koobas.hobune.stream
Unity 2D and Texture Memory.
I'm making a digital storybook, and I've got some very happy artists with some very large and CPU expensive textures (like, 4 background textures that are each 1024 x 512). So far, my advice for keeping it performant has been to:
1) make sure they're allowing unity to keep things as a power of two, 2) combining layers where possible 3) avoiding having images with lots of empty space 4) Making things static where possible.
But there's still no way it's going to look sharp on any iOS Retina screen, and have a good framerate. A friend suggested that making everything -- the characters, the backgrounds, everything -- into Unity 2D sprites -- would be vastly better. Is that true? Why?
Is there any other major performance-increasing thing I could do? Because right now Unity is seeming pretty slow for this kind of thing. I understand that Unity 2D will batch draw calls, but putting all my textures into one gigantic draw call wouldn't help, right? It's just putting all the eggs in one basket.
I recently had to do this in Unity while porting a game from another engine (that had superior png decompression somehow). I resorted to using a loading animation that as it turns out is a great feature for our target audience. In your case however I'd advise your artists to indeed construct everything out of smaller sprites.
The reason is because this way you only load as much as the space you take up, and you can provide smaller images for non-retina devices ins$$anonymous$$d of having backgrounds for different aspect ratios.
However if your artists do want to draw the whole thing then it's best to confine them to the space of powers of two. It also helps to do that in layers even. I ended up having to use a tiled background with slightly smaller images layered on top for a small loading time decrease. However you can still achieve good loading times with proper compression. I've even heard people say it's better to use jpg for images with no transparency.
If you want to really get into the fastest way to load a texture I can provide an answer.
Hi, smoggach! Thanks for the help. I know what you mean by using smaller sprites, and I plan to help them with that. That's good advice. BUT Do you think that the Unity 2D option will increase at all? Or no?
Nope. The 2D option doesn't do much more than set the default main camera to orthographic. If you're super worried about performance you CAN shave a few milliseconds off by pooling sprite objects and just replacing their textures.
some very large and CPU expensive textures (like, 4 background textures that are each 1024 x 512)
That has nothing to do with the CPU; textures are drawn by the GPU.
A friend suggested that making everything -- the characters, the backgrounds, everything -- into Unity 2D sprites -- would be vastly better. Is that true?
Nope. Sprites aren't magic and they're not even really 2D, they're the same 3D objects that everything in Unity is...textures on meshes. Having 4 background textures on quads vs 4 sprites is going to be pretty much the same, performance-wise. Using sprites makes sense simply because that's easier to work with, but won't significantly increase performance. Depending on what you're doing with the characters and what Unity license you have (Unity Pro can use tight meshes that save on fill rate), you can see some moderate performance improvements.
Anyway, 4 1024x512 textures is not very intensive even on mobile devices and will run quite fast. Just make sure to use a non-transparent shader (i.e., not the default sprite shader) on any textures that don't actually need transparency, to save on fill rate. Use compression where possible. It's usually better to use, say, a compressed 512x512 texture rather than a non-compressed 256x256 texture...you can visually scale down the compressed texture to make it look better and it will still use less RAM and be a little faster.
Ah, yes, the old GPU CPU mixup. Thanks.
Darn. I didn't think sprites were magic, but I had my hopes. It sounds like it's still the right direction to go in.
As far as compression, I'm curious to hear your ideas on a concept. Would it be faster to run, say, a 512 x 512 image with an unlit shader and no transparency on a 50 tri mesh that is shaped to look like a partially transparent image? Or would it be faster to run a 512 x 512 image with transparency as a sprite? For example, let's say I compared:
1) A texture of a tree with transparency (the easier approach) on a quad, which uses an unlit sprite shader.
and
2) A UV map on a flat mesh cut to the shape of a tree, but which uses a non-transparent, unlit shader.
Is 2 still faster?
Option 2 would work better because (since you don't need alpha) you could use JPG ins$$anonymous$$d of PNG which will load faster. However option 1 would work better on apple devices if you used PVR texture compression.
In any case Unity saves a lot of time on drawing with dynamic and static batching. In your position I'd choose whichever option is easiest for you and your artists.
You really do not want to use JPG, since it's lossy-compressed. It will not load any faster since Unity does not use JPG or PNG files (aside from the initial import in the editor).
The answer is, it depends. Not rendering pixels is faster than rendering them, of course, however rendering many polygons is slower than rendering few polygons. It's normally better to make some extra polygons if it means not rendering transparent pixels, since polygons are cheaper, but if you had really a lot of extra polygons, it could be slower. You'd have to test to know for sure.
Great info, everybody. Sounds like something we'll have to test. Thanks!
