Preferred physics engine (cannon.js, ammo.js, DIY...)



Hi All,

Do you have a preferred physics engine? I’m planning to use one for a project I’m starting, but having never used one with Three.js before, I wanted to learn from the masters to hear what they’ve found best.

I’m basically building a very simple platformer-style microgame in which the character can also fly, in case that helps the decision.

Either way, I’d be curious to hear what others think about using a framework like cannon.js or ammo.js vs rolling your own physics. Any tips from experience are very welcome!


What should I use for collision detection in three.js (Physijs, cannon, only three.js)

I think it boils down to personal preference in coding style.

I’ve been using cannon for a bit but found that - no matter which engine you use - if you do everything on the main thread (not using workers), it’ll burn your performance quite a bit.

Only consider building your own physics engine if you want really simple stuff (no real physics). Otherwise you’ll go down an endless rabbit hole when you’re writing your solver… Trust me, I’ve been down that road (because I always want to build things myself) and ended up using cannon from a worker (threading) :stuck_out_tongue:


@Harold Do you have an example of “using cannon from a worker”? It’d be super helpful!


Here’s an example using cannonjs in a web worker:

The gist is that the worker writes all of the objects’ positions and rotations into a (Float32Array) array and sends array.buffer back to the main thread on each frame. If you have interactive elements (like VR controllers) this becomes a tradeoff, as collisions won’t feel as snappy when physics aren’t synced to VR rendering unless you use some tricks to update earlier. In my opinion the worker only becomes necessary when you have enough objects being simulated that it cuts into your FPS.

I’ve used CannonJS — it’s probably the best documented, which makes it easier to get started with, but isn’t maintained these days. AmmoJS is compiled from the classic Bullet engine, so that’s fully featured and stable, but quite a large library. Oimo.js is also worth a look, although I haven’t tried it.


I happen to be one of the crazy ones that went down the rabbit hole, and to be honest I think I like it here.

I tried out a few other implementations in my FPS, physx and cannon mainly. Cannon worked well for me, it was pretty snappy and looked really realistic, but it’s actually too realistic in that it becomes impossible to easily allow objects to move arbitrarily without constantly changing the physics. The gameplay in my FPS depends on quick fun movements so I had to throw it out.

It took me a good month just to work out the static mesh collision, and it works with moving objects too (I didn’t bother to implement angular momentum though), but it’s solid and quick, and better still I did it almost exclusively with three.js helper functions. Mr. Doob and friends supply almost all of the optimized code.

Was it worth the time it took me to figure out? Absolutely. It feels really good to have a custom engine that does exactly what you need it to do and nothing more, and because I had to understand it intimately to get it running, I have more power to bend it if I have to to be able to do other things, too.


Can you expand on that?

Gonna open source it? :smiley:


Can you expand on that?

Physics engines keep track (and manage) of object position, rotation, etc. If you want to change these manually, it’s usually quite a hassle to update them by hand. You’ll also have to tell whatever engine you’re using to reset things like velocity for the object you want to change the properties of.


I’ve also implemented a sliding-sphere collision, basically this kind of pseudo-physics is used by most games. It’s very fast on big geometries without threads, since it only deals with input velocity per frame, and solves the position with colliding faces.

While i’m mostly familiar with ammo/bullet, it’s seems demanding and the emsripten port using pointer objects doesn’t appear like very memory efficient, it makes it hard to do proper object pooling, but it’s very extensive and more solid/faster than some other engines.