In my task manager, Unity editor is using almost 10GB memory, this makes it very difficult to bake lights. Actually I can’t even bake lights with 2 texels because I’m running out of memory.
Doing some memory profiler I realized that my textures are consuming a lot of memory:
Then, how can I reduce the memory consumption of my textures?
Stick with textures that are of the size format like 256x256 1024x1024 4096x409 and on. In the import settings for each texture chose the correct size the textures will be in the game. they all default to 2048x2048 which may not be the correct size if your texture is 512x512
in the texture import setting you can see the amount of memory will consume for each texture. you can see a huge difference if you do this simple test. create a correct 1024x1024 pixel texture and one that is 1024x1025 pixel. This last one will have way heavier memory consumption than the previous one even if is just one pixel more.
you ca read the numbers on the white text where the texture preview is shown
the explanation is that unity converts all your textures to special file formats that work on the GPU. if you don’t respect the correct settings you have this memory issue. Is fine for simple games, you can get away with non standard sizes, but when you have a lot of textures and objects is important to use the correct sizes and formats.
Yeah they are with the right size, when I change them from 4096 to 1024 they are much lighter but also the quality in the scene is lower.
However in some textures says they use 21 m memory but in the profiler shows 42. It’s somehow duplicating
but the original textures, the image files are the same size as you select them in the options? so they need to be 1024x1024 if you select 1024x1024.
obviously smaller textures means lower quality textures in the game.
I don’t know about that duplicate thing. maybe build one single scene with one texture manually placed and see how it behaves.
Sorry, not really sure what you mean
What he means is you import your textures as high resolution as you can and set the resolution you intend on your target device. But it is impossible without special tools to make a low resolution texture to become high resolution.
Which means if you import a texture which is 512x512 on disk, you don’t want to use it as a 1024x1024.
What’s also important is to keep Read/Write disabled as default and only tick it when you know you will have to make changes. That increases the memory consumption. (Doubles it).
Also if you want memory but not performance, then keep the mipmaps off, that uses ~33% more memory.
And read this through in general: https://docs.unity3d.com/Manual/ImportingTextures.html
And this: https://docs.unity3d.com/Manual/OptimizingGraphicsPerformance.html
If it’s applicable, you may want to think about texture streaming: https://docs.unity3d.com/Manual/svt-streaming-virtual-texturing.html
More specifically outside unity your texture needs to be of the pixel size format
128x128, 256x256, 512x512, 1024x1024, 2048x2048, 4096x4096
they textures need to have that size not a pixel more or less in height or width.
once you import the textures to unity you set the import settings dimension to the same value (or less)
if the numbers of the original texture and the settings coincide you get a way less reduction in textures size when loaded in memory.
then offcourse, depends how many textures you have, some GPUs have more or less memory.
ANYWAY 
I’ve bought an asset from the unity store, a realistic HDRP setup of an interior. Turns out that the author recomends having TWO GPUs installed to help with the light baking task. Exactly what your issue seem to be.
The size setting in the texture importer is the Max Size. Having that importer setting at a higher value than the actual texture file will not upscale the Texture.
That is a very common misconception that we are now working on a UI/UX and size Estimation calculation solution for (the UI/UX side is actually the bigger can of worms, as screen real estate in the importers is scarce, near holy, and there is not yet a clear answer to what platforms and graphics APIs you are targeting). It actually shows the resulting disk size, not the size it will take in memory on the target device and graphics API.
Anyways, the advice here holds: disable read write as it doubles, Mindmaps add overhead too, and a compression setting that is incompatible with the graphics API/ Shader Model version compatibility will cause the texture to be loaded into memory in uncompressed form.
Also memory usage in the editor can be vastly different to memory usage in a Player, so be sure to capture memory info while the Memory Profiler is connected to a Player too. Not that that will necessarily help you reduce memory usage in the Editor when that is the only concrete issue here.
Also, 1880 textures is also just a pretty high amount of them. You might have to go through these and see if you need all of them in memory at the same time, find out why they are in memory and if they all need to be there etc…
Thank You for the clarifications, I’ve based my assumptions on the UI info lol. if that is not precise then assumptions are wrong.
Read/write is disable in all of the texture, however I can see in the preview of a textures showing 21.3 mb and in the memory profiler 42.7 mb.
In some of my textures the author used a plugin, “amplify shader” which could be the issue for using extra memory.
Yes I even have more than 2k textures some times, but how can I control the loading time of the textures? only via Mipmap streaming?
As I mentioned, the size in the preview view in the inspector is disk size, not memory size. Until we add that size-estimation-on-target UI to the inspector, the only way to get the size in memory is by taking memory snapshots from a build running on your target platform.
The shader used or the tool that created the texture shouldn’t matter, unless it maybe chose suboptimal importer settings for you. Since you’ve already checked the usual suspect, aka R/W enabled, maybe the Texture Format is incompatible with the device or Graphics API and therefore your texture loads into memory in uncompressed raw fromat? Check this guide for platform specific Format choices. Also watch out for textures that have the full RGBA Format while not needing to be importet with transparency. Or maybe the disk size can just be compressed way further than the size it will have in memory.
Couldn’t find anything wrong.
The memory size gets reduce when I change the resolution in quality settings, but then of course I lose quality for the visuals, which is not optimal. From Full Res to Half, it went down to 7GB and it reduced the time to enter playmode (normal time is 30 seg, it went down to 20 seg).
I’d have to change the 4k textures to 1k to make a difference but that sucks.
I think I either go for that solution or to work with Mipmap Streaming.
Well, authoring high resolution texture based games is memory-intensive. You should consider upgrading your hardware too.
I’m also wondering how do you fit those 1880 textures into one scene. Are you absolutely sure you can’t break up your scene or switch to virtual texturing?
I can’t break up the scene, it’s just 1 map, it would be weird a transition. Don’t know about virtual texturing I’d have to look into it.
Yesterday I tried to bake lights and I almost burned my GPU, of course it failed causing Unity to crash and then there was a pixelated cube in the middle of my screen. Scary to try it again.
If this is UI Textures, then use Atlas
Hi There, is this thread still on going? I wanted to ask does a Texture Memory of 10Gb for an APK is too much? Because that’s what I see in my Profiler. @MartinTilo
curios how the games behaves on the device
I’m not aware of too many Android devices with enough VRAM to deal with 10GB of textures. Unless that’s a typo and not APK but APP and as the thread opening post the amount used by the Editor. Or is it the build report reported size for all textures that went into the build? Also what Unity and Package version are we talking about and what’s the overall context?
We’re using Unity 2020.3.38f, and yes, My Team is making an APK on Android and somehow when we check our Profiler to know why it kept crash on our Android devices, we noticed two things:
Does keeping images pixel size to the power of two (512x512, etc) will help that problem, or is there any other settings do I need to check? Our game is 2D, so our gameObjects are mainly textures and sprites.
The only texture that are above 2048 size are our maps (up to 8k) but we also have reduced its size to only 1MB.
The gameplay is only going around talking to people learning stuff without any additional gameplay. We’re making a 2D game. so, our game consist of mainly textures and sprites.
