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!

Doug

2 Likes

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:

2 Likes

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

1 Like

Here’s an example using cannonjs in a web worker: https://github.com/schteppe/cannon.js/blob/master/examples/worker.html

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.

9 Likes

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.

2 Likes

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.

1 Like

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.

I’ve been looking around for an engine I could use in future projects, and have found a few options that I thought I should share:

Possibly outdated libraries

If anybody has any additional suggestions for a simple box-collision engine, I’d appreciate other options!

3 Likes

Soo lots of comments here.

In general its safe to assume that rudimentary physics use is going to expand over time, the main reason I went with Physijs, it handles all of my needs so far.

Really it’s no issue to make position/rotation etc changes, Physijs allows for movement impulse forces etc, manually changing the actual values simply requires you to set dirty flags, not a real issue to me.

Physijs uses ammo (I think) I got an improved version from err whitehorse/whitestone framework??

Stuffs only outdated when it doesn’t do what you want :slight_smile:

Oimo seems cool, have fun finding user doc. I have looked at it code and its nothing like I write, not judging just different. Without user doc determining from code is an issue for me.

Physijs worker performance is not an issue at the moment. My current setup has multiple animated gltf models, moving with a steering behavior system, shooting balls, with particle explosions, etc. I run at 60 fps render and physics. I limit myself to going no faster at the moment. Some physics lets the system move shapes and some I manually adjust, realtime.

Even though Physijs does not use buffered geometry, doesn’t threejs convert on its own??