CPU Optimizations for animated meshes

I will do that and see if it helps.
On the playground most of the meshes are disabled, the rest of the meshes are tools, weapons, pieces of armor, etc. If you want to have a look at what I mean, you can see the different mesh names by viewing the playerMeshes array in the dev console. To see one, just call player1.meshes[‘sword’].setEnabled(true); and replace sword with whatever mesh name you want to see.

I originally did it this way because it seemed like the most forward approach, and allows me to modify the materials much easier.

I will combine it into 1 mesh and just modify the materials another way I guess.

1 Like

Ideally if you can replicate in a obvious way the slow down in the PG it could help a lot

Here’s the best I could come up with:
https://playground.babylonjs.com/#J1TBLL#3

If you pointer lock and then rotate your camera, you will see a CPU spike. For me it’s from about 55% to about 70% CPU usage.

Here’s a demonstration:

In the production environment there’s a bit more going on, so in production it’ll sit at around 55% but then jump up to over 90%.

Since the pointerMovePredicate isn’t having a strong effect, maybe it has to do with the Universal camera? Maybe there’s an event that’s called on the camera rotate that picks or something CPU heavy? I have experienced rotate lag in Firefox when pointer moving/camera rotating. I’ve also seen many other posts with similar issues, but none of the ones I’ve seen have had a solution

So a few questions to narrow it down:

  • Does it happen without pointerlock?
  • Does it happen if debug tools (f12) is not open?

I can’t reproduce what you show in your video, I stay around 60% CPU all the time.

What if you freeze everything (meshes, materials)? Does the CPU still spike?

Would you be able to reproduce the quick moves of the mouse but programmatically, to see if the problem comes from the mouse itself or from the quick moves?

Also, what if you disable picking in the PG?

  • Does it happen without pointerlock?
    Yes, just tested it and it seems the same without pointerlock.

  • Does it happen if debug tools (f12) is not open?
    Yes, it actually feels more laggy with debug tools closed.

I froze meshes, materials, and mesh world matrices:
Babylon.js Playground (this example also doesn’t pointerlock)

The scene sits at around ~35% cpu and when I rotate the camera it jumps up to ~55%.

Programmatically rotating the camera seems to not cause lag:
https://playground.babylonjs.com/#Q9882J#1

If I add the code Deltakosh mentioned:
scene.pointerMovePredicate = function() {
return false;
}

The lag still exists when I move the mouse with my pointer. I’m not sure how to disable picking in the scene entirely.

Based on these tests it seems to me like there is something (probably picking) being called somewhere in the pointermove call stack, that is outside of the pointermove predicate.

Have you tried to disable picking with this code:

    scene.onPrePointerObservable.add((pointerInfo) => {
        pointerInfo.skipOnPointerObservable = true;
    });

Yes, but that disables pointer moving entirely, so it’s not a viable solution

Ok, just for the sake of testing, can you try to add this:

BABYLON.Scene.prototype._internalPick = function() {
    return new BABYLON.PickingInfo();
}

This way we will be sure nothing related to picking will be executed.

Hmmm… doesn’t seem to effect it…

So it seems the picking is not the problem…

Have you tried to profile in Chrome what happens when there’s the problem?

lag

evaluateactivemeshes can be completely wiped out by calling scene.freezeActiveMeshes()

that’s worth a try

1 Like

The graphical parts of your game can primarily impact on two systems of the computer: the GPU and the CPU. The first rule of any optimization is to find where the performance problem is, because strategies for optimizing for GPU vs. CPU are quite different (and can even be opposite - for example, it’s quite common to make the GPU do more work while optimizing for CPU, and vice versa).

Common bottlenecks and ways to check for them:

  • GPU is often limited by fillrate or memory bandwidth.
    • Lower the display resolution and run the game. If a lower display resolution makes the game run faster, you may be limited by fillrate on the GPU.
  • CPU is often limited by the number of batches that need to be rendered.
    • Check “batches” in the Rendering Statistics window. The more batches are being rendered, the higher the cost to the CPU.

Less-common bottlenecks:

  • The GPU has too many vertices to process. The number of vertices that is acceptable to ensure good performance depends on the GPU and the complexity of vertex shaders
    . Generally speaking, aim for no more than 100,000 vertices on mobile. A PC manages well even with several million vertices, but it is still good practice to keep this number as low as possible through optimization.
  • The CPU has too many vertices to process. This could be in skinned meshes, cloth simulation, particles, or other game objects and meshes. As above, it is generally good practice to keep this number as low as possible without compromising game quality. See the section on CPU optimization below for guidance on how to do this.
1 Like

Thank you for the detailed response. I have a decent understanding of the underlying principals, I just don’t know the best way to apply them in Babylon. Your links are Unity specific, so they aren’t very useful for this example, although it’s looking more and more like converting to Unity will be my best bet.

Anyways, just wanted to bump this thread in case anyone has any idea what could be causing this. Still having the same issues. I did try reverting my local repo back to 6 months ago when this problem didn’t exist (and the old single mesh player model was in the game), and the lag is occurring. This proves that the player model isn’t causing the lag, and is leading me to believe that it could be a Chrome issue, but I also have no way of proving that.

Problem still occurs :face_with_head_bandage:

This is almost impossible to help you without a solid repro in the pg that we can profile. Or even a repro on your game with a reference to babylon.max.js

Something we can see and not just imagine :frowning:

Do you not have a CPU spike in the PGs that I posted previously?

And I’m not sure what you mean by: “Or even a repro on your game with a reference to babylon.max.js” Are you saying to add babylon.max.js as an import so you can diagnose it? Would it not be possible to do that via console?

Here’s a video that shows the problem as clearly as I can show it:

Well I cannot debug a video :smiley: And no I see no spike in your PG unfortunately