Freezing unfreezing meshes

Questions
1

Hello! I’ve missed a lot while I was away for a long time, so I have a question:
Has anything changed in the implementation of (un)freezeMeshes? In my project, these two functions have become the bottleneck.

2

There might’ve been some churn around that area with Frame Graph and its implementation, but it would’ve been close to a year ago. What’s the bottleneck-- performance?

On a side note, welcome back!

3

The Frame Graph isn’t an option for me, it would require rewriting my existing code.

My scene contains a very large number of meshes. Merging isn’t a solution either, because I need to manipulate meshes individually in response to user actions (not per frame), for example showing/hiding groups of meshes, like floors in a building.

Simplified approach:

function setFloor(floorIndex: number) {
  scene.unfreezeActiveMeshes();
  applyFloorVisibility(floorIndex); // setEnabled / isVisible changes
  scene.onAfterRenderObservable.addOnce(() => {
    scene.freezeActiveMeshes();     // re-freeze after one full evaluation
  });
}

The bottleneck is the unfreezeActiveMeshes() / freezeActiveMeshes() calls themselves. I don’t need to freeze/unfreeze all active meshes, only a subset. Since both functions iterate over the entire scene.meshes array, and my mesh count is very high, calling them causes a visible rendering hitch on low-end mobile devices.

Is there a way to freeze/unfreeze only a subset of meshes, or to make these calls cheaper for large scenes?

4

Hmm, would overriding scene.getActiveMeshCandidates make sense for your use case? It returns scene.meshes by default but you could return the subset instead. Babylon does something similar internally.

Comparison: https://playground.babylonjs.com/#BOGC77#2

5

Thanks! I actually came across that post already. It’s quite old (from 2023), and I did some experiments with scene.getActiveMeshCandidates() back then.

Unfortunately, it was a while ago, so I don’t remember the exact reason why I abandoned that approach. If I recall correctly, it was something related to meshes losing their state between freezeActiveMeshes() and unfreezeActiveMeshes() when getActiveMeshCandidates() was overridden, but I’m not 100% sure.

I also remember seeing another forum post where someone ran into the same issue, but I haven’t been able to find it again.

For my use case, the real bottleneck is the time it takes to freeze and unfreeze the meshes. So I think it’s best to close this question for now. I’ll revisit the whole topic, redo my homework, and come back once I have a better understanding and some fresh data to share.