How to avoid Chrome crash when loading a lot of glb models？

Questions
,
1

Hello everyone!
When I load some ktx2 packed glb models with the babylonjs.loaders.js,I found that,for each glb model the loader will open a worker thread and load two js files from the server:

image
image1369×916 114 KB

Then if the quantity of models gets larger the Chrome browser may crash!
Then I try to make some adjustments on the babylonjs.loaders.js’s GLTFValidation.ValidateAsync function:
image
image1393×449 34.6 KB

After this adjustment,the validator’s loading reduce to a reasonable extent：
image
image1366×761 78.8 KB

This problem was dealt with temporarily,although the quesition still exist——is there a
formal approach to set the loader’s threads number,or is there a official threads pool to load models efficiently？
Another quesition is,What parameters do I need to adjust if I want to put all the models in the browser’s cache?So I can reload them from the hard disk with the 304 response code instead of download from web server.
Thank you for reading.

2

Hey there! I think the possible issue with having a pool of workers in the validation is that, if a worker was not available, we would have to wait for the load. I’m not sure if this would be desirable in the general case. But maybe we could add an option in the GLTF loader for a pool of workers, or even to skip the validation altogether? :thinking: What do you think @sebavan @Evgeni_Popov ?

We have a section on caching here Optimizing Using Cached Resources | Babylon.js Documentation (babylonjs.com) through it might change soon as IndexedDB support is getting revamped :slight_smile:

3

Are they never closing or is it because you have too many in parallel ?

It anyway feels like a bug to me. @bghgary what do you think ?

4

Do you have the inspector loaded? glTF validation should be off by default. The inspector code enables the validation if included.

KTX2, Draco, etc. both use the AutoReleaseWorkerPool which will automatically release the worker if idle for 1 second by default. Each can use up to 4 workers by default typically.

We can probably also do this for the validation, but it probably shouldn’t be running to begin with.

We can also maybe add a max total workers somewhere to ensure we don’t exceed a certain number of workers.

2 Likes
5

I suggest:

  1. expose the worker pool for arbitrary user defined tasks and possibly put it in its own package.

  2. checking navigator.hardwareConcurrency for thread pool size by default , possibly overridable.

6

Both of these are already there with the exception of being in its own package.

7

Thanks.You’re right!I exactly use the babylon.inspector.bundle.js in this program.When I remove the inspector the loading times of the blob becomes the same as the ktx2Decoder,and the gltf_validator.js won’t be load.

1 Like
8

For the caching,I have tried as the doc,but I don’t know if I’m right.
First,I add “BABYLON.Database.IDBStorageEnabled = true;” in the code.Then I found the browser want to load for example the Tile_+000_+000-19-tc.glb.manifest?1674262066384 url.
So I create Tile_+000_+000-19-tc.glb.manifest with content：
“{
“version” : 1,
“enableSceneOffline” : true,
“enableTexturesOffline” : true
}”
Next,when I load this scene again,the response is :

image
image1607×615 48.9 KB

The manifest is loaded well,but the glb is loaded no difference from others.And the response code is still 200 too!

9

The IDB support is only for .babylon format scenes and for textures, not for .glbs :frowning: So if you want to cache glbs you’d have to have a separate solution. Maybe look into Using Service Workers - Web APIs | MDN (mozilla.org)?

1 Like
10

Thank you for reply!
I have try as the doc you gave me.It seems like that,the babylon loader can treat the glb like a texture,and can load it from the hard disk.
But the question is,if I want to load more than one glbs,the loader can only cache the last glb offline.I have open an other question for this,could you do me a favour at there?