Implement generic integrators for the physics world.

[dkushner]

As you mentioned on the Gitter, I think working towards a generic integrator implementation would be an excellent step towards getting this wonderful project production ready. As far as I can tell (and that's not terribly far considering I've only just started to get a handle on the code base), all of the important pieces seem to be in place.

What design approach were you thinking about for this feature and does this approach sound reasonable? If I understand correctly, the current dependency tree for the systems in order of actual execution looks something like:

SpatialSortSystem -> CollisionSystem -> SolverSystem

Where the collision system relies on the spatial sort being performed to make the BVT query more efficient and the solver system relies on the contact events published by the collision system. Furthermore, the solver system appears to be doing the actual force integration as well as the contact resolution. Is the idea to make the actual integration strategy pluggable by the end user or to simply improve the logic that is already present?

At the very least, it would certainly pay to implement island/sleep detection to be able to prune out inactive bodies and more efficiently parallelize integration. Should also consider supporting linear and angular dampening.

Possible implementations for the integrators include:

• Symplectic Euler
• RK4
• Verlet

[Rhuagh]

The idea is to separate collision detection and integration so end users can mix and match any way they want.

[Rhuagh]

I want to separate the solver for the current frame (that do contact resolution and update the actual position/orientation of the bodies), and for the next frame (which is basically just setting up NextFrame so collision detection can be run). The idea is to be able to do next frame calculation and collision detection in parallel with rendering.

[Rhuagh]

And the spatial sorting etc should be optional, the basic collision system can be used for simpler games that don't need rays etc.

[Rhuagh]

Check the rb PR if you haven't, some things are already in there

[dkushner]

I'm going to take some notes on the current integrator implementation here for both visibility and to confirm with @Rhuagh whether or not I am completely off-base. Referring to the ImpulseSolverSystem implementation, it appears that the current simulation loop takes the following form:

1. Re-sort DBVT for current step via SpatialSortingSystem.
2. Perform collision detection via SpatialCollisionSystem and report collision events and manifolds through the CollisionEvent queue.
3. Resolve pending contacts by applying corrected positions and velocities to the next_frame positions and velocities of all collided bodies (in ImpulseSolverSystem).
4. Update the current frame positions and velocities to the next_frame positions and velocities for all bodies (in ImpulseSolverSystem).
5. Perform forward integration on current frame velocities and positions to determine prospective next_frame velocities and positions for all bodies (in ImpulseSolverSystem).

I've not had much experience breaking down a physics engine for an ECS of this type, but perhaps we can consider moving to a sequential impulse/constraint based solution rather than explicit contact resolution?

[Rhuagh]

That's the plan yes, but I have no experience of that and information on the Internet is scant, so I wanted to do a simple stupid version first, mostly to learn the basics.