Author Topic: High memory consumption on mobile devices  (Read 7351 times)

Hey Guys,

me and my team having strange memory consumptions on iOS at the moment. Some of the .sbsar-files have a big file size. I have the feeling that the problem comes with our loading behavior in Unity. Could you please explain what are the "Load Behavior" settings in Unity (Do nothing, build on level load, bake and keep substance, bake and discard substance, use caching) ? We didn't found any explanation.

brgd.

Hey Guys,

me and my team having strange memory consumptions on iOS at the moment. Some of the .sbsar-files have a big file size. I have the feeling that the problem comes with our loading behavior in Unity. Could you please explain what are the "Load Behavior" settings in Unity (Do nothing, build on level load, bake and keep substance, bake and discard substance, use caching) ? We didn't found any explanation.

brgd.

Hello,

A large sbsar file would typically be because there are bitmaps embedded. Any bitmaps that are contained within the sbsar are embedded at the resolution set in Substance Designer. For example, if you are using 2K bitmaps, this will increase the size of the sbsar file.

It could also be the mipmap levels. The size of the sbsar should be relative to the embedded bitmaps unless the resolution of the substance differs from the resolution of the source texture. It won't add to the download size, but it will affect memory used by the app.

Here is an explanation of the Load Behavior settings.

Build On Level:

This setting will generate the substance every time a level needs it.

Bake and Keep:

This setting will bake the substance as a bitmap for fast loading, but will keep the substance source so that you can still work with the procedural parameters of the substance i.e. you can change the substance file

Bake and Discard:

This setting will bake the substance as bitmaps when building the game.

Use Caching:

This setting will generate the substance only once during the first loading then save it as a bitmap on the device. This is the best setting for mobile.


Cheers,

Wes


Integrations Product Manager / Training
wes.mcdermott@allegorithmic.com
Twitter: The3DNinja

Thanks Wes this was very helpful.

In addition i created a test file with a embedded bitmap (1024x1024) and a output (1024x1024). The file has a size of 8 mb in game. I put the Format to Compressed (which, if I'm right, would be automatically PVRTC 4Bit on iOS and Android), but it seems to be uncompressed. Do you have any idea what the problem could be? Is there some way to check that unity/substance really compressed the file/texture and what compressionformat it used?

Hi

What do you mean by "a test file with a embedded bitmap (1024x1024) and a output (1024x1024)", are you talking about an SBSAR file with an embedded bitmap? If so, then you should really tell Designer to embed a *compressed* bitmap instead of a RAW one, this will create a much smaller SBSAR file. You can do so by clicking on the bitmap resource in the package explorer.

Also, I'm not sure what you mean by "The file has a size of 8 mb in game", could you please clarify?

Last, to check what format a given texture was generated in, you can use some kind of GPU profiling/debugging tool to connect to your device and capture the frame that uses the texture you're interested in . For example, on a Tegra device, you can use Nvidia's PerfHUD ES to do so. I know that ARM (for Mali GPUs), ImgTech (for PowerVR GPUs) and Qualcomm (for Adreno GPUs) provide the same kind of tools, so you will have to pick the right one according to your device.

Best Regards,
Eric

Also, I'm not sure what you mean by "The file has a size of 8 mb in game", could you please clarify?

Was a problem occured a while ago. But anyway the answers were really helpful. One thing is still unclear to me. Could you explain what the Format "compressed" exactly means and if there is a case were it can't work right ?

'Compressed' tells the Substance engine to generate a compressed texture at runtime from the full RGBA output. Depending on the platform and on the GPU (for mobile platforms), a substance output set to 'Compressed' can end up being generated in DXT5, PVRTC1-4bpp, or RGBA4444. In the next version of Unity, "no-alpha" variants will be added so that DXT1 and ETC1 outputs can also be generated.

'RAW' means that no compression will be performed, and the full RGBA32 output will be used. The consequences are:
 - higher image quality (image compression algorithms are lossy and introduce artefacts)
 - no time will be spent compressing the image
 - higher memory footprint
 - higher bandwidth consumption when sending the texture to the GPU

I can't think of a way for the "compressed" mode to "not work". It will *always* pick a format at runtime and compress the substance output to that format, what do you mean by "can't work right" ?

Best Regards,
Eric

Okay your answer cleared up a bunch of questions. Many thanks!

With "not work", I meant a case like substance put a texture accidently to RBGA 16 Bit or something like that, but i had the ability to put it actually to PVRTC. But as you said, you cant think of a way it "couldn't work", so I belive you ^.^

Again many thanks for your fast & educational support.

brgds.

Sorry for reopening this topic, but one question occured. Is Substance only compressing the output texture or is it also compressing the embedded textures?

You can compress 8 bits embedded textures to jpeg.

currently I use .png . What exactly you mean by "to jpeg" ? From the start impl it as a jpeg data type? Bad thing is I need a transparency for the graphics.

Whatever file format the image came in, it will be embedded in the sbsar file either in raw (uncompressed) format or using jpeg compression.
If your image has transparency and you choose to embed it compressed, the color and alpha parts are actually compressed separately in the sbsar file, and are put together by the Substance engine automatically when rendering the substance file.