MarianG
December 7, 2019, 12:35pm
1
Hiey,
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
I’m still trying to isolate, I’ll try to repo in codesandbox too.
sebavan
December 9, 2019, 11:05am
2
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.
MarianG
December 9, 2019, 11:24am
3
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?
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.
Wait! I may have an idea!
Ok I will push a potential fix for next nightly
1 Like
Hi, sorry for late
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
And I’m waiting for the fix too. Cheers!
Kesshi
December 10, 2019, 6:48am
9
I just tried 4.1.0-beta.9 but i still get the same error
Kesshi
December 10, 2019, 7:58am
10
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:
/**
* Specifies that the submesh is ready to be used.
* @param mesh - BJS mesh.
* @param subMesh - A submesh of the BJS mesh. Used to check if it is ready.
* @param useInstances - Specifies that instances should be used.
* @returns - boolean indicating that the submesh is ready or not.
*/
public isReadyForSubMesh(mesh: AbstractMesh, subMesh: SubMesh, useInstances?: boolean): boolean {
if (subMesh.effect && this.isFrozen) {
if (this._wasPreviouslyReady) {
return true;
}
}
if (!subMesh._materialDefines) {
subMesh._materialDefines = new PBRMaterialDefines();
}
const defines = <PBRMaterialDefines>subMesh._materialDefines;
if (!this.checkReadyOnEveryCall && subMesh.effect) {
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
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;
}
}
Kesshi
December 10, 2019, 11:25am
12
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
Kesshi
December 12, 2019, 7:12am
16
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
At least you are unlocked but I would have loved to get my hands on a repro
Kesshi
December 13, 2019, 7:47am
18
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 ?
Kesshi
December 19, 2019, 9:02am
20
Version 4.1.0-beta.16 solves the issue for me
3 Likes