I feel like Box2D, was pretty good for the time, I didn't feel like it aged quite as well, mostly because where the solutions built internally went, but hoping box3d is great for it's time as well, would love lots of fun physics engines.
> On the Valve side, Rubikon continues to evolve and Dirk has developed optimizations (similar to those in Box3D) in a new engine called Ragnarok. Look for that in future Valve games.
Some years ago, I used Box2D from Python to get a couple of bodies moving naturally in a 2D plane, lightly disturbed by random impulses (like water lilies in a pond when it's raining). It was a fun project and working with Box2D was pleasant. Looking forward to using Box3D!
I went ahead and wishlisted his legend of California game. Probably won’t use Box3D, I’m not a fan of low level programming. I will look forward to the abstraction layers above it
I first heard of Box3D when s&box loudly ripped out the Source 2 physics engine in favor of it (along with ripping out all cross-platform rendering code, etc). Nice to see it really is open-source now.
I'm a bit familiar with Rapier (and before that Cannon and Ammo) so how does it compare?
PS: FWIW made my own physics engine in 3D space just few weeks ago (and shared it here). OK ok ... it's just a 1-liner that brings an object down at regular interval but it's surprising how well it works already! I recommend you give it a go as from a learning perspective it's really fun.
Oh I'm so ready for this.. I've had some success with Box2D in the past, it's well and truly one of the top bits of F/OSS out there.
Box3D-based Spectre VR? It's so happening. (Shades of Tanarus ..)
EDIT: holy smokes, the transition to recording and playback in the Legend of California demo (Unreal Engine-based) is quite a jarring leap. If you at first get the impression things are quite basic, be sure to get into at least 18:00 into the demo video, it gets pretty wild .. recording and playback is awesome.
Funny to see this just a few days after I’ve started building a Tron-like 3D game for the browser using Jolt[1]. So far Jolt is working pretty well but I’ll certainly be taking a look at this.
Glad to see the release, Box2D has some of the best code I've ever read.
It's interesting to see that Box3D was originally a fork of a physics engine made by Dirk. Dirk is one of the best presenters in GDC, and so influential in Physics Engine space, nice to see how he's continuing to push the latest and greatest forward.
Physics simulation is a dangerous rabbit hole. Even if you focus just on rigid bodies and just physical plausibility there are plenty of open problems related to collision detection and collision resolution. Convex approximations and/or decompositions for geometry and hand tuning of solvers are the norm, balancing robustness and precision against speed.
Yes! This is exciting to see. Erin Catto is such a cool hacker. Thank you, Erin, for sharing your code with the open source community.
There wasn't anything about determinism in the announcement, but I'd really love to see some more about that, too. Trying to use Unity's built-in physics to make a networked billiards game is quite troubling, when none of the clients can happily agree on what happened.
I was looking for the same thing. There is a replay mechanism, so it seems to be deterministic. But with floating point physics, not across platforms. Though -ffast-math is unsupported according to the documentation, so maybe it is intended to be deterministic across platforms? https://box2d.org/documentation3d/recording.html
PhysX itself (assuming Unity still uses PhysX, but any major physics engine will be the same) is unlikely to be your problem, although it is possible that Unity compiles it with undesirable optimisations, or some aggressive multithreading strategy, etc.
In any case, it's quite likely that the physics simulation is not being initialised with identical state on each instance, so the physics engine -- even if it claims to be deterministic -- cannot be expected to arrive at the same solution across instances.
From the scripting layer atop Unity (et al.) you are essentially out of luck. You don't have the requisite control/access to guarantee the simulation input is consistent.
To expand on the "quite likely" variance in the simulation input, there's an unending list of possibilities, so just a couple of points: Unity is really really big and complicated.
The physics engine is in Unity is not primarily there to be a physics engine (as a feature). It's a general purpose collision system, and it's fundamental to so many things. It's always running. Stuff that has nothing to do with what you see as your simulation can affect your simulation.
My unopinionated advice is: read Glenn Fiedler's classic networked physics articles[0].
My opinionated advice is: you're making a game where the physics is the whole game. It's also a very nicely contained problem space. Write your own physics simulation. It's gameplay code. Also, typical rigid body physics engines certainly can do a billiards sim, but they aren't actually that good at it.
Very easy to build, and quite small. A release build of the library is 916K (on macos at least). I have a game engine that compiles to WASM for web, and having 3D physics has been a challenge. 3D physics libraries tend to be large and hard to compile. I didn't try yet, but compiling this into a WASM library with emscripten should be easy, and it's likely small enough to be justifiable for a simple web game.
Love to see this! I got started with Box2D back in probably 2006ish. Great to see Erin is still working on this stuff. Thank you Erin for the great libraries!
As an ML researcher, I know box2d because it underpins many of the standard reinforcement learning environments (in OpenAI Gym) that we use to benchmark methods, like Lunar Lander or Car Racing: https://gymnasium.farama.org/environments/box2d/car_racing/
Thanks to Erin for such a useful piece of software!
34 comments
[ 3.0 ms ] story [ 40.1 ms ] threadSomeone tried to bind Jolt to C and then Odin, and the result is not very enjoyable.
I wonder if the landscape is empty enough for a resurgence.
wait....
I have to say, based on those videos, that is one accurately-named engine.
PS: FWIW made my own physics engine in 3D space just few weeks ago (and shared it here). OK ok ... it's just a 1-liner that brings an object down at regular interval but it's surprising how well it works already! I recommend you give it a go as from a learning perspective it's really fun.
Box3D-based Spectre VR? It's so happening. (Shades of Tanarus ..)
EDIT: holy smokes, the transition to recording and playback in the Legend of California demo (Unreal Engine-based) is quite a jarring leap. If you at first get the impression things are quite basic, be sure to get into at least 18:00 into the demo video, it gets pretty wild .. recording and playback is awesome.
1 - I’ve been sitting on this domain for years: https://lightcycles.io
It's interesting to see that Box3D was originally a fork of a physics engine made by Dirk. Dirk is one of the best presenters in GDC, and so influential in Physics Engine space, nice to see how he's continuing to push the latest and greatest forward.
There wasn't anything about determinism in the announcement, but I'd really love to see some more about that, too. Trying to use Unity's built-in physics to make a networked billiards game is quite troubling, when none of the clients can happily agree on what happened.
EDIT: Clarified meaning about ffast-math
In any case, it's quite likely that the physics simulation is not being initialised with identical state on each instance, so the physics engine -- even if it claims to be deterministic -- cannot be expected to arrive at the same solution across instances. From the scripting layer atop Unity (et al.) you are essentially out of luck. You don't have the requisite control/access to guarantee the simulation input is consistent.
To expand on the "quite likely" variance in the simulation input, there's an unending list of possibilities, so just a couple of points: Unity is really really big and complicated. The physics engine is in Unity is not primarily there to be a physics engine (as a feature). It's a general purpose collision system, and it's fundamental to so many things. It's always running. Stuff that has nothing to do with what you see as your simulation can affect your simulation.
My unopinionated advice is: read Glenn Fiedler's classic networked physics articles[0].
My opinionated advice is: you're making a game where the physics is the whole game. It's also a very nicely contained problem space. Write your own physics simulation. It's gameplay code. Also, typical rigid body physics engines certainly can do a billiards sim, but they aren't actually that good at it.
[0] http://gafferongames.com
Very easy to build, and quite small. A release build of the library is 916K (on macos at least). I have a game engine that compiles to WASM for web, and having 3D physics has been a challenge. 3D physics libraries tend to be large and hard to compile. I didn't try yet, but compiling this into a WASM library with emscripten should be easy, and it's likely small enough to be justifiable for a simple web game.
https://github.com/Birch-san/box2d-wasm
And Catto said, Box3D is very similar to Box2D.
https://kotaku.com/this-guy-created-angry-birds-physics-and-...
Thanks to Erin for such a useful piece of software!