cool thanks!
Viewing post in Construct 3 3DObject Plugin comments
I see the crash. After a little research, it _may_ be a chrome bug that gets fixed in chrome 115 when available. I will keep an eye on this when that version releases.
https://stackoverflow.com/questions/75728569/web-worker-memory-leak-when-using-t...
This also may be another bug/issue with chrome and workers where they don't do reliable GC. In fact, I see that if I do manual forcing of GC through Chrome dev tools, I can stop the crash from happening.
I've seen bug reports on this, but no resolution in chrome yet. I will look at this one possible solution which requires the workers to be terminated and created again. I'm not sure what they will do w/ perf and we'll see if it's actually viable.
Yep its not fixed even in Chrome Canary which is 117, also tried as far back as Chromium 97 same results. Hope your fix helps!
EDIT: In the test that crashes with 250 objects, I was able to get up to 300 objects at 60fps without crashing if I split it up, 150 workers and 150 nonworkers. So having 2 of the same type of enemies in a Object Bank layer, I can split them up while spawning. Not perfect but works ok for now. Will try to see if prefab instances, destroying 3d objects offscreen and respawning onscreen helps with memory.
This is definitely an issue with worker GC not triggering when it should and not a direct memory leak.
I looked around for possible fixes and there is a complicated one that at least one developer has done where they terminate the worker after a certain amount of time and start a new one 'fresh'. I am not sure this is a good way to go yet, since they were only using one worker, not hundreds of workers like in this test case.
As you noticed, when there is less load in terms of the number of workers, the worker GC have time to activate and lower the memory requirements. As you note not a desired solution, but hopefully a work around for now. For example if in the test case, I delete 1/2 of the models and watch memory, I can se GC kick in on the workers as memory pressure rises. I do not see the same case with the screen full of models.
As a longer term project I will experiment with whether the tear down and worker creation idea would work (I need to do more like retain some of the state from the worker, so animations don't get messed up, so a few logistics to work out before I can start testing.)