solved When is it safe to freeze materials?

[fenomas]

Hi,

I had some transparent textures that broke when updating to the current nightly build (from 3.2). After much searching, the problem seems to depend on the timing of when I call "mat.freeze()". Can someone confirm if this is a bug or not?

Specifics: in my project I create and set up my materials and textures at init, and then freeze the material. I delay the "freeze" call, to give Babylon a chance to initialize, but this is while the game is paused so no renders are taking place.

var mat = new BABYLON.StandardMaterial(name, scene)
// set some colors...

var tex = new BABYLON.Texture(url, scene, noMip, true, sampling)
tex.hasAlpha = true
mat.diffuseTexture = tex

// freeze material after a tick
setTimeout($ => { mat.freeze() }, 10)

In 3.2 this worked fine, but in 3.3 my transparent textures are broken. If I delay calling "mat.freeze()" until after the scene has rendered at least once, things work as in 3.3.

Bug or no? When is it safe to freeze materials?

Thanks!

[Guest]

I'm surprised that there is a change on that between 3.2 and 3.3

Do you mind reproducing in the PG?

As a rule of thumb, freezing is valid when mat.isReady() is true

[fenomas]

I can't easily reproduce this in the PG, as it seems to depend on the timing of when scene.render is called.

11 hours ago, Deltakosh said:

As a rule of thumb, freezing is valid when mat.isReady() is true

This looks promising, but mat.isReady() is never true - it returns false if no mesh argument is passed in.

Do I need to check isReady(mesh) for a mesh the material is used for? Or all of them?

[Guest]

yes you need to check for a mesh because materials are compiled per mesh. But if you plan to freeze a material it means that all meshes are compatible (ie. same way to use the material) so using just one with isReady will make it

[fenomas]

Hi, thanks for the response but it seems that things are more complicated than that.

I managed to make a PG that (probably?) replicates my issue:

http://www.babylonjs-playground.com/#8EMFCU

As you can see it creates a bunch of meshes, which all use the same material, and then freezes the material later on. The meshes become visible at various delays. The transparent texture breaks for some meshes, but not always the same ones - it seems to depend on whether or not the mesh has been rendered at the time when mat.freeze() is called?

 

[Guest]

This is expected. The mesh has to be rendered once before you can actually freeze the mat

[fenomas]

5 hours ago, Deltakosh said:

This is expected. The mesh has to be rendered once before you can actually freeze the mat

Per the PG, isReady(mesh) returns true even for meshes that haven't rendered yet.

Does that mean it's impossible to tell whether it's safe to freeze a material that is being used for multiple meshes?

[Guest]

You just need to wait for the mesh to have been rendered at least once because it requires to get data from the mat and if the mat is frozen the entire check is skipped.

Furthermore we all the latest update, the material freezing is no more a big deal regarding performance

[fenomas]

I understand that!  But with frustum culling there's no real way to be sure when a mesh has been rendered, right?

If there's no way to definitely know when this is safe, and it doesn't help performance, should it just be forgotten about?

[JCPalmer]

Seems like this is an obsolete optimization that was also too difficult to use.  BTW, for future reference,  Adding a mesh afterrender, which un-registers itself in the callback, is foolproof.

[Guest]

I think it is ok to say that you can ignore this property for now