Massive (42mb) Grass Atlasses in memory

In a recent adventure, I was trying to find why there are a lot of massive textures in memory, in build.



I built a tool that loads all textures in memory using Resources.FindObjectsOfTypeAll, sorts them by size, and then saves the top X of them. I double checked instance ID's to make sure these largest textures were indeed the ones showing up in the memory profiler.

Turns out these massive textures consist of duplicate, 2048 x 2048 textures that is an atlas of grass textures, seemingly generated by the terrain. Each of these textures takes up 42.7 mb. When I encode them to PNG and save them, they become 531 kb. That is... clearly absolutely insane. I have no idea how this can even be possible.

First off, why is a texture that isn't even *that* large so massive? Finally, why does each individual terrain create its own, even though the other terrains have the exact same textures?

Should I report this as a bug?

EDIT: I decided to heavily shrink my grass textures to 256x256 as a test. This turned these 42mb atlasses into 2mb atlasses.

I understand that perhaps having a 1024x1024 grass texture is a bit much, but I also think that having to do something like a 256x256 is a bit... bad. Also, my question remains - why in the world does a single 2048x2048 texture become 42mb? I understand no compression is happening, but damn.

From my quick checks, it looks like grass has been like this at least since 2018.3.

 

What format is the 2048x2048 texture in? Normally, an uncompressed RGBA takes up ~16MB (2048x2048x4 bytes) plus mipmaps would bring it a little over 21.3 MB. Since your number of 42.7 is double this value, that makes it look like the texture memory is being doubled up somehow or perhaps it is a 2048x4096 texture.

Also, are you running from a build or in the editor? Profiling in the editor will give you different numbers.

As for the grass system, I wouldn't recommend using it. It's pretty awful.

 

Maybe the atlas is readable?

https://docs.unity3d.com/Manual/BestPracticeUnderstandingPerformanceInUnity4.html

 

I'm guessing the atlas is indeed readable, since I believe a texture created during runtime is always readable by default, so Unity probably doesn't mark it as unreadable. And I was testing in build, of course )
As for using the grass system, I agree, I plan on leaving it far, far behind. It's pretty antiquated at this point.

 

Did you find a fix for this we seem to be having this issue

 

Yes - reduce the texture size of grass, and don't load all terrain data into memory at once. The atlas that is generated is generated for each terrain, so if you have a ton of terrains in memory with large textures it'll destroy your ram

 

Ah surely that is a bug. I'm afraid I need all my terrains in memory due to the nature of my game i.e Multiplayer where the host simulates the physics.

I have made a post about it https://forum.unity.com/threads/lots-of-grass-atlases-21-3mb-each.1255629/

I will try reducing the texture size, that could work.

 

That seems to do the trick.

Thank you!

 

Yeah, I'm not sure if the atlas is generated during buildtime (which would explain it being loaded in memory, not many ways for Unity to fix this then), or runtime (if so then this is a large oversight in my eyes)

 

Just seems really silly to be generating pretty much the same atlas for each terrain when really only 1 or two is required