Hello,
I am creating a Facebook Instant game and I am currently having an issue where the browser gives me and OOM exception. I’ve increased the heap size to 1024 in the project settings.
The build itself is 30MB large. I have 3 atlases (created in the Defold engine) with sizes of: 2048x2048, 8192x4096 and 8192x8192. Could the atlas sizes be the reason why it is running out of memory?
Thanks!
Oh yes, this is definitely the reason. The 8192x8192 atlas is a whopping 268MB+30% more if you have mipmaps enabled. You can reduce the size (both runtime and on disk) by enabling texture compression.
As we currently don’t support any compressed textures to the GPU on HTML5, it will still take up a lot of memory there though. And we’ll unpack it when loading it, so we’ll still need that memory.
Ah, thanks for the clarification!
So the texture compression methods do not apply here?
And the only thing I can do is make sprites with lower resolution before importing them into Defold?
Yes, and no.
It does affect download size which is very important too for web games.
Think of it as an alternative zip compression.
But currently, we don’t support texture compression when uploading to WebGL.
We have in our backlog to update our texture compression library, and this will make it possible for us to use GPU texture compression.
This is currently the result. So the compressed column shows the size of the download, correct? But if used in game and loaded into ram, it uses Uncompressed. And currently it is not possible to reduce the Uncompressed memory usage except simply making smaller resolution sprites?
If I used a tilemap for each animation instead (so I would have 14 tilemaps since I have 14 characters), it would still not help me, correct? If all of the characters were visible on the screen at one time. Since instead of using a big 8K atlas vs using multiple 1K textures, won’t make a difference.
Another thing I find interesting though is that the max size is 540MB. However, I set the heap size to 1024 for HTML5. And I still got the OOM exception.
This is currently the result. So the compressed column shows the size of the download, correct? But if used in game and loaded into ram, it uses Uncompressed
Correct.
And currently it is not possible to reduce the Uncompressed memory usage except simply making smaller resolution sprites?
There is an option to set a max size of the resulting atlas texture, but that’s about it.
Well 14 1K atlases are 56mb = (1024 x 1024 x 4 x 14)/(1024 x 1024)
A single 8K texture is 256mb = (8192 x 8192 x 4)/(1024 x 1024)
(a 8K texture fits 64 1K textures)
So that would definitely save memory. But…
When splitting into multiple atlases, you also need to consider the number of draw calls as well.
By setting the max size for atlas, will it downscale it then? If the resulting atlas would by default be 8K, it would automatically resize it to 2K while leaving all of the animations in?
Yes
I set the resolution to 2048 and got the size down very low. But oh my does it look horrible.
Are you telling me that if I set compression to Best and Type o Webp, it won’t make a difference for the Facebook Instant Games? Only changing max texture size and mip maps does?
Setting compression to Best and Type to Webp seems to have increased the memory footprint, however the animations still look very blurry. I wonder why did the memory footprint change even though the compression methods shouldn’t work with HTML5 build?
So I tried setting max texture size to 4096 with compression level normal and type Webp.
This resulted in a build like this:
Then I was thinking…wait a minute…how is it possible that if I now were to increase the max texture size to 8192, 1.78MB suddenly becomes 300MB. So I tried setting max texture size to 8192. I made the build and this is the result:
My question is: how is it suddenly only 7.50MB?
My issue is: when I run this in browser, I again get the OOM exception. It shows that uncompressed size is 7.50MB yet I get OOM. Perhaps it is bugged and should instead show the 540MB like before? Or is this the size that would be if the actual compression worked? If yes then why does it show the size like it would be if it was compressed when it actually isn’t compressed?
Thanks!
It’s hard to follow along with all of the tests you’ve made. Can you share the settings you have for texture compression and the output from the report? It sounds quite unlikely that 540MB worth of assets would be only 7.5MB uncompressed, unless you have changed max texture size to something very small.
But I have to ask, you’re making a Facebook Instant game right? Application size and startup speed is really important. Do you really need that amount of textures? Is there some optimizations to be made? Can you have adjust the size of all/some of your art? Can you use Live Update to download additional content once the game is running?
Hey, yes.
These are the settings for 7.50MB build:
And this is the output:
I am already reducing sprite sizes and it seems to work. It’s just that the images get blurry.
I’m actually not sure what’s going on there. Sorry. Can you share a project with the atlas and your texture compression settings so that we can try?
Alright, I sent you a pm. Thanks!
Tip: check the amount of used memory in the profiler (only Win/mac/Linux).
I suppose the HTML5 build uses the same amount of memory or about that.
