ImageMap packing efficiency
by And Yet It Moves · in Torque Game Builder · 10/03/2008 (5:47 am) · 4 replies
Hi,
checking the memory usage of our textures, i noticed that imageMaps which use the key mode are packed very inefficiently. we got a texture with elements which are already arranged in the most efficient way, fitting into a 1024x1024 image (also taking into account some additional pixels for filterpadding). but however, tgb turns it into a 1024x2084 texture, giving an efficiency of 40%.
this leads to another question: a 2x2 celled image map with packing efficiency of 100%, size 512x512 is internally turned into a 256x1024 image (using the $pref::T2D::imageMapDumpTextures). do these images show how textures are stored on the graphics card? and if so why are they turned into this inefficient aspect ratio?
thanks,
peter
checking the memory usage of our textures, i noticed that imageMaps which use the key mode are packed very inefficiently. we got a texture with elements which are already arranged in the most efficient way, fitting into a 1024x1024 image (also taking into account some additional pixels for filterpadding). but however, tgb turns it into a 1024x2084 texture, giving an efficiency of 40%.
this leads to another question: a 2x2 celled image map with packing efficiency of 100%, size 512x512 is internally turned into a 256x1024 image (using the $pref::T2D::imageMapDumpTextures). do these images show how textures are stored on the graphics card? and if so why are they turned into this inefficient aspect ratio?
thanks,
peter
#2
but our textures are already in a fairly compact format. i just want to use the color keying feature of imagemaps. i have some textures which fit into a 512x512 image, seperated with a key color as described in the reference (actually the image is a little bit smaller, but with the filterpad pixels it gets 512). so this texture should have an efficiency of ~90%. but tgb rearranges these textures into a 1024x512 format (shown with imageMapDumpTextures - why this non quadratic format anyway?) and so efficiency drops to 40%. i just want tgb to use the texture as i assembled it and generate the frames resp. its texture coordinates and not to rearrange the frames. so i would like to know how i can prevent tgb from doing that.
regards,
peter
10/05/2008 (1:11 pm)
Thanks Justin,but our textures are already in a fairly compact format. i just want to use the color keying feature of imagemaps. i have some textures which fit into a 512x512 image, seperated with a key color as described in the reference (actually the image is a little bit smaller, but with the filterpad pixels it gets 512). so this texture should have an efficiency of ~90%. but tgb rearranges these textures into a 1024x512 format (shown with imageMapDumpTextures - why this non quadratic format anyway?) and so efficiency drops to 40%. i just want tgb to use the texture as i assembled it and generate the frames resp. its texture coordinates and not to rearrange the frames. so i would like to know how i can prevent tgb from doing that.
regards,
peter
#3
as we are struggling with texture sizes again, has anybody an answer on this?
thanks alot,
peter
09/07/2009 (5:29 am)
digging up the dirt :)as we are struggling with texture sizes again, has anybody an answer on this?
thanks alot,
peter
#4
If that's not the case and you've already accounted for that, then it could be that TGB's image packing algorithm is just not doing as well of a job at packing your frames as you did yourself. In that case, I would say maybe you would need to add a "raw" image packing mode which doesn't do any of the reorganizing. t2dImageMapDatablock::calculateDstFrames() is where frames are broken up and laid out on one or more textures. If you just rounded up to the next power of 2 for your dimensions and copied all the frame data as-is, that might solve your problem.
As for the non-square textures, it seems the packing algorithm favors height over width when all else is equal. I just looked at some stuff I'm doing myself and noticed I ended up with a few 64x2048 textures. That doesn't take up any more video RAM than a 256x512 texture, but I agree it looks "wrong". (TGB does check the maximum texture size first, though.) In any case, a raw layout function as described above would solve this problem too.
09/08/2009 (1:27 am)
You said you had filter padding turned on and that your image was slightly smaller than 512x512. However, it's my understanding that filter padding is not applied to the texture as a whole, but rather to each frame individually. If you have frames sharing their 1-pixel border, filter padding may be expanding that out to a 2-pixel border and pushing you over a power of 2.If that's not the case and you've already accounted for that, then it could be that TGB's image packing algorithm is just not doing as well of a job at packing your frames as you did yourself. In that case, I would say maybe you would need to add a "raw" image packing mode which doesn't do any of the reorganizing. t2dImageMapDatablock::calculateDstFrames() is where frames are broken up and laid out on one or more textures. If you just rounded up to the next power of 2 for your dimensions and copied all the frame data as-is, that might solve your problem.
As for the non-square textures, it seems the packing algorithm favors height over width when all else is equal. I just looked at some stuff I'm doing myself and noticed I ended up with a few 64x2048 textures. That doesn't take up any more video RAM than a 256x512 texture, but I agree it looks "wrong". (TGB does check the maximum texture size first, though.) In any case, a raw layout function as described above would solve this problem too.
Associate Justin DuJardin
Default Studio Name
If you're interested in a more compact way of storing image maps, I'm not entirely sure if this made it back into the official TGB at any point, but Michael Woerister had a plan in which he talked about this before. Hope this is what you were looking for.
http://www.garagegames.com/blogs/53436/12318
Cheers,
-Justin