Behavioral change for 4.2

I set up my animation system under 4.1 to freeze the world matrices of all meshes & mesh instances to reduce the performance penalty of checking every single frame, especially for those with a parent(s).

Nothing moves outside of the systems control, so it is known when world matrix needs to be recalculated. When rotation or position change occur, freezeWorldMatrix() is explicitly called on the mesh or meshInstance as well as any children. This gets computeWorldMatrix() called one time, but it is still frozen.

I also “bundled” a _freeze() call in the initial matrix freeze. This occurs in a scene after render, because I found freezing a mesh before it is rendered at least once is problematic.


Fast forward to 4.2. The upshot is that nothing moves in the unusual case where a mesh has instances. I also noticed that calling _freeze() as well is required to get the behavior change to happen.

Here is the most simplified PG of the issue. If either the instance or the call to _freeze() is eliminated, then it works as before. I can probably override _freeze() since I am sub-classing both Mesh & MeshInstance, if required.

Can you help me understand what you would expect from this PG?
https://www.babylonjs-playground.com/#YBV4W7#5

I removed the _freeze (as this is a private function) and it seems to me it is working

I expect that when the pg is run on 4.2. alpha, that nothing moves, but if you switch version to 4.1 they do.

For diagnostics into what causes the change, one is remove _freeze (which you already saw), the other is removing the instance. I am thinking some of this thin instance changes for 4.2 react with _freeze to cause the one time compute either to not happen or block the effect.

They did move for me on 4.2:

It does not jump for me in 4.2, but it does in 4.1, so there is indeed a different behaviour between both versions.

Did you check my PG? it definitely jump on 4.2 :smiley:

Yes but you removed the _freeze call: @JCPalmer did say that commenting this line make the PG works :wink:

My point is it HAS to be removed. This should not stay as it is a private function
4.1 using _freeze was a hack no more required

1 Like

Having something that is no longer being required works for me. Perhaps gutting that function to be on the safe side might be good. It takes an edge case of also using instances and tightly controlling when matrices get computed to surface, but no reason to keep any lines in the function, or outright delete it for that “clean look”.