Performance regression

We are considering using cannon-es in three.js but seems like there’s a performance regression.

@Mugen87 converted cannon.js to modules and here’s the running example: https://raw.githack.com/mrdoob/three.js/dev/examples/physics_cannon_instancing.html

This is the same example using cannon-es: https://raw.githack.com/Mugen87/three.js/dev45/examples/physics_cannon_instancing.html

https://github.com/mrdoob/three.js/pull/19709

[marcofugaro]

Thanks for the issue and the usage example. This also looks related to #16. I’ll look into it soon!

[marcofugaro]

Hello friends, I’ve discovered the issue.

Basically there are tons or commit which are in the cannon.js repo but haven’t been published to npm or built into the cannon.js bundle. Here is the full list. When we built the source files again in cannon-es, we inherited automatically all those commits.

Between these commits there is 86b0444, where schteppe implemented the fixed timestepping from the last snippet of this famouse article, however it was left unfinished or was not tested properly, leading to the framerate issues.

I’ve tried to fix those issues in #40, but of course I’m not schteppe. If you guys @mrdoob and @Mugen87 could test with the cannon-es bundle from that branch that would be grand 🙏

Also @codynova issue #16 should be fixed as well, could you do a test? 🙏

@arpu is right, the third parameter is used to tell how many maximum internal steps the step() function can take if there is too much lag. If you set it to 1, it doesn’t take any internal steps, but the simulation is technically slower. If you set it to an high number, it takes as many steps as needed to make the interaction have a fixed timestep, however if the step is expensive (a lot of boxes), taking too many steps can cause lag by itself.