Open dkushner opened 6 years ago
The idea is to separate collision detection and integration so end users can mix and match any way they want.
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.
And the spatial sorting etc should be optional, the basic collision system can be used for simpler games that don't need rays etc.
Check the rb PR if you haven't, some things are already in there
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:
SpatialSortingSystem
.SpatialCollisionSystem
and report collision events and manifolds through the CollisionEvent
queue.next_frame
positions and velocities of all collided bodies (in ImpulseSolverSystem
).next_frame
positions and velocities for all bodies (in ImpulseSolverSystem
).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?
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.
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:
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: