Compressed textures are huge in ram - Crash

Hello,

we’ve got a problem that the iPad1 runs out of memory because the textures we use take up way too much ram. Somehow a compressed texture PVRTC 4 bit 1024x1024 of 0.7MB takes up 7MB of ram.

We use the following textures (All PO2, PVRTC) for a scene
2x 2048x2048 (texture atlas of the level)
4x 1024x1024
3x 1024x1024 lightmaps
Plus particles, gui.

Compressed they take up about 15MB. But on the iPad it’s about 90MB making the iPad one crash. Whats the point of having compressed textures when they take up just as much ram as uncompressed textures?

It appears that compressed textures become uncompressed in Vram. Is there anyway to prevent this? We just can’t use less texture space, else everything will be blurry.

Do you have them all Read/Write enabled? That’ll do it. But that’s not “VRAM”. Is profiling telling you that it’s actually GPU-related?

are you loading the pvr from www or through system.io and Texture2D LoadImage? In both cases the RAM usage will ‘explode’

What is the alternative to texture2D loadimage? But what about the textures applied to meshes through the editor? We don’t apply them with code. It’s just a standard texture with a mobile/unlit shader on it.

their not read/write.

There is no alternative if you want to load pvr. If you want to load it from the disk / WWW then it will always go through LoadImage, be it that you call it yourself or that you use WWW.texture or www.LoadImageIntoTexture, it does not matter, you will always get the 200-400% RAM hit (it varies from version to version a bit, in unity 3.0 it was in the range of 750% with a texture that uncompressed would have needed 1MB ate up over 12MB of RAM + VRAM)

The only way to get around it is storing color data and then make use of CreateImage, read the image data and manually apply them to the image.
But thats always a read-write enabled texture so 2x the data (once in VRAM, once in RAM) and its always uncompressed

But you can use " makeNoLongerReadable" to solve the read-write problem right?

And how about the textures applied on meshes in scenes? Why do they take up so much when we don’t manually load them through code?.

Right now it appears that the ipad 1 can only handle about 30mb of compressed textures because of the problems we have… Seems a bit weird.

because stuff present in scenes is loaded differently.

and the ipad1 can handle at maximum 100-120mb of RAM + VRAM, how you distribute it is up to you.

I tried using the quality settings to use half res textures on ipad 1 and full res on ipad 2 (since iPad 2 can run our game just fine). But there is no difference in ram usage…

So the only thing we can do is make lower resolution textures…

I know that to active mipmapping grow up faster compressed texture size.
We always got a lot of surprise about. This can reduce by 40% app size… This could also affect memory use in runtime, isn’t it?

If you disable mipmapping on each texture, what does the memory use says?

I disabled mip-mapping and made the textures 2 bit. It still takes up too much memory…

On PC (running in iphone mode) it takes up 30MB. On ipad 135+

Well, never though with low level on ipad texture…

But more a texture contient RGB data, more that is cost memory.
I mean that if you work with a low palet of color on a 2048 texture that should reduce the info stocked into the file and help for reading on iOS.

Well I really dunno about the iOS process, but I know that on PSP we do not deal with high texture size to reduce draw call but with lower color data into each single texture.
Vram on PSP is about a few meg then on a character we separate parts using common color :

  • skin on a texture
  • cloth from the same color on another one,
  • hair too on one more texture, etc…

Well it provide VERY small RGB info on each texture and help reducing used V-Ram.

As I said, dunno how the texture is read by the iOS thing, but I am sure you have a very high list of Color into your 2048 texture and it could be very heavy for the little ipad.
Well, imagine you separate your 2048 as the PSP way.
I accept that is very old school process, but experience can help from it o_<

To see how it works on iOS, try to paint all your texture with white first and one more test with all black.
That sound weird but that is very serious on PSP and past PSone, etc…

EDIT : also reading 2048 texture on iOS is GL2.0 support O_O… be careful with ipad!!

I had a scene once with about 50 mb of PVR compressed texture data running on the ipad as actually only using 50 mb of RAM for the textures. The size of PVR compressed should be the size of it in VRAM on the ipad.

So your doing something wrong…

When I made that scene, I did run into a bug, if you drop .pvr files into Unity, you need to do a little bit of a trick to get it to disable read/write because it is NOT disabled by default on .pvr files you drop into unity.

I explain this in this thread and post the code needed http://forum.unity3d.com/threads/105941-Lightmaps-using-twice-as-much-memory-as-expected.

If that doesn’t work. Make sure of these things:
Your watching memory usage through the xcode profile tools, not the unity profiler.
Make an empty project with nothing but your scene and your texture, compile it to the device and watch memory usage without texture, then watch it with textures in order to make sure it really is your textures…

How did you export your .pvr files?

We added your code to a C# file in the editor folder. When does it run? And where did you place the .pvr files?

Hi people,

thought I’d give you guys an update.

The problem has been solved. Textures do NOT take up too much ram. I was reading my profiling data wrong. The problem we had was that our low poly models had references to their high poly counterparts, making them huge in ram.

So, problem solved.