Hello Everyone,
In my project, I have some GLB’s loaded. There is a huge stutter and frame drops when models enter view. Is there a way to avoid this?
Turn around to look at the car and you’ll see how it lags:
After it has already been seen, there’s no stutter or frame drops.
I tried doing the things in this thread but it didn’t help:
In particular, I don’t know how to apply what is mentioned in post 20.
Any chance someone can explain this to me? How would I do that do my playground example?
Here is an example of tracking shader compilation calls; I just monkey patched the compilation function.
What I did involved trying to ensure all compilation calls occur during a preload step. I triggered compilation by running something along the lines of mesh.isReady(true, false). I had to make sure the correct material properties were assigned prior to running this, in order to ensure that the correct shader variant was compiled.
You can also log the full shader source and inspect that to see what variant is being generated, which basically amounts to inspecting the #defines and such. Overall, it wasn’t a very straightforward process and involved a lot inspection of shader source and the Babylon.js source code as well in order to figure out what causes specific shader flags to be set.
According to a post in the thread you referenced, material.forceCompilationAsync may work also but I didn’t test that at the time.
Thanks for getting back to me. I’m limited in terms of technical skill, but I tried to do what you mentioned and it seems everything compiles:
However the stutter is still there 
Loading GLB’s seems like a foundational thing most need to do and as far as I understand, my GLB isn’t that complex. How does everyone use models into their projects without the stutter?
For example, the Hill Valley demo has lots of models and when I look around, it’s buttery smooth:
https://www.babylonjs.com/demos/hillvalley/
Here is a version with the tracing enabled, and you’ll notice that when you turn the camera, it logs a bunch of new shader compilation events.
From what I can surmise, this seems to come from ImageProcessingConfigurationDefines applying some custom defines. Doing a diff of some shader compilations shows that these are some of the flags being modified to trigger a recompile. This may stem from something configured in the GLB model that is being loaded, and without a deep dive into the Babylon.js source, I’m not sure why these flags are only turned on later. Perhaps a contributor can chime in.
Thanks, I’m still looking into it, but the frame drops seem to be coming from an emissive material and some lights. I’m still trying to figure out how to have these without the lag.
cc @Evgeni_Popov our shader god
If you set compileMaterials on the loader, it will catch most of the shaders. I’m not sure what’s up wtih the materials that are not compiled beforehand yet.
The asset is using the KHR_material_transmission extension, which means we are creating a hidden RTT behind the scene to render opaque objects.
You can force compiling the materials used by this RTT this way:
You will see that when the car comes into view, there’s no new shader compilation, but it’s still stuttering.
The performance snapshot is something like this on my computer:
It’s the GPU timeline that takes a long time when there’s stuttering…
We’re not doing anything to explain why the GPU runs for 1.2 seconds continuously.
Maybe it’s the driver that doesn’t do anything until the mesh is visible?
I have to say that I don’t really understand this snapshot…
@vx9 Can you try taking apart your glb model into its subcomponents and then loading into the PG one subcomponent at a time? It will help to isolate, I’m guessing some hierarchy interactions with the scene lighting might be causing the stutter.
It seems it is a bit like in:
Even if in this case setting Angle to OpenGL does not fix completely the stuttering on my computer, it improves a lot (only a single small stuttering remains).
Also, there’s no stuttering in Firefox.
I disposed materials and lights to isolate the causes. It seems like there are two reasons: a small stutter results from lights parented to transformNodes. A large stutter results from some materials. I used Blender to make the GLB and the materials which cause problems are: 1. an image hooked up to emission node, 2. objects without materials assigned, and 3. a random material with something in it, I don’t know what, that causes problems.
See this with the problem elements removed:
Does anyone know what is the problem with the materials I disposed of in the array? (You can remove the dispose() to see them in inspector. And how can I use them and not have stutter?
And is there a way to get around the stutter that results from parenting lights to transformNodes? It doesn’t seem great, but perhaps use an onBeforeRender to sync positions of light with absolute position of the transformNodes? I’m not sure if that would create other problems.
The stuttering is from the Angle graphics backend that Chrome ships. I believe it was OpenGL prior, so if you switch it back and test your PG in the OP, there is no stuttering.
Type chrome://flags/ in chrome, type Angle to bring up the graphic backend option and switch to OpenGL, relaunch your browser and run your PG.
Hope it helps.
@Evgeni_Popov do we have a bug tracking this on Chromium as it could be a good candidate to follow. It is the second time we have been hit by this behavior.
Actually, the latest Chrome version fixed the problem (116.X)! There’s another thread about it somewhere.
I tested my PG again, and there’s no stuttering anymore:
YESSSSS !!! thanks a lot for the feedback
Amazing! Thanks everyone
