I’m trying to get to the bottom of how masterTextureLimit works, but my results have been inconsistent so far.
I created a massive sprite (8192x8192), and I’d like to resize it at runtime to save performance. The idea is to start with large sprites and then resize based on the monitor’s resolution. Here’s what happens at different settings:
Texture import size 4096, masterTextureLimit 0, mipmaps on: ~0.9ms
Texture import size 4096, masterTextureLimit 1, mipmaps on: ~0.83ms
Looking at these results, I have a couple of questions:
If masterTextureLimit is supposed to halve the texture resolution, why did it not affect performance while setting texture size to 4096 did?
Why did turning mipmaps on improve performance at 8192 texture size but not at 4096? My camera is orthographic, and it’s only 1 unit away from the sprite.
With mipmaps on, you have lower resolution versions of the texture that get selected automatically. The performance gain is in the caching of the texture. With a smaller version of the texture, you have more cache hits.
It seems that the required resolution is partly 8192 and partly 4096. So when turning on mipmaps on the 8192 version, part will come from the 4096 version, which will lead to a performance gain. When turning on mipmaps on the 4096 version there is no change, since 4096 is the required resolution. If you would increase the distance, you’d see a performance increase also on the 4096 version.
Thanks, I think that explains my 2nd question. And I suppose the camera would have to be really close to the object for Unity to automatically select the 8192 texture.
It’s not so much Unity that selects it. It’s the GPU that does that per pixel. I have no experience with masterTextureLimit, but I agree that your results seem to indicate it doesn’t work as documented.