High VRAM issues

Hey guys,

I am facing VRAM issues, i.e its too high that the playcanvas app crashes on my Android phone. I have not faced this problem in any of my previous project except my most recent one, which is having a Vram of 800 Mb and around 500 Mb is being used by the vertex buffer.

Here the project with 800 Mb,

Total tricount is 410K

And in comparison, here is another similar project I did, having a VRAM of 307 MB:

As you can see the Vertex buffer is occupying just 17mb even though the tri count here is 390k so very similar to the BMW one.

I cant figure out this issue, as the total tricount is very similar but the VRAM is very high in BMW one as compared to the other one.

1 Like

Hi @Saad_Haider,

Yes, 800MB of VRAM is way too high for most mobile devices to handle. Most likely you are already using texture compression for your texture assets, is that correct?

Now for your BMW model a 522MB vertex buffer is unreasonably high, especially if your total polycount is only 410K. I am not sure what may be wrong here but I’d try disabling a couple of mesh instances in a modelling app and reimporting to see if that reduces the vertex buffer size.

Also are you using batching? That tends to increase the size of the vertex buffer.

1 Like

It seems the issue is on our side in glb loader, it creates duplicates of the same vertex buffer. I’ll investigate more today and hopefully fix it.


Hi Leo,

No I am not using Texture compression and there are merely only 3-4 textures,
I am also not using Batching.

The only difference between the two projects is that one is using the older json format while the newer one is using the Glb format.

1 Like

Experiencing the same issue in one of my project. It only contains 2d images but still vram size goes upto 1.5 gb and that’s too high.

@saif - what are the sizes of these textures? large textures can easily fill up vram, especially if they’re jpg or png and not compressed images.

@mvaligursky yes, my image sizes are high. Each image has size 4096x4096. Also i haven’t compressed them yet. I can’t lessen the size of the images but i will compress them and check whether they have effected the vram size or not.

@saif - each 4096x4096 textures is 16mb, or around 21mb if it uses mipmaps.
Compression often makes it larger size on disk (so download size is larger - compressed to jpg), but it takes 25-50% of the size in vram. So you trade download size vs vram size here. If you don’t need these textures at all time, maybe you can download them dynamically.

1 Like

The each texture i am using doesn’t exceed size from 150kb. So loading is not an issue. I guess i should go with the compression and then see the results.

Just to clarify more.
at the moment you have 4096x4096 texture, probably in jpg format. So these are the sizes:

  • download size: up to 150kb
  • vram size: 21mb

when you compress the same texture, you can expect sizes like this (depending on compression size):

  • download size: 5mb
  • vram size: 5mb (exactly the same)
  • additionally here you can configure your hosting to server these as .zip files, so you get some compression of the 5mb file which will help download size only (not vram size).
1 Like

@Saad_Haider - I have a fix for this here:

This should land in the engine release sometimes next week I think.

In the meantime, I’ve compressed your mesh into draco compressed glb file (file size 17MB -> 1.5MB) and this does not have the issue, and vram use is low. I used this tool to compress it for reference: https://github.com/CesiumGS/gltf-pipeline


Thank you! @mvaligursky

Will check out the mentioned tool

here’s an example of how to load draco compressed mesh in your project


@Saad_Haider - the engine release with the fix to excessive vram use for some glb files has been released.


@Leonidas and @yaustar: please read and/or feedback this

  • I think we can benefit by such a sector :slight_smile:
1 Like