What do people usually do in unity to reduce the memory consumed by textures? Given for example that many sprites are 256 colors or less using palettes. What is everyone doing? Just loading them in as 32bit RGBA textures using 4 bytes per pixel? And I’m not talking about any of the compressed texture formats which lose quality.
Absolutely nothing unless it becomes a problem.
Otherwise my focus is 100% laser on the idea, trying to find the fun gameplay, the implementation of features, testing, etc.
DO NOT OPTIMIZE “JUST BECAUSE…” If you don’t have a problem, DO NOT OPTIMIZE!
If you DO have a problem, there is only ONE way to find out. Always start by using the profiler:
Window → Analysis → Profiler
Failure to use the profiler first means you’re just guessing, making a mess of your code for no good reason.
Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.
Remember that optimized code is ALWAYS harder to work with and more brittle, making subsequent feature development difficult or impossible, or incurring massive technical debt on future development.
Notes on optimizing UnityEngine.UI setups:
At a minimum you want to clearly understand what performance issues you are having:
- running too slowly?
- loading too slowly?
- using too much runtime memory?
- final bundle too large?
- too much network traffic?
- something else?
If you are unable to engage the profiler, then your next solution is gross guessing changes, such as “reimport all textures as 32x32 tiny textures” or “replace some complex 3D objects with cubes/capsules” to try and figure out what is bogging you down.
Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.
This sort of speculative optimization assumes you’re properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.
So you’re ok with using 4x the amount of memory than is needed?
Why not?
Are you using more than you have?
If not, use it all!
You don’t get credit for using less memory until it becomes a constraint.
It impact file file size, download times, installation times, gpu usage, power consumption, memory bandwidth, etc. “Be greedy as hell until someone complains” is not my approach.
is there anything you can really do? the image has the pixels that it has, if you cant resize or fundamentally change the image i dont see how you can save memory. You can unload them when you arent displaying them.
If your sprites have a lot of transparent pixels maybe you can create a file that holds the positions of each pixel and reconstruct the sprites during runtime. This would save you installation size but would still take the same up the same ram.
1 Like
In two short posts you have TWICE mis-characterized what I said and tried to put your own words into my mouth.
Specifically, I never said:
And I also did not say:
Those are your words my friend, not mine.
I am going to leave this thread now because I am not interested in people reading my words and injecting random nonsensical straw man exaggerations into my words.
I stand by my words as they are written above. I disagree with your mis-characterization attempts.
All the best of luck in your endeavors.
You gave your opinion and I responded to it. I do not believe that all optimization should be left until thought to be necessary, regardless of whether that’s a popular notion among other programmers. I am looking for a way TO reduce the memory consumption, not to ask WHETHER to do so. So your response was really off topic anyway. Thanks.
Am personally not such a firm fighter of “don’t optimize until it’s a problem” and I find it important to get a good grasp on what detoriates performance and what doesn’t. Having the incentive to optimize can help building that knowledge which then in turn helps you avoid pitfalls.
However it’s always a matter of what effort is worth it.
So for the textures, it’s probably not worth it because textures ARE compressed: Unity - Manual: Texture compression formats
It is likely that you could save some executable size by using the color count efficiently as you describe, but because GPUs internally work with full colors anyways, there isn’t a standard for that in Unity.
Fear you’d need to construct that yourself from ground up (or search Github if someone else did) and then also develop special shaders that decode this information accordingly. Likely not worth it and might even reduce performance of the shader due to the extra decoding for every pixel.
Edit: Theoretically you could rewrite the whole shader, lights and shadow code of Unity’s shaders to use the fewer colors, but then we truly are in the range of esoteric programming xP
1 Like
No-one who does pixel art wants to use lossy texture compression. It changes the pixel colors too much. Then the only alternative is to use full 24-bit textures unnecessarily. GPU’s don’t necessarily ‘work with full color’, the texture data’s contents and what pixel colors are output in the fragment shader are not necessarily related. You can store 32 1-bit pixel values in an RGBA pixel for example and extract them in the shader. Now your memory use is 1/32th the size.
Also you bring up a good point that gpu texture memory is also limited and could run out especially on mobile.
By “gpu internal” I didn’t mean your shader code but what is being done with the return value of the frag method. That one normally is a float4. Can that actually be changed?
Of course you can do what you want with the input texture but in exchange of some computation cost.
Have trouble imagining to fill the vRam just with textures of a 2D game even if they are full color…
In every case you are free to write a simple, lossless compressor yourself, perhaps using the AssetPpstprocessor (so the texture files on the hard drive remain in their regular format) and then adapt the shader.
It’s much more of an issue on mobile devices, for example, and in terms of file transfer bandwidth. Textures often take up a vast majority of a downloaded file and who doesn’t want their thing to open 4x faster? Or to put it another way, if someone asked you if you wanted to deliberately make your download 4x slower, would you say “Yes please!”?
The return value of the fragment shader doesn’t have anything to do with texture memory as such it’s only to do with the output to the backbuffer or render texture, which can be in a variety of formats. Even with a float4 output which is overkill (most people only need a fixed 8-bit value not a float), it gets translated into the format of the render target.
Yes I could make a lossless compressor myself.
My question mainly though is I’m trying to find out if other people are actually doing something to address this, or whether everyone is just defaulting to using RGBA 32-bit textures all the time?
the answer is that probably no one is optimizing on textures, its too much work for little gain
on mobile i find that i’d rather make a download slower than make the ingame experience laggy when you are decrypting the textures from the more compressed efficient file(since smartphones nowadays have tons of memory capacity but trash ram and cpu)