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.
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.
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
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?
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.
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…
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.