Slow GLB load times, Shaders compiling when updating textures

Questions
1

Hi All, trying to figure out ways to speed up loading our GLBs. (ps, right now everything is on localhost so there is no CDN ) We have a bunch of assets that we load via AssetManager using a bunch of asestContainer tasks. What we are seeing is while our AssetManager tasks finish pretty quickly (the individual meshes are pretty small and are also draco compressed). The time between when those tasks finish and when the mesh is displayed is pretty slow. We start the render loop when scene.whenReadyAsync resolves. We found that shaders are compiling which is causing the delay…

so why are the shaders compiling…
What we are doing is iterating through each loaded mesh and updating some textures on them and this is apparently what is causing the shaders to re-compile . Not updating textures will load a lot faster so teh texture update is marking the shaders as dirty I guess.

  • Is this to be expected? I woudln’t think a texture update would cause a re-compile?

Further exploring this, what I did was re-export all the loaded / configured geometry into one big fat GLB…essentially a ‘snapshot’ of the configured mesh. (using babylon’s glb export) and went ahead and draco compressed the GLB (using gltf-pipeline cli utility).

  • simply loading the snapshot glb with all the meshes and materials does load about 20% faster than when we were loading the mesh one piece at a time via assetsManager. However, its still relatively slow. When I try the same mesh in the babylon gltf sandbox I think its loading a little faster. Im not sure why the difference. All we are doing to load the GLB is simply
    containerTask.loadedContainer.addAllToScene();

So for comparison’s sake, I actually tried to load the same GLB using a three-js based GLTF viewer (https://gltf-viewer.donmccurdy.com/) and here the GLTF loads 2x-3x faster. Its wildly faster.

also, I ran it through the GLTF validation tool… no errors.

So obviously… its not the fault of the GLB…there is some overhead happening perhaps at the engine level… something is up. Are there any engine flags that need to be set or unset that could be causing the slowness? Or any other ideas.

Id love to be able to share the .glb asset but I am unable to do so publicly.

2

If there was no texture it will recompile but updating an existing (or replacing it) should not trigger a new compilation. Can you share a repro in the PG?

Regarding the speed of loading, let me add @bghgary

We will need to have a glb file to debug further (one that can highlight the issue)

Also we did several speed improvements recently so make sure to use v5.2 for your tests

3

I’ll try testing with v5.2 . Curious is the gltf sandbox using 5.2? https://sandbox.babylonjs.com/

Also yes, our incoming glbs are plain vanilla no textures. So that would explain it. One workaround is to stub in a dummy 1x1 texture for all appropriate material channels, perhaps pre-process the incoming glbs offline on disk before they are loaded. (id rather not have to force the artists to have to populate the texture channels manually)

4

yes Sandbox is on 5.2

and yes just having a dummy texture will totally help :slight_smile:

1 Like
5

we tested 5.2 with our model. Still a bit slow… sent you the model to look at. Thanks again!

2 Likes
6

@bghgary will check as soon as possible

2 Likes
7

Thank you David, much appreciated.

8

Hello just checking in, are you still having issues? @Anupam_Das

9

the issue has been resolved with fixes in Babylon 5.6.0 . see Loading time performance regression? - #53 by Anupam_Das

2 Likes