Box2D

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…

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…

> 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)…

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…

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_GDC2009.pdf
[2]http://allenchou.net/2013/12/game-physics-constraints-sequential-impulse/

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.