Weird error from babylon 4.1.0.beta-*

As the title is saying, I have a strange error in the code, which apear from time to time, because of this it is hard to track it. Today I wanted to isolate it but quess what, it never come so I said ok, it is gone, and right now it happened again :slight_smile:

I’m still trying to isolate, I’ll try to repo in codesandbox too.

This looks like a race condition where you would call into getAttributeLocationByName before the effect is compiled.

Could you try to turn parallelShaderCompilation off to see if the issues goes away (to grab more feedback) ?

I am really wondering how this would be possible thought and it is probably not related to es6 in this case.

Could you try to turn parallelShaderCompilation off to see if the issues goes away (to grab more feedback) ?

Can you please tell me how to do this? :slight_smile:

So if I understood well, I’m trying to get a material using scene.getMaterialByName when it is not ready, or something like this?

And yes, maybe it is not related to es6 modules, but I’m using them, so I thought it is an important info. I’ll edit the name later

So you can do : engine.getCaps().parallelShaderCompile = null; to turn the async compile off.

This should give us a great hint of the issue.

And about ES6, you are right to precise cause in other cases we could have looked for ages due to a missing dependency.

same here:

Wait! I may have an idea!

Ok I will push a potential fix for next nightly :slight_smile:

1 Like

Hi, sorry for late :yum:
I added this

engine.getCaps().parallelShaderCompile = null;

and I tried for aprox 30 mins and no more error. But I’m still not sure it was totaly gone :slight_smile:
And I’m waiting for the fix too. Cheers!

I just tried 4.1.0-beta.9 but i still get the same error :frowning:

I added some logging to the babylonjs sources to analyze the issue.
Here some things i found:

  • _executeWhenRenderingStateIsCompiled executes to late for the effect (after it was rendered)
  • isReader() of the effect returns false but it still gets rendered
  • the _wasPreviouslyReady flag of the PBR material is true even if the effect itself is not ready

The problem here seems to be related to this line of the PBR material:

Some background information about our app:

  • after loading/creating a material i directly freeze it
  • materials never get modified afterwards
  • materials are shared between several meshes

even with this new information i was not able to reproduce it in playground … i hate race conditions, they are horrible to debug :slightly_smiling_face:

It’s not really possible, _wasPreviouslyReady is set to true at the very end of isReadyForSubMesh (so when the effect is built and ready) and the only other reference to it is what you have shown at the beginning of isReadyForSubMesh:

    public isReadyForSubMesh(mesh: AbstractMesh, subMesh: SubMesh, useInstances?: boolean): boolean {
        if (subMesh.effect && this.isFrozen) {
            if (this._wasPreviouslyReady) {
                return true;

i know that but this is what is happening according to my logs

Can’t agree more.

I have no idea how your issue could happen. Everything seems to be at the right place

Let’s try this: Can you make sure to call freeze on the material ONLY after the isReady is true?

Let me try something else :slight_smile:

I did a short test and removed the freeze() call directly after a material was created. Instead i just used a timeout to freeze them some seconds later to be sure that they are ready. This way there is no error.

FYI: version 4.1.0-beta.12 does not help

1 Like

Well so I have no idea :frowning:
At least you are unlocked but I would have loved to get my hands on a repro

If i have time i will try again to repro it. If that doesn’t work, would it help if i create a link for you to a small app from us which is referencing the babylon.max.js ?


Version 4.1.0-beta.16 solves the issue for me :grin: