Using GLTFLoader to load models causes high memory usage, suspected of not releasing memory in time. about three.js HOT 6 CLOSED

@xingxiang1227 high resolution images consume an enormous amount of memory. With TextureLoader, the compressed image is held in CPU memory, and the first time it's rendered, the WebGL API is blocked while decompressing and uploading it to the GPU. For a 4K texture that's 90 MB of memory.

The reason we use ImageBitmapLoader is that it moves the decompression off the main thread, allowing us to block rendering for a shorter amount of time. The memory cost on the GPU is the same. I'm unsure of the difference in CPU memory, or whether Chrome's Task Manager is able to measure both accurately.

Additionally, the Web Workers used to decode Draco-compressed data will need some unknown amount of CPU memory.

You can opt out of both in your own application – for example, using TextureLoader or (better yet) KTX2 compressed textures. See my blog post, Choosing Texture Formats for WebGL and WebGPU, for more on that. Or you can skip using Draco compression in favor of lighter-weight Meshopt compression or quantization.

These all have tradeoffs, among which CPU memory is just one, so I'm not sure there's much we can change about the Editor here. If you're having particular problems managing memory in your own application, please feel welcome to start a thread in https://discourse.threejs.org/ and we can probably help you optimize memory there.

from three.js.

The editor may be saving the textures as jpeg into indexedDB. Is that what you're trying to report?
And... Is 290,068 kb really high memory usage for you?

from three.js.

Might be related to the Web Workers spawned and WASM allocated while decoding Draco compression. I'm not sure if the editor keeps those workers around for reuse, or disposes them eventually. For this particular model, the geometry is not that heavy – Meshopt compression might be more appropriate.

This model also contains two 4K textures, with estimated GPU memory cost of 90 MB each. My confidence is low that Chrome's tab manager reports GPU memory accurately, but the numbers here do seem within reason.

from three.js.

The editor may be saving the textures as jpeg into indexedDB. Is that what you're trying to report? And... Is 290,068 kb really high memory usage for you?

Hello, in my actual project, a 150MB model, when loaded through GLTFLoader, ultimately occupies 3GB of memory, whereas when stored through indexedDB and rendered again, it only occupies around 700MB. Is there room for optimization in memory management when using GLTFLoader for loading?

from three.js.

Might be related to the Web Workers spawned and WASM allocated while decoding Draco compression. I'm not sure if the editor keeps those workers around for reuse, or disposes them eventually. For this particular model, the geometry is not that heavy – Meshopt compression might be more appropriate.

This model also contains two 4K textures, with estimated GPU memory cost of 90 MB each. My confidence is low that Chrome's tab manager reports GPU memory accurately, but the numbers here do seem within reason.

After my testing, for models with many textures, the memory usage when using GLTFLoader for loading is much higher than that after conversion through indexedDB. Is there room for optimization in memory management when using GLTFLoader?

from three.js.

In the GLTFLoader.js file, within the GLTFParser class, the textures are loaded using this.textureLoader = new ImageBitmapLoader( this.options.manager ), which results in a high memory footprint. After I replaced it with this.textureLoader = new TextureLoader( this.options.manager ), the memory usage became normal. The memory consumption of the former is about 6 times that of the latter. Is there a way to optimize the memory usage of ImageBitmapLoader?

from three.js.