Complex Image Maps Worth It?
by Charlie Patterson · in Torque Game Builder · 03/07/2012 (8:56 pm) · 11 replies
I'm just starting to really add the images to my game. I'll probably also need to do my own animations by flipping through images (ImageMaps), FWIW.
This gets me reading the T2D docs on ImageMaps and modes, and the docs promise me that T2D is very smart about packing images into textures and getting a great performance boost anyway. Sounds great!
1) So I'm thinking about the extra cumbersome step in the "asset pipeline" of taking the artists output and compositing images into "sheets" (you know, lots of related images in one big image). And I'm wondering if this is even worth it in Torque if it can pack textures anyway? What do you think/know?
I could still create sheets of images to keep similar images together, say all the frames of the players death animation. But why bother? I could just use a directory for that and let Torque bring it all together in textures, no?
Two more related questions if you don't mind. :)
2) Any tools to create the "Key"-Mode Image files if I wanted to?
3) Any way to ask Torque how many textures it is creating, swapping during run time? I don't see it in the banner.
This gets me reading the T2D docs on ImageMaps and modes, and the docs promise me that T2D is very smart about packing images into textures and getting a great performance boost anyway. Sounds great!
1) So I'm thinking about the extra cumbersome step in the "asset pipeline" of taking the artists output and compositing images into "sheets" (you know, lots of related images in one big image). And I'm wondering if this is even worth it in Torque if it can pack textures anyway? What do you think/know?
I could still create sheets of images to keep similar images together, say all the frames of the players death animation. But why bother? I could just use a directory for that and let Torque bring it all together in textures, no?
Two more related questions if you don't mind. :)
2) Any tools to create the "Key"-Mode Image files if I wanted to?
3) Any way to ask Torque how many textures it is creating, swapping during run time? I don't see it in the banner.
#2
03/08/2012 (4:35 pm)
I think the basic question is, bigger character sheets with lots of stuff on them or lots of little image files. I'm curious about the actual overhead/benefits to each too. I've been doing similar images on the same sheet.. basically a standing, attacking, and dead image since it's likely they'll all potentially be needed if that sheet gets loaded up. 
#4
1.Draw calls. It's much more efficient to draw all your frames of an animation from the same texture than to switch between textures. The more you can batch together, the faster it is. Many context switches can kill even great hardware's performance. TGB doesn't currently cram images together, and automatic packing of multiple textures isn't always very efficient without at least a little intervention anyway. You'll always want to plan out your sheets to balance between loading time and memory used.
2.Image sizes. Compressing a bunch of similar images generally saves a lot of space compared to storing each individually. Many different images will still be more efficient to draw, and it's just one file to reference.
3.In-memory sizes. TGB will adapt sizes to a power of two. If your sprites are 68x68 frames in individual images, each is padded to 128x128. An even grid of sprites on a sheet will save nearly half the video memory.
03/09/2012 (8:52 am)
You want sprite sheets. The benefits:1.Draw calls. It's much more efficient to draw all your frames of an animation from the same texture than to switch between textures. The more you can batch together, the faster it is. Many context switches can kill even great hardware's performance. TGB doesn't currently cram images together, and automatic packing of multiple textures isn't always very efficient without at least a little intervention anyway. You'll always want to plan out your sheets to balance between loading time and memory used.
2.Image sizes. Compressing a bunch of similar images generally saves a lot of space compared to storing each individually. Many different images will still be more efficient to draw, and it's just one file to reference.
3.In-memory sizes. TGB will adapt sizes to a power of two. If your sprites are 68x68 frames in individual images, each is padded to 128x128. An even grid of sprites on a sheet will save nearly half the video memory.
#5
03/10/2012 (11:46 pm)
Good thread. So if I make a huge sprite sheet with all 100+ frames of a fighting game character versus sectioning each imagemap into groups of each individual animation. I'm not sure but isn't the cap 2000 pixels x 2000 pixels per imagemap so you can't go too huge. Sorry I just trying to break down what you just said before I make the huge beast.
#6
The laptop GPUs from NVidia have a 8192x8192 limit per texture. Most desktop GPUs are around that level too, with the real gamer GPUs peaking at 16384x16384 currently. You can read these numbers from them, and you'll probably see that in TGB's console.log. With a little effort I'm sure you could make use of this and the existing resizing code to slap smaller textures together if the GPU can actually handle more.
16384x16384 gives you a lot of headroom, at the mere cost of 768MB of VRAM ;)
03/11/2012 (12:56 am)
An old Intel GPU might have a 2048x2048 limit. Old mobile devices have 1024x1024 as their limit, and the newer ones like the iPhone 3GS and on or the latest Samsung (the expensive ones) have reached the old desktop limit.The laptop GPUs from NVidia have a 8192x8192 limit per texture. Most desktop GPUs are around that level too, with the real gamer GPUs peaking at 16384x16384 currently. You can read these numbers from them, and you'll probably see that in TGB's console.log. With a little effort I'm sure you could make use of this and the existing resizing code to slap smaller textures together if the GPU can actually handle more.
16384x16384 gives you a lot of headroom, at the mere cost of 768MB of VRAM ;)
#7
1) Laziness. It's so much easier to type "%sprite.setFrame( <newFrame> );" rather than "%sprite.setImageMap( <imageMap>, <frame> );".
2) TGB Organization. It feels like each additional sprite added to the Game Builder makes it so much more difficult to use. Sprite sheets at least give you some basic organization.
Both of those (especially #2) make the effort of running a program like "GlueIt" effortless.
03/11/2012 (3:19 pm)
I have two reasons for sprite sheets:1) Laziness. It's so much easier to type "%sprite.setFrame( <newFrame> );" rather than "%sprite.setImageMap( <imageMap>, <frame> );".
2) TGB Organization. It feels like each additional sprite added to the Game Builder makes it so much more difficult to use. Sprite sheets at least give you some basic organization.
Both of those (especially #2) make the effort of running a program like "GlueIt" effortless.
#8
These two:
$pref::T2D::imageMapDumpTextures
$pref::T2D::imageMapShowPacking
Will help you get an idea of what T2D is doing with your textures behind the scenes. The first will actually dump the video ram version of each texture out to a folder for you to look at, and the second will show packing data in the console as it goes along.
You'll likely find it's not as great as you imagine at "packing" the textures... In fact it doesn't seem to really do anything unless the image is a KEY or CELL mode datablock.
I was somewhat under the impression it was doing something similar to this: http://www.blackpawn.com/texts/lightmaps/ as it loaded them into VRAM, but that doesn't seem to be the case at all.
It would be awesome if it did!
Maybe my engine is just set up wrong?
03/12/2012 (2:35 pm)
Hey.These two:
$pref::T2D::imageMapDumpTextures
$pref::T2D::imageMapShowPacking
Will help you get an idea of what T2D is doing with your textures behind the scenes. The first will actually dump the video ram version of each texture out to a folder for you to look at, and the second will show packing data in the console as it goes along.
You'll likely find it's not as great as you imagine at "packing" the textures... In fact it doesn't seem to really do anything unless the image is a KEY or CELL mode datablock.
I was somewhat under the impression it was doing something similar to this: http://www.blackpawn.com/texts/lightmaps/ as it loaded them into VRAM, but that doesn't seem to be the case at all.
It would be awesome if it did!
Maybe my engine is just set up wrong?
#9
03/12/2012 (9:17 pm)
No, TGB doesn't do any serious packing. But it WILL round up to the nearest power of two, just to test if you're paying attention :)
#10
I'm looking forward to doing a few experiments with the tools @Tim brings up. Thanks!
As for @Williams point about organizing your ImageMap area in TGB, that's a good point I hadn't thought of. I was considering creating directories for each "sheet" and loading them in with TorqueScript. As for the editor, I was considering using just one image for each ImageMap as a placeholder in the editor. But if T2D doesn't pack them all that well, this is probably out.
This leave the last biggie. It seems T2D only understands multi-sprite ImageMaps in either Cell or Key mode. But I haven't seen a tool that does Key mode. (Not even unchaos that comes with T2D, I don't think.) Was Key mode a Torque-exclusive idea and you were supposed to build these maps by hand? Is there a tool to build these maps?
Ultimately, I'm hoping the artist can "save" in his favorite tool and I can "compile in" his output. I wouldn't mind a tool in between us in the chain. However, I'm hoping not to re-build image maps and animations by hand or tweak anything that looks like fiddly numbers.
I may be forced to use Cell mode and leave it at that. Not bad really.
03/12/2012 (10:57 pm)
Thanks for this great thread! Lots of food for thought. The ImageMap docs made it sounds like Torque packs textures like a boss. I guess not.I'm looking forward to doing a few experiments with the tools @Tim brings up. Thanks!
As for @Williams point about organizing your ImageMap area in TGB, that's a good point I hadn't thought of. I was considering creating directories for each "sheet" and loading them in with TorqueScript. As for the editor, I was considering using just one image for each ImageMap as a placeholder in the editor. But if T2D doesn't pack them all that well, this is probably out.
This leave the last biggie. It seems T2D only understands multi-sprite ImageMaps in either Cell or Key mode. But I haven't seen a tool that does Key mode. (Not even unchaos that comes with T2D, I don't think.) Was Key mode a Torque-exclusive idea and you were supposed to build these maps by hand? Is there a tool to build these maps?
Ultimately, I'm hoping the artist can "save" in his favorite tool and I can "compile in" his output. I wouldn't mind a tool in between us in the chain. However, I'm hoping not to re-build image maps and animations by hand or tweak anything that looks like fiddly numbers.
I may be forced to use Cell mode and leave it at that. Not bad really.
#11
03/13/2012 (12:13 am)
TexturePacker produces all sorts of sprite sheets. Make it pack tightly with 1px border, and TGB should be able to pick up on where stuff is (it looks at the upper left corner of the sheet as a guideline). A similar tool exists for Windows. Google harder :) 
Simon Almqvist Pettersson
Dohi Sweden