bepu / bepuphysics2

Pure C# 3D real time physics simulation library, now with a higher version number.
Apache License 2.0
2.35k stars 272 forks source link

Adapative speculative margins #177

Closed RossNordby closed 2 years ago

RossNordby commented 2 years ago

Currently speculative margins for every collidable are set to a fixed value by the user. Any single fixed value comes with tradeoffs that are hard to automate, hence punting responsibility.

Swapping to a minimum-maximum speculative margin range and automatically computing a speculative margin within that range could make configuration simpler, and possibly offer significant performance advantages in some simulations.

The speculative margin for a shape could be calculated on a per frame basis during bounding box prediction. Take the velocity and shape maximum radius, compute a conservative point motion bound, clamp it to the collidable's speculative interval. Collision pairs would then add the calculated margins from both shapes together, and then clamp them to the interval overlap of both contributing collidables.. If the intervals do not overlap, do something reasonable- probably taking the higher interval's minimum.

Why?

  1. In order for bounciness to be easy, the speculative margin must be large enough to ensure that a body doesn't discretely step into penetration. This is velocity sensitive, so it wouldn't be surprising for users to currently choose float.MaxValue so that it never fails.
  2. Using large speculative margins can add cost to simulations with lots of bounding box overlaps- think a giant pile of boxes, or the ColosseumDemo that has tons of off-axis aligned bounding boxes in close proximity. Even with a fairly low speculative margin, it will tend to generate tons of constraints that don't matter until chaos begins. Velocity adaptive margins means you only pay that cost once the chaos actually begins.
  3. Most users can just use default values of [0, float.MaxValue] without thinking about it at all, so it's one less weird parameter that people have to think about in the median case.

Interaction with swept CCD needs some thought. If I remember correctly, it terminates within speculative margin, For extremely large speculative margins, this would kind of defeat the point of swept CCD (ghost contact filtering). The user COULD specify a lower maximum margin for such shapes. Could solve pretty easily by exposing another swept convergence parameter for maximum CCD speculative range. The smaller of the true speculative margin and the maximum range would be used for sweep convergence. Would be nice to avoid as much configuration complexity as possible here.

May want to consider also allowing the user direct control over the speculative margin for a given pair by exposing it in AllowContactGeneration. If there's no significant complexity involved, probably just do that.

Relevant to #159.

RossNordby commented 2 years ago

Done in 42d12b1b3bdf72b36a203c82c3075230017b20a3.