freezeActiveMeshes() disables actions, decals, particleSystem, etc

[kurhlaa]

Hello,

I've got info that both setting all meshes as active and calling freezeActiveMeshes() should improve the performance, because it turns off some expensive calculations. So I tried to implement this feature.

But in my case:

1. If I only call mesh.alwaysSelectAsActiveMesh = true for all meshes - DebugLayer shows smaller potential FPS, by ~100. Should it be like that? I have <100 meshes, nothing very complex. Maybe disabling detecting visible meshes enables some other expensive calculations?!

 

Then I thought that freezing should help with that. But that gave me 2 more problems

2. If I use AssetsManager -> addMeshTask -> loader.onFinish() -> scene.freezeActiveMeshes() I get an error: 

TypeError: Cannot read property '0' of undefined
    at t.isInFrustum (babylon.js:8)
    at t.isInFrustum (babylon.js:8)
    at r.i.isInFrustum (babylon.js:9)
    at r.isInFrustum (babylon.js:15)
    at i._evaluateActiveMeshes (babylon.js:13)
    at i.freezeActiveMeshes (babylon.js:13)
    at i.Game.loader.onFinish (index.js:64)
    at i._decreaseWaitingTasksCount (babylon.js:48)
    at i (babylon.js:48)
    at i.e.onDoneCallback (babylon.js:48)

What does it mean? In my example - http://www.babylonjs-playground.com/#MPS90E#6 - try to uncomment Line 28 to get the same error. I was hoping to freeze active meshes right after they all were loaded.

 

3. If I put scene.freezeActiveMeshes() somewhere later - all my actions are disabled/removed, nothing happens when one mesh intersects some other, creation of decals also disappears, particleSystem also doesn't work. Some kind of "freeze the world". Example with intersections only - http://www.babylonjs-playground.com/#MPS90E#6

You see a moving red mesh - when it exits from yellow mesh - "intersection" should appear in the console. But after the first time scene.freezeActiveMeshes() is called and nothing is printed out any more. If you comment out the line 93 - every iteration prints "intersection".

 

Can you please explain what am I doing wrong in these 3 questions and how to fix them?

Thanks!

[Guest]

Hey!

1. It depends on your computer. Having 100 meshes could be a lot as every mesh needs to compute world matrix and check frustum clipping. You can try to use F12 profiler to understand where the CPU is mostly used

2. This is a stupid bug. I'll make sure to fix it for the next commit

3. When the scene is frozen, the entire evaluation loop is skipped, this means that: 

- Intersections are no more computed: https://github.com/BabylonJS/Babylon.js/blob/master/src/babylon.scene.ts#L3318

- Particles are not processed: https://github.com/BabylonJS/Babylon.js/blob/master/src/babylon.scene.ts#L3347

Decals should work though.

 

In you case it will be better to use mesh.freeze() and mesh.alwaysSelectAsActiveMesh = true to only skip world matrix computation and frustum culling

[kurhlaa]

@Deltakosh,

Thanks, with 2. and 3. no more questions. 

Can you give more info about 1. ? When it increases FPS and when decreases? I've just tried to use Chromium profiling tools, I'm not an expert in such things, but with mesh.alwaysSelectAsActiveMesh = true and without I have more or less the same % numbers for the functions _evaluateActiveMeshes and i.computeWorldMatrix. Top CPU users are mostly functions with "render" in their names, it doesn't give me more debug info. If I disable detecting active meshes with mesh.alwaysSelectAsActiveMesh = true - shouldn't percentage numbers for these 2 functions become close to 0 ? That would give a higher FPS, but I get lower.

 

Also I haven't found a function mesh.freeze() - PG says TypeError: scene.getMeshByName(...).freeze is not a function. What is a correct name?

[Vorion]

I think he meant mesh.freezeWorldMatrix(). The function freeze() is only used for materials, as far as I know. You can find some info here: https://doc.babylonjs.com/how_to/optimizing_your_scene

[Guest]

Yes lol thanks @Vorion, I'm getting old

@kurhlaado you mind sharing your scene somewhere? (with a reference to babylon.max.js for debugging purposes)

[kurhlaa]

@Deltakosh, I've learned to use a free hosting 000webhostapp.com for you

I've prepared a demo with 3 variations. DebugLayer included. While trying to move to the same position and watching in the same direction somewhere to the right I get:

1. Slowest - https://bjsdemo.000webhostapp.com/slowest/ -  Potential FPS ~300-400, with mesh.alwaysSelectAsActiveMesh = true;

2. Medium - https://bjsdemo.000webhostapp.com/medium/ - Potential FPS ~400-500, without mesh.alwaysSelectAsActiveMesh = true;

3. Fastest -  https://bjsdemo.000webhostapp.com/fastest/ -    Potential FPS ~500-700, without mesh.alwaysSelectAsActiveMesh = true; and with mesh.freezeWorldMatrix(); meshes.material.freeze();

 

.. lines 117-119.

Partly I understand why Nr. 3. is the fastest out of this examples, mesh.freezeWorldMatrix() and material.freeze() really help. The strange thing is with the difference between Nr.1 and Nr.2. I believe alwaysSelectAsActiveMesh should improve the FPS even more, somehow.

 

P.S. Hosting provider says "Your website will be sleeping for 1 hour from 22:00 to 23:00 every day your local time (GMT +2)" - funny please don't be surprised if this demo is somewhen down.

[Guest]

The small difference between 11 and 2 is because getWorldMatrix is low in the Call tree

based on this call tree,  you should probably consider using instances or reducing the number of different materials to get more FPS