Hi everyone, new here! It took a while for me to find this place x)
I was just wondering about sprite sheet cost in udk or ue4 (or unity)…
What i mean is, let’s say you have two sprite sheets, one is 512x512 and has 4 sprites (2x2), the other is 512x512 and has 64 sprites (8x8), I’m wondering if it is any more expensive to use the 8x8 rather than the 2x2, and if it is more expensive, how come?
I’m working primarily in udk right now if that helps
thanks!
No. Same cost. It’s the same UV math in both cases, just different values.
Welcome!
The cost of a flipbook/sprite sheet comes down almost entirely to the texture size. We’re stlil not typically pushing massive textures, so the puzzle is always do you want less frames at a higher resolution per frame? Or more frames at a lower resolution?
You can also consider channel packing the flipbook (i.e. putting different image sequences in the red, green, and blue channels) but this requires a more intelligent shader to be created. If you’re paying attention to texture size and color channels, its also worth noting that the different compression types do alter the channels differently, and none of them treat alphas particularly well. For example, with the default DXT1 compression in Unreal, a texture with RGBA = 2x the file size as a texture with just RGB. In this case, if you can store the alpha in a different texture, you actually get 2 for the same texture cost (2x RGB textures = 1x RGBA texture). This becomes more efficient for texture memory, but requires a secondary texture lookup (so your shader is less efficient) and can definitely be a pain for the artists to work with.
Since flipbooks are frequently the most negatively abused tool in a junior FX artist’s tool box, I want to call out something: It’s important when using flipbooks that you understand their short comings and strengths - the strength is obvious: you can put whatever data you want onto it and get incredible motion that you just can’t otherwise achieve. The negatives are:
You typically can’t achieve the target frame rate. If your game is running at 30 fps, you need 30 frames for 1 second of animation. Most effects have to last several seconds, so you’ll need #seconds * 30 frames in your texture sheet. Most flipbooks are still 8x8s, and rarely can push above 1024 (except for super important hero effects). So you’re pretty much never going to hit your target frame rate. We can decrease the frame rate a little, and if the player isn’t too keen, they won’t notice. That said, it’s really painful when I see flipbooks in a 60fps game playing back at ~10 frames a second.
There is no random: Every particle playing back that flipbook sequence will look exactly the same. With ambient smoke, etc, this is less of an issue. With fire - it’s always painfully obvious. Offsetting the start frame, and adding small variances like UV distortion do help a little, but rarely enough.
There is no dynamic lighting. Ok, so this isn’t necessarily true. If you’re a pro, you’ll figure out how to use a flipbook to store things like density, normals, and temperature to plug into the runtime lighting, rather than your final emissive render. The problem is that most people just render the final beauty pass from their CG tools, throw it in a flipbook, and press play in their effect. Unless it’s only ever going to play in one locked off position with a locked off camera (i.e. a movie), good luck getting that thing to integrate into the environment across the game.
There is no interaction: This is a lesser issue because most of our tools suck at dynamic interactions anyway, but it’s worth calling out - motion solutions created in the shader or other methods can be interacted with at run time (increase/decrease distortion, change vectors, slow down/speed up).
Thanks a lot for your insight! I love the idea of packing 8x8 (or x amount) across rgb channels lol x) That never occurred to me as a use for channel packing before, very interesting : )
Thanks again!