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.
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.
@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.
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.