Box2D

Do you mean Verlet.js?[1] Note that box2djs is also very capable[2], and has been around for years (it is port of Erin Catto's great work on Box2D[3]). [1] http://subprotocol.com/2013/04/18/introducing-verlet-js.html [2] http://www.jeremyhubble.com/box2d.html [3] http://box2d.org/

Well, maybe you can work on some new iPad applications using the physics and the gyroscope for the new iPad (or iPhone). The physics kit used for angry birds is Box2D: http://box2d.org/ perhaps you could build an app for fun at the intersection of your interests, on a mobile device. Best of luck.

Ah, found more: https://box2d.org/documentation3d/md_simulation.html#autotoc_md152 "Box3D is designed to be deterministic across thread counts and platforms." This is absolutely fantastic!

Is it just me or does that section not really explain why? The reasons given here felt more insightful to me: https://box2d.org/documentation/md_faq.html > Box2D is designed to be portable and easy to wrap with other languages, so I decided to use C11. I used C11 to get support for atomics.

The author of Box2D just put out a fantastic blog post on exactly that subject: https://box2d.org/posts/2024/02/solver2d/ The author's video linked at the bottom of the post shows how each solver handles various hard stacking problems https://youtu.be/sKHf_o_UCzI

A lot of software that doesn't support multithreading could easily support it by implementing a single threaded graph partitioning algorithm or an algorithm to find disconnected subgraphs. Your ability to feed your cores is now limited by this piece of single threaded code. The easy way to get around this is to have heterogeneous cores. Ampere could have easily slapped 2 A76 cores for every 32 Ampere cores to prevent this problem. The harder way to get around this is to multithread the partitioning algorithm, but that will convince more people that multithreading isn't worth it, because their Ryzen runs the same code faster even though it might only have 12 cores. https://box2d.org/posts/2023/10/simulation-islands/

I would start with Erin Catto's Box2D. http://box2d.org/ There are C#, Flash, Java versions if you aren't into C++. Lots of documentation on the web, but the getting started guide is good enough.

Interesting link, feral. For anyone else reading, I'd also suggest reading some of the followup posts such as this one: http://www.box2d.org/forum/viewtopic.php?f=3&t=1800&sid=f28239…

Why would he bother writing his own physics engine if there are free and easy solutions already? People who invent their bicycles don't end up shipping stuff in two weeks with no prior programming experience. http://cocos2d-iphone.org (which uses:) * http://code.google.com/p/chipmunk-physics/ * http://www.box2d.org/

> it must have some interesting physics code inside. You can check it out for yourself: http://box2d.org. You can also download several of the Game Developers Conference presentations given by the original author here: http://www.gphysics.com/downloads An enterprising chap has also ported the original C++ code to Flash: http://box2dflash.sourceforge.net

The principle of least constraint is the basis for rigid body mechanics based contact forces. This has been known since the days of Gauss and Hamilton, and is fundamentally how restitution and collision forces are derived in Lagrangian mechanics. There's a long literature on this going back more than a hundred years. It's true that some commercial solvers like Ansys use spring/penalty methods, but this is due to the spring forces being easier to couple to other solvers. It's harder in the Ansys force/velocity formulation to combine things like elasticity and fluids to their rigid body solver. To deal with the instability of systems of many stiff springs they have to take many small timesteps to avoid convergence issues. More recently techniques like XPBD have been gaining popularity, particularly in film, which use purely positional constraints and variational methods to combine many different types of physics simulations. There's a really great and approachable series of videos by Matthias Muller on youtube which goes through how to implement all this in JS https://matthias-research.github.io/pages/ Finally it's funny you should mention games, since many older games used spring methods for physics. It was only when constraint based solvers became popular after Havok/Half-Life 2 did we start to see games with real rigid body dynamics and stable stacking of boxes. Older physics games like Trespasser ( https://en.wikipedia.org/wiki/Trespasser_(video_game) ) had many…

Have you considered not using an engine at all, in favor of libraries? There are many amazing libraries I've used for game development - all in C/C++ - that you can piece together: General: stb https://github.com/nothings/stb 2D Phys: box2d https://box2d.org/ UI / Editor: imgui https://github.com/ocornut/imgui Platform: SDL https://www.libsdl.org/ Engine: Quake https://github.com/id-Software/Quake Ok, Quake is more of an engine than a library - but it is well documented & widely used. Even many current day AAA engines are still originally based on the Q1 engine (though, of course, heavily modified over the years to stay modern). I don't mean to bring down anyone but I feel like game engine announcements are a dime a dozen these days. As someone who has worked in the industry I'd favor putting together my own simple engine based on libraries for smaller scoped projects. Most open-source engines, I presume, are not really going to be battle tested, well-supported, well-funded etc. There are some exceptions of course (like Godot). If your goal is too complex; why not just use UE5 or Unity? Epic has been in the industry for a long time, Tim Sweeney is a really smart guy, and the engine has been widely used in AAA and indie games.

> sorry for the wall of text, i did my best to explain. No need to appologize, I definitely asked for it. I'll get back to your original questions in a little bit, first I want to talk about your list of inspirations: > Gource > Minecraft > scribblenauts unlimited object attribute editor And your description of what you want to do: > simulations of objects in an environment > Physics > experiment with familiar concepts, like gravity, wind, light, ect > create abstract system with odd rules What you want sounds fun, but complicated. If you _really_ want to do this, it will obviously be possible. It may take a lot of work, but from here out, I'm going to assume you'll be willing to put in a lot of work. Even with that assumption, I think the best advice anyone can give you is unrelated to any technology: Limit your scope. I've started a significant number of projects, super excited about all the possibilities, and started writing everything for the general, most abstracted case. When I do this, I invariably get bogged down quickly. When I'm more focused on one small feature, things turn out better. You want something that is immediately fun, even if the scope is tiny. You can see this in your inspirations as well. Minecraft started development on May 10th, 2009[1]. It was playable by May 16th 2009 (First officially numbered version). That seems like a ridiculously short development time, but note that inventory management (the ability to pick up and place blocks)…

As gms7777 points out, for the RNG, surely you can just share seeds? Your comment about the differences in how CPUs deal with floats is very interesting. I found the following interesting comment, from a GPG employee, talking about how they take care to ensure their float math is deterministic: "I work at Gas Powered Games and i can tell you first hand that floating point math is deterministic. You just need the same instruction set and compiler and of course the user's processor adhears to the IEEE754 standard, which includes all of our PC and 360 customers. The engine that runs DemiGod, Supreme Commander 1 and 2 rely upon the IEEE754 standard. Not to mention probably all other RTS peer to peer games in the market. As soon as you have a peer to peer network game where each client broadcasts what command they are doing on what 'tick' number and rely on the client computer to figure out the simulation/physical details your going to rely on the determinism of the floating point processor." http://www.box2d.org/forum/viewtopic.php?f=3&t=1800#p16480

In addition to writing Box2D, the author of this article was the lead physics programmer at Blizzard for 15 years. He also wrote an evaluation harness called Solver2D where he has pitted many solvers against each other. I suspect that he has solid reasons for choosing to exhaustively test for collisions. In fact, if you listen to his recent podcast episode with Łukasz Ściga (which I linked in another comment), he mentions some properties that his current project (The Legend of California) relies on like determinism and reversibility. He also put up an earlier blog post with accompanying videos that show how Unreal’s built-in physics engine fails to resolve important collisions in their game correctly: https://box2d.org/posts/2026/06/announcing-box3d/

Valve is still working on new things. See this section, specifically the bottom. https://box2d.org/posts/2026/06/announcing-box3d/#valve-to-the-rescue

Hey Glenn, what do you mean by 'rollback determinism'? Is there some particular thing missing from Box3D now that makes it difficult to synchronize with solely the inputs? My reading of Box3D's docs is that it has 'cross platform determinism', and 'recording/replay'? Isn't that sufficient? Synchronize inputs, determine if inputs were 'mispredicted', if so, rollback the physics world, apply the changed inputs and resimulate? Just for context: I implemented state-sync netcode into box2d in 2018 and shipped multiple real games using it - and I work on netcode professionally. I'm planning on adding full netcode support for box3d and releasing it as part of a larger framework. https://box2d.org/documentation3d/md_simulation.html#autotoc_md152

ok, so you haven’t tried box2c, there are some posts about it in the blog https://box2d.org/posts/2025/04/box2d-3.1/ It became the current box2d implementation, now after version 3.0, it was entirely rewritten in C, it works differently.

Box2D has moved from C++ to C for this v3.0 release. Erin has explained why further down in the post: https://box2d.org/posts/2024/08/releasing-box2d-3.0/#moving-to-c-from-…

I'm curious whether you've considered using Box2D[1] as a reference, since it is a pretty complete implementation of rigid body physics? Or is it more that you want to re-implement things from scratch as part of this tutorial? [1] - https://box2d.org/documentation/

Actually, rigid body simulators using impulse based constraint solvers can simulate soft constraints (including soft contact), and you can control the stiffness from very stiff to very soft without becoming totally unstable. See this slide deck by Erin Catto: https://box2d.org/files/ErinCatto_SoftConstraints_GDC2011.pdf

Well, it’s a pretty huge topic. I recommend taking a look at the SIGGRAPH course notes on contact and friction simulation: https://siggraphcontact.github.io/ Also, look at some recent papers on SIGGRAPH and SCA, such as: - https://matthias-research.github.io/pages/publications/PBDBodies.pdf - https://mmacklin.com/primaldual.pdf - https://arxiv.org/pdf/2201.10022.pdf Note that these are all cutting-edge stuff, and most physics simulations in production still use more traditional methods (which you can learn from Box2D’s source code and related GDC slides). The links: - https://github.com/erincatto/box2d - https://box2d.org/publications/

I think theoretically you're correct that the methods underlying Box2d could be used in such a way, but practically I don't think it's there, as that was never one of the engine's goals. Read up on the methods used (for instance, http://twvideo01.ubm-us.net/o1/vault/gdc2013/slides/824737Catto_Erin_P… for some of the limitations that Erin chose to accept. In particular the fact that it misses multiple roots during the solve means that you can't use if for perfect tickless simulation; there are (were? I'm not sure to what extent they've been addressed since I was deep in that code) also issues with conservation of time that would be a problem, which are discussed elsewhere (for instance http://box2d.org/forum/viewtopic.php?t=154).

Here's a thread @Box2d where Erin responds to this himself, confirming that this was not a "calling out" or any sort of big deal: http://box2d.org/forum/viewtopic.php?f=3&t=6462

Nice visualization of a very cool data source: http://wordnet.princeton.edu/wordnet/ Re: the visualization: maybe uses the Box2D Flash port? I don't do any Flash development so can't easily look at the source to see, but it feels like Box2D under there. http://www.box2d.org/wiki/index.php?title=AS3_FAQ

Hi! Rollback determinism is a term invented by Erin Catto here: https://box2d.org/posts/2024/08/determinism/ Physics engines like Box3D have a significant amount of internal state and caching, like contact caching, and other things to speed things up. I've talked to Erin a lot about stuff like: "Hey, what if I want to do an FPS or a vehicle, but I want to roll back only the character or vehicle, like in an FPS?" From these discussions (and many other inputs I'm sure) Erin has had a big think about determinism, and come up with his own determinism and replay stuff. In the article he uses the term "rollback determinism" to mean you'd be able to synchronize (or at least invalidate) any of this caching so that it doesn't affect the way the simulation replays if you were to rollback the simulation fully and then change the state only for a few objects. For example, if you were to rewind and replay a physics simulation just for say the player predicted object like a vehicle and any objects that it happens to touch, expanding these objects out recursively as they touch other things. Or if you were to do rollback on the player controller like we normally do in FPS, and the player started predicting a physically simulated door they push into, and then any other object the door pushes and so on, this sort of thing. This should not affect you if you only step the physics simulation ahead with inputs, and do the GGPO thing where you copy fork, and step that sim ahead with…

The usual approach is some form of sweep to get a time of impact. Once you've got a time of impact, you can either generate contacts, or avoid integrating the involved bodies beyond the time of impact, or do something fancier like adaptively stepping the simulation to ensure no lost time. If the details don't matter much, it's common to use a simple ray cast from the center at t0 to the center at t1. Works reasonably well for fast moving objects that are at least kinda-sorta rotationally invariant. For two dynamic bodies flying at each other, you can test this "movement ray" of body A against the geometry of body B, and the movement ray of body B against the geometry of body A. One step up would be to use sphere sweeps. Sphere sweeps tend to be pretty fast; they're often only slightly more complicated than a ray test. Pick a sphere radius such that it mostly fills up the shape and then do the same thing as in the previous ray case. If you need more detail, you can use a linear sweep. A linear sweep ignores angular velocity but uses the full shape for testing. Notably, you can use a variant of GJK (or MPR, for that matter) for this: http://dtecta.com/papers/jgt04raycast.pdf If you want to include angular motion, things get trickier. One pretty brute forceish approach is to use conservative advancement based on distance queries. Based on the velocity and shape properties, you can estimate the maximum approaching velocity between two bodies, query the distance between the…

I had to figure this out recently, a couple things that really helped me are Erin Catto's GDC lectures (particularly [1]) and Allen Chou's game physics articles [2]. I think of a Jacobian as a way to transform the velocities from however they're stored for the interacting objects into linear world-space velocities. For example, in 2D rigid body physics, rotational velocity is usually just a single number representing how fast something is spinning. Given a radius from the center of a spinning object (e.g. object origin -> a contact point in world space), the instantaneous linear velocity is the rotation speed times the tangent to that radius. Therefore, the Jacobian is just that tangent vector - multiplication by that vector transforms scalar rotational velocities into 2D linear velocities. The Jacobian for the object's linear velocity is just the identity matrix. The rotation Jacobian is more complicated in 3D and 4D, but the principal is the same - find a matrix (at a particular point, usually the contact point or the joint location) to multiply with whatever represents rotational velocity to get the linear velocity. [1]https://box2d.org/files/ErinCatto_ModelingAndSolvingConstraints_GDC200… [2]http://allenchou.net/2013/12/game-physics-constraints-sequential-impul…