Integrating a modern and maintained physics engine to Babylon.js

Hi everyone!

I decided to add a topic here on this manner, since I’m a bit worried on the physics engine integrations / plugins of today’s Babylon.js. This is mostly to add conversation on the topic in one place. Hopefully it hasn’t been done in some other place :sweat_smile:.

There are two concerns that I have on the current state physics engine state:

  1. Current physics engines (Ammo.js, Cannon.js, Oimo.js) are not maintained. And that kind of means that all the bugs will be there forevermore… For example, I think it is still a problem that physics objects can’t enter sleep state, in at least Ammo.js, which unfortunately happens to be the most performant of the current engines. And Ammo.js creator doesn’t work on the project anymore.
  2. The npm packages are all over the place, so actually adding an physics engine to a modern Babylon.js project with es modules and TypeScript is a hassle. For example, ammo.js - npm is not what you would want, but this ammojs-typed - npm. However, this might differ from the original package…

Well, how about some solutions? Here are some alternatives that I came up with:

  1. Maintain an own “Ammo.js” port of the Bullet engine, with TypeScript and support for es modules.
  2. Use a new physics engine that is well maintained, for example:
  3. Maintain own Physx wasm/js port. Most work?

I would very much like to hear what the future plan for the physics integrations would be… Are there more solutions that what I’ve presented? Is there already an official plan in motion? Anyway, I think discussion on this matter is welcome :slight_smile::pray: Cheers!

3 Likes

@RaananW @Cedric

1 Like

I agree physics engines get less maintained and we need to do something.
We also see build issues between versions of ammo : AmmoJs SoftbodyImpostor - "b._free is not a function" error - #13 by ruzrobert
Adding a new physics engine while still supporting existing ones might not be a good idea because of lack of time.
This is a discussion we will have for babylon.js 6.
Physx is, IMHO, the best available on native and the wasm version needs some tests to see how stable it is. Do we need to maintain a build on our side?

The Babylon team will gather in June. It will be the perfect moment to discuss what we want to do. @PirateJC @Deltakosh

4 Likes

PhysX would be a great addition IMHO :slight_smile:

3 Likes

I think too but we need to check the license for us and our partners. For example, partners can do paid product with babylon.js. Will they be able with PhysX as they can with Ammo or Cannon?

3 Likes

Has the council of great minds determined some path regarding to this matter? :pray:

I can’t say more than that at the moment but we have some VERY exciting stuff coming up for physics :eyes:

5 Likes

@Panuchka I’ve been doing research in that matter and there is actively maintained Cannon JS fork GitHub - pmndrs/cannon-es: 💣 A lightweight 3D physics engine written in JavaScript.
Looks interesting :thinking:

1 Like

cc @Cedric who is our physic mastermind

Yes, cannon-es is on my radar. definitely something I need to catchup with @RaananW

4 Likes

My only question is that is Cannon as performant as Ammo (which I’m using currently).

The things I’m looking (personally) in the physics engine:

  1. Performant
  2. Robust (the simulation must hold for a longer period of time, not just for a small demo)
  3. Semi bug free (things like not being able to set objects to sleep is a terrible problem for a game…)
  4. Works with or without browser (can be run with Node (maybe in the future Deno and Bun) or from browser)
1 Like
  1. I really don’t know
  2. Same, I don’t know but maybe I’ll try it soon
  3. I think it is. It’s actively maintained so even if there will be some bug there is big chance of having it fixed in sensible time
  4. I think it is, same as AmmoJS / Cannon eg. using NullEngine
1 Like

Anything you can release/tease/hint yet? :grimacing:

1 Like

Wondering this as well! Still have to do some “moves” at least in my current Ammo.js situation, since I have a lot of lag when things don’t sleep properly… By moves I mean get a sort of fix for that or completely change the physics engine in my game => a lot extra work in all the paths I take, I think…

Not yet I reckon :pensive: But we (and by we I mean @Cedric :rofl: ) are working hard on it~

3 Likes

Will be most curious to beta test and give feedback if there is some new thing cooking up :slight_smile:

2 Likes

I’m also interested in the new physics developments, so I created a forum account to add my name to the list.

I’m currently evaluating Babylon.js, I use three.js and my intention was to use a physics engine with that, so I’m evaluating the options but Babylon.js provides a useful way to evaluate 3 physics engines together and I may switch to Babylon.js. I actually came across this forum post when searching for Physx and other options.

Any hints as to the future physics would be welcome as it may well be a factor in deciding if I switch to Babylon.js.

2 Likes

No hint or infos until there is something to show. :slight_smile:

5 Likes

My guess/hope it that it’s about an integration of the rapier physics engine since it’s the fastest and best maintained physics engine I’m currently aware of: https://rapier.rs/

4 Likes

My hope would have been Physx, it’s well established across the industry, I like the soft limits, etc. I’m currently playing with Three.js + Emscrimpten generated Physx out of curiosity, though I suspect I will quickly run up against a brick wall due to few JS-specific demos. This is exactly where Babylon.js would come in handy to help unlock it’s potential and finally make it more accessible to developers in the browser.

As a footnote, Unreal 5 is in the process of dropping Physx for their in-house Chaos engine, but you don’t have to go far in the forums to see a lot of people wish for an option to still use Physx due to poor performance of Chaos. Physx 4.1 remains a very tried and trusted solution.

2 Likes