TexCoord cropping: Best approach?

[MunkDev]

Hey, I wanted to ask how other developers handle textures in general; whether cropping large files is better than wasting hellalot of space by saving each texture individually with a lot of black around them, since textures follow the "power of two" rule?

As an example, my approach to using large texture resources is using SetTexCoord and then finding the starting point in the topleft corner of a given subtexture and then using its width and height to determine the bottomright corner.

I use this to create my own "atlas" of textures, stored in simple tables containing width, height and the topleft starting point (x and y values). I'm not sure whether this is a good approach or not. It definitely works, but is there a better way of doing it that I'm unaware of?

Example:

local _, db = ...
local path = "Interface\\AddOns\\MyAddon\\Textures\\"
db.Atlas = {}
 
-- width, height, startX, startY
db.Atlas.Frame = {
    Size        = {1024, 1024}, -- source texture size
    Main        = {912, 842, 0,   0},
    Ornament    = {89,  61,  935, 914},
    SplitStack  = {237, 115, 0,   842},
    Item        = {382, 68,  619, 956},
    ItemPress   = {382, 68,  237, 888},
    ItemFocus   = {382, 68,  237, 956},
}
 
-- calculate the fraction of the image size 
local function GetCoords(sourceSize, subTexture)
    local sourceWidth, sourceHeight = unpack(sourceSize)
    local width, height, startX, startY = unpack(subTexture)
    return {
        (startX)        /sourceWidth,   -- left
        (startX+width)  /sourceWidth,   -- right
        (startY)        /sourceHeight,  -- top
        (startY+height) /sourceHeight,  -- bottom
    }
end
 
function MyAddon:CreateAtlasTexture(parent, source, subTexture, layer, name, resizeParent)
    local fullTexture = db.Atlas[source]
    local textureName = name or subTexture
    local subTexture = fullTexture[subTexture]
    local width, height = unpack(subTexture)
    local texture = parent:CreateTexture(nil, layer)
    texture:SetTexture(path..source)
    texture:SetTexCoord(unpack(GetCoords(fullTexture.Size, subTexture)))
    texture:SetAllPoints(parent)
    parent[textureName] = texture
    if resizeParent == true then
        parent:SetSize(width, height)
    end
    return texture
end

The info tab in Photoshop gives me all the info I need for calculations on a given subtexture:

..on a source texture file called "Frame.tga", which is 1024x1024:

In-game result:

[Resike]

It's way to much hassle if you ask me, it can also cause some issue if you later want to rotate/animate those textures. However if you don't plan to edit/rotate/animate the textures later then it's the best method.

[Seerah]

This is what the game does.

[semlar]

Originally Posted by Resike It's way to much hassle if you ask me, it can also cause some issue if you later want to rotate/animate those textures. However if you don't plan to edit/rotate/animate the textures later then it's the best method.

It's substantially better performance-wise to draw the same texture multiple times than it is to draw multiple separate textures on-screen.

As for whether it's worth the hassle of slicing up and defining a texture atlas, that's up to the addon author.

[Resike]

Originally Posted by semlar It's substantially better performance-wise to draw the same texture multiple times than it is to draw multiple separate textures on-screen. As for whether it's worth the hassle of slicing up and defining a texture atlas, that's up to the addon author.

I'm pretty sure the game is already collecting the smaller textures and putting them into a bigger square texture by default, to save video memory. However if you do this by yourself then you can save a little bit more space actually.

[SDPhantom]

Whichever way you end up doing, you should have all the coordinates precalculated instead of dynamically calculating the same numbers repeatedly live. Even if you have to do something like this, it'll be a lot better. This also allows more control by allowing you to flip textures by swapping the relevant X or Y values.

local TexCoords={
--  {Left, Right, Top, Bottom}
    Main=       {0,         0,          912/1024,   842/1024};
    Ornament=   {935/1024,  914/1024,   1,          975/1024},
--  etc...
}
 
--  Later on
texture:SetTexCoord(unpack(TexCoords.Main));

[MunkDev]

Originally Posted by SDPhantom Whichever way you end up doing, you should have all the coordinates precalculated instead of dynamically calculating the same numbers repeatedly live. Even if you have to do something like this, it'll be a lot better. This also allows more control by allowing you to flip textures by swapping the relevant X or Y values.

Damn it, I was hoping to get by without doing simple arithmetic on every texture. Oh well. This solution is indeed cleaner.

[SDPhantom]

The solution I posted is a compromise, but it only ends up making the calculation once on load instead of every time it's referenced. It's also simple enough in which you put in point/length instead of percentage values. The point of the matter is the more work you leave the computer to deal with, the less CPU power it has to do everything else it needs to do.

[MunkDev]

The consensus seems to be that cropping large textures is the best approach to using a lot of texture resources, instead of splitting them up into separate files. Just looking at the art provided by blizzard, this is the way they do it (both WoW and Diablo).

Is there any proof to any of your claims regarding video memory? There will obviously be less black in a texture file where everything is mashed together, because the sub textures are obviously not always a perfect fit for power of 2 image sizes.

[Resike]

Originally Posted by MunkDev The consensus seems to be that cropping large textures is the best approach to using a lot of texture resources, instead of splitting them up into separate files. Just looking at the art provided by blizzard, this is the way they do it (both WoW and Diablo). Is there any proof to any of your claims regarding video memory? There will obviously be less black in a texture file where everything is mashed together, because the sub textures are obviously not always a perfect fit for power of 2 image sizes.

I'm not sure the game still doing it or not. I only know that is used to do with the icons for example.

When you tried to rotate an texture back then it showed all the cached icons/textures around that icon, if there were no cached icons then they weren't visible.

http://i.imgur.com/7zPamH3.jpg

But my guess would be that the game still does this, since sometimes some icons looks really weird like missing 1 line of pixels or have an extra one, which would indicate that the game is reading that icon from such a table and there is an overlapping there. But you really need to have some serious OCD to notice something like that.

Of course all this is only happening, if you don't use any custom icon packs.

Also texture rotation/animation is still fucked up currently, if the texture doesn't have at least a 1 pixel fully transparent border around it.

[semlar]

Originally Posted by Resike I'm not sure the game still doing it or not. I only know that is used to do with the icons for example. When you tried to rotate an texture back then it showed all the cached icons/textures around that icon, if there were no cached icons then they weren't visible. http://i.imgur.com/7zPamH3.jpg

This is strictly a result of the game merging the icon textures, it doesn't do this to anything else.

[MunkDev]

I'm happy Sublime has support for multiple cursors.
Is it possible to calculate these expressions within a text editor?


Edit: Calculate for Sublime did the trick.