Memory growth & WebGL context loss when streaming SOGS GSplat frame sequences (double-buffer, serial load)

[Heeekdl567]

I’m trying to play a sequence of SOGS GSplat frames in the browser (to approximate “4D” by swapping 3D frames). I have 50 frames and I'm using a double buffer to get a smooth transition between the frames. But after a while I always get the following error in Chrome.

Do you have any idea how to fix that?

[slimbuck]

Hi @Heeekdl567,

Every time a GS scene is loaded, the engine creates a sort web worker as well. The sorter is given the list of gaussian positions to sort and it looks like this allocation is resulting in OOM.

Can you check whether the number of webworkers in chrome devtools are growing as your progress through the animation? If so, then they're likely not being cleaned up correctly.

Thanks!

[Heeekdl567]

Hi @slimbuck,

thanks for the pointer. We checked in Chrome DevTools and can confirm that the number of web workers keeps increasing as the sequence plays. They never drop back down across frame swaps, which lines up with the OOM/context-loss we’re seeing.

We tried to workaround this on our side with the attached scripts (double-buffer player; strict serial loading; deferred unloads; device-loss gating; only current + next SOGS in memory). However, we still hit this crash during SOGS loading:

Uncaught (in promise) TypeError: Cannot read properties of null (reading 'readTextureAsync') at webgl-texture.js:520 at texture.js:437 at gsplat-sogs-data.js:17 ($E / prepareGpuData) at gsplat-sogs-data.js:278 (prepareGpuData) at sogs.js:86 (loadTextures)

(see screenshot)

At this point we’re not sure how to fix it in our app code. A few questions:

Is there a supported way to explicitly dispose the GSplat sorter worker when a gsplat asset/instance is unloaded or swapped out? (e.g. an API like instance.sorter.terminate() or best practice we should follow)

Is this a known issue with sorter workers not being cleaned up? If so, is there a patch/branch we can test?

Any guidance on the correct unload sequence for gsplat/SOGS (order of detaching assets, waiting for sorter events, etc.) to guarantee worker teardown?

Thanks in advance!

gsplatFramePlayerDoubleBuffer.esm.js main.js

[slimbuck]

Hi @Heeekdl567 ,

Are the sorter instances being correctly cleaned up now? Is the issue now that a texture is leaking?

I can't see anything obvious from a quick look at your script. As long as the gsplat component invokes destroy on the GSplatInstance you should be fine.

SuperSplat editor supports loading animated PLY sequences and this seems to handle those fine. I'm doing anything special there.

If you can provide me a repro I can investigate, this should be working.

Thanks!

[mvaligursky]

You could also try using those in 'unified' mode https://api.playcanvas.com/engine/classes/GSplatComponent.html#unified-rendering this creates a single sorter and so on, and loads / unloads data from it as needed.

[mvaligursky]

Closing this, the reference issue shows how to implement this.