Gravity v. stacked items

[jebremus]

Hello!

With an insufficient gravity vector specified in something like the DemoPoseIntegratorCallbacks, objects feel like they float too much - as if they were on the moon. It's trivial to increase that downward vector, however, when I do that to a degree that objects feel like they are correctly returning to Earth, I find a different problem - the force is enough that a stack of boxes falls over on its own, with no forces other than that gravity.

With sufficient gravity that objects feel realistically pulled downward, are there dials I can turn to prevent side effects like my toppling stack of boxes?

Thanks so much!

-jremus

[RossNordby]

Increasing gravity by N times will increase stacking forces by N times, which will tend to squish the demos default contact configuration if N is large.

Contacts in bepuphysics2 are all springs. The material properties output by ConfigureContactManifold in the INarrowPhaseCallbacks define how those springs behave.

If you've increased gravity by a factor of 10, try setting pairMaterial.MaximumRecoveryVelocity = 20f; in your INarrowPhaseCallbacks. By increasing the maximum recovery velocity proportionally, it's able to fight back against the force of gravity without just getting squished. (This will allow objects to be shoved out of deep penetration more forcefully, too, which you might want to counterbalance by increasing shape speculative margins or using continuous collision detection to avoid excessive penetration.)

There will still be a little bit of squishiness left over with the default demos spring settings of 30hz frequency and 1 damping ratio. Higher frequency values correspond to a stiffer spring and will squish less.

Notably, high stiffness constraints are harder to solve than soft constraints. While individual contact springs are solved in a way that guarantee stability locally, a system of constraints (which contacts are) can be unstable if the solver doesn't have time to converge. Further, even if the solver does converge, frequencies too high relative to the time step rate cannot be represented and get damped out. If you want a very stiff simulation, it's a good idea to use the SubsteppingTimestepper so that the solver runs at a higher rate internally, allowing you to use higher stiffness values with far, far fewer solver iterations and higher quality. See the SubsteppingDemo for more information (and stay tuned for when the embeddedsubstepping branch gets merged into main and makes aggressive substepping the default for all simulations).

[jebremus]

Thanks so much - increasing the MaximumRecoveryVelocity stabilized my stacks of boxes.

My general use case is a simple one - really just a sandbox of shapes that behave correctly/realistically when arbitrary forces are applied. In that context, is there any documentation on other dials like MaximumRecoveryVelocity that I'll want to be aware that I can turn? In other words I'm staying far away from the underlying logic of the solver, but want to be aware of high-level controls of the simulation. Any pointers would be awesome, thanks much again.

[RossNordby]

Hard to say what specifically you'll need, but a few resources:
Stability tips
Performance tips
General getting started/high level view stuff
Q&A

And probably use PositionLastTimestepper or SubsteppingTimestepper when creating the Simulation if you plan on modifying velocities arbitrarily outside of the timestep. PositionFirstTimestepper, in contrast, will integrate velocities into positions at the start of the frame without solving any constraints, so velocity modifications outside of the timestep would not be fought against.

[jebremus]

Thanks for the doc pointers! Hoping to ask a few more (extremely basic) questions on collisions -

1. Is SpeculativeMargin on CollidableDescription a radius under which collisions will be generated, or a radius under which they'll just be considered? i.e. 'the objects are actually X far apart, but we'll treat them as hit' versus 'the objects are less than X far apart, let's do further math to see if they've hit'. Or, very possibly, neither of these things and I don't understand at all.
2. I'm understanding INarrowPhaseCallback::ConfigureContactManifold to be called when two objects have collided, provide the opportunity to configure how that collisions behaves in the simulation (e.g. a rubber ball will bounce of a wall differently than a iron one), and provide the opportunity to do any outside-simulation bookingkeeping (e.g. increase a counter that displays how many collisions have occurred in total). Is that a fair/complete summary?
3. Is the Manifold parameter passed to ConfigureContactManifold a set of discrete points where the two objects have collided? (i.e. points in simulation space that contain both objects?) What happens when two parallel faces collide (so there would be an infinite number of such points)?
4. The TankDemo contains this logic in considering projectile collision in ConfigureContactManifold

for (int i = 0; i < manifold.Count; ++i)
{
if (manifold.GetDepth(ref manifold, i) >= -1e-3f)
        {
		...

What's going on here exactly? What's the depth of a manifold member? Also the comment in that scope says "An actual collision was found" but I thought a collision was assumed if this method was called at all.
5. Maybe a better way to ask the same question as just above- what would happen if the logic at that scope was brought outside the for loop? So the only required condition would be
if (propertiesA.Projectile || (pair.B.Mobility != CollidableMobility.Static && Properties[pair.B.BodyHandle].Projectile))
I didn't notice any immediate differences making that change in the Tank demo.

Thanks so much for your help, much appreciated.

[RossNordby]

Is SpeculativeMargin on CollidableDescription a radius under which collisions will be generated, or a radius under which they'll just be considered? i.e. 'the objects are actually X far apart, but we'll treat them as hit' versus 'the objects are less than X far apart, let's do further math to see if they've hit'. Or, very possibly, neither of these things and I don't understand at all.

Alas, sorta-kinda-neither! It is a distance under which speculative contacts may be created. "Speculative" contacts are any contacts with negative depth. Negative depth is equivalent to separation. Speculative contacts do not stop the objects from approaching each other unless the approaching velocity is sufficiently high that it needs to be opposed to stop penetration. That is, a speculative contact will do something if contactApproachingVelocity * dt >= -depth.

In order for speculative contacts to be created, two shapes must 1) be no more than the maximum of the speculative margins of each collidable apart, and 2) must have overlapping bounding boxes.

The bounding box of a body is expanded by its velocity, so a fast moving object will have a bounding box which overlaps other objects it is likely to hit during a frame.

The purpose of speculative contacts is to act as a sort of small scale continuous collision detection. If a box tilts a little bit off a flat surface, it will likely still have speculative contacts for the area of the colliding shape feature that is not currently touching. Those contacts will act if some force (like a stack of other boxes on top of that box) end up shoving it back into the ground. Without the speculative contact, the solver couldn't 'see' the whole contact surface and it's possible for the box to get rotated partially into the ground.

Speculative contacts are also used in the 'proper' continuous collision detection path, but there, they are created by an explicit sweep test to avoid some of the weaknesses of very large speculative margins.

(This is something I still need to write some dedicated documentation for.)

I'm understanding INarrowPhaseCallback::ConfigureContactManifold to be called when two objects have collided, provide the opportunity to configure how that collisions behaves in the simulation (e.g. a rubber ball will bounce of a wall differently than a iron one), and provide the opportunity to do any outside-simulation bookingkeeping (e.g. increase a counter that displays how many collisions have occurred in total). Is that a fair/complete summary?

Yup!

Is the Manifold parameter passed to ConfigureContactManifold a set of discrete points where the two objects have collided? (i.e. points in simulation space that contain both objects?) What happens when two parallel faces collide (so there would be an infinite number of such points)?

In principle, yes, the point set for two parallel faces touching would be infinite. For the purposes of simulation, a pair of collidables never emits more than 4 contacts. These are typically chosen to approximate the true contact surface (that infinite point set).

For example, to generate contacts between two box faces, the edges of the box faces are clipped against each other to generate contacts. The complete set of these intersections (or just face vertices, if the vertex is contained by the other collidable's face) form the boundary of the 'true' contact manifold. But you could end up with quite a few intersections- we don't want to give the solver 8 contacts for a single pair since that'll be more expensive for effectively no simulation benefit, and for more complex intersections like hull-hull you could end up with very high maximum contact counts. So instead, we take this 'raw' manifold and select a subset of points according to rules of thumb like 'keep the deepest point' and 'maximize the area of the output manifold'.

Some of these up-to-4 contacts may have negative depths and be speculative contacts. To use the box-box example again, imagine that the boxes are tilted so that the faces aren't perfectly aligned. You could choose to create a manifold restricted only to the truly overlapping region, but instead, it (conceptually) performs the face clipping in a projected 2d space- it generates contacts via clipping like the two faces were fully touching, and then goes back and assigns depths that may or may not be negative as appropriate.

What's going on here exactly? What's the depth of a manifold member? Also the comment in that scope says "An actual collision was found" but I thought a collision was assumed if this method was called at all.

That function just pulls the depth of a particular contact in the manifold. The depth is how much overlap there is at that contact point, which can be negative in speculative contacts.

The condition avoids triggering an impact for speculative contacts. It would be odd to make the bullet explode if it hasn't actually hit anything. The existence of a speculative contact alone does not necessarily imply that any force has been applied to either shape as a result of the contact manifold or that the shapes even touched.

(The weird function signature, calling with manifold and passing in manifold, is just a byproduct of C# language limitations. Notably, the upcoming static abstracts in interfaces feature will let me get rid of that pattern.)

5. Maybe a better way to ask the same question as just above- what would happen if the logic at that scope was brought outside the for loop? So the only required condition would be
   if (propertiesA.Projectile || (pair.B.Mobility != CollidableMobility.Static && Properties[pair.B.BodyHandle].Projectile))
   I didn't notice any immediate differences making that change in the Tank demo.

If the depths weren't tested at all, the bullet could blow up without touching anything. If they're tested ahead of time to confirm that there's a real collision, that would be fine. Further, in the demo, note that the TryAddProjectileImpact for each of those conditions is actually passing different values, so combining the conditions and only calling one won't quite do the same thing.

Really, for the purposes of that demo, I should have instead checked the accumulated impulses of contact constraints associated with projectiles each frame. With the current setup it's possible for it to miss impacts because they never generate a nonzero depth even though a contact constraint does do work. I've been meaning to change that now that I've got other examples of using the contact callbacks.

[jebremus]

Thanks so much for the super helpful info. One more question, back to gravity and the configuration of MaximumRecoveryVelocity - is it a good idea to set MRV based upon the mass of the collidable in ConfigureContactManifold? i.e. I'd use a larger value for more massive objects. My hope is that approach would solve for stacks of massive boxes falling apart without putting unnecessary burden on the simulation. I'm assuming because it's even possible to set per-collision in ConfigureContactManifold it's OK if there's a wide range of MRV values used for different objects in the simulation? Thanks again for putting up with my many questions!

…

-jeb

On Mon, Sep 6, 2021 at 2:20 PM Ross Nordby ***@***.***> wrote: Is SpeculativeMargin on CollidableDescription a radius under which collisions will be generated, or a radius under which they'll just be considered? i.e. 'the objects are actually X far apart, but we'll treat them as hit' versus 'the objects are less than X far apart, let's do further math to see if they've hit'. Or, very possibly, neither of these things and I don't understand at all. Alas, sorta-kinda-neither! It is a distance under which *speculative* contacts *may* be created. "Speculative" contacts are any contacts with negative depth. Negative depth is equivalent to separation. Speculative contacts do not stop the objects from approaching each other unless the approaching velocity is sufficiently high that it needs to be opposed to stop penetration. That is, a speculative contact will do something if contactApproachingVelocity * dt >= -depth. In order for speculative contacts to be created, two shapes must 1) be no more than the maximum of the speculative margins of each collidable apart, and 2) must have overlapping bounding boxes. The bounding box of a body is expanded by its velocity, so a fast moving object will have a bounding box which overlaps other objects it is likely to hit during a frame. The purpose of speculative contacts is to act as a sort of small scale continuous collision detection. If a box tilts a little bit off a flat surface, it will likely still have speculative contacts for the area of the colliding shape feature that is not currently touching. Those contacts will act if some force (like a stack of other boxes on top of that box) end up shoving it back into the ground. Without the speculative contact, the solver couldn't 'see' the whole contact surface and it's possible for the box to get rotated partially into the ground. Speculative contacts are also used in the 'proper' continuous collision detection path, but there, they are created by an explicit sweep test to avoid some of the weaknesses of very large speculative margins. (This is something I still need to write some dedicated documentation for.) I'm understanding INarrowPhaseCallback::ConfigureContactManifold to be called when two objects have collided, provide the opportunity to configure how that collisions behaves in the simulation (e.g. a rubber ball will bounce of a wall differently than a iron one), and provide the opportunity to do any outside-simulation bookingkeeping (e.g. increase a counter that displays how many collisions have occurred in total). Is that a fair/complete summary? Yup! Is the Manifold parameter passed to ConfigureContactManifold a set of discrete points where the two objects have collided? (i.e. points in simulation space that contain both objects?) What happens when two parallel faces collide (so there would be an infinite number of such points)? In principle, yes, the point set for two parallel faces touching would be infinite. For the purposes of simulation, a pair of collidables never emits more than 4 contacts. These are typically chosen to approximate the true contact surface (that infinite point set). For example, to generate contacts between two box faces, the edges of the box faces are clipped against each other to generate contacts. The complete set of these intersections (or just face vertices, if the vertex is contained by the other collidable's face) form the boundary of the 'true' contact manifold. But you could end up with quite a few intersections- we don't want to give the solver 8 contacts for a single pair since that'll be more expensive for effectively no simulation benefit, and for more complex intersections like hull-hull you could end up with very high maximum contact counts. So instead, we take this 'raw' manifold and select a subset of points according to rules of thumb like 'keep the deepest point' and 'maximize the area of the output manifold'. Some of these up-to-4 contacts may have negative depths and be speculative contacts. To use the box-box example again, imagine that the boxes are tilted so that the faces aren't perfectly aligned. You *could* choose to create a manifold restricted only to the truly overlapping region, but instead, it (conceptually) performs the face clipping in a projected 2d space- it generates contacts via clipping like the two faces were fully touching, and then goes back and assigns depths that may or may not be negative as appropriate. What's going on here exactly? What's the depth of a manifold member? Also the comment in that scope says "An actual collision was found" but I thought a collision was assumed if this method was called at all. That function just pulls the depth of a particular contact in the manifold. The depth is how much overlap there is at that contact point, which can be negative in speculative contacts. The condition avoids triggering an impact for speculative contacts. It would be odd to make the bullet explode if it hasn't actually hit anything. The existence of a speculative contact alone does not necessarily imply that any force has been applied to either shape as a result of the contact manifold or that the shapes even touched. (The weird function signature, calling with manifold and passing in manifold, is just a byproduct of C# language limitations. Notably, the upcoming static abstracts in interfaces feature will let me get rid of that pattern.) 1. Maybe a better way to ask the same question as just above- what would happen if the logic at that scope was brought outside the for loop? So the only required condition would be if (propertiesA.Projectile || (pair.B.Mobility != CollidableMobility.Static && Properties[pair.B.BodyHandle].Projectile)) I didn't notice any immediate differences making that change in the Tank demo. If the depths weren't tested at all, the bullet could blow up without touching anything. If they're tested ahead of time to confirm that there's a real collision, that would be fine. Further, in the demo, note that the TryAddProjectileImpact for each of those conditions is actually passing different values, so combining the conditions and only calling one won't quite do the same thing. Really, for the purposes of that demo, I should have instead checked the accumulated impulses of contact constraints associated with projectiles each frame. With the current setup it's possible for it to miss impacts because they never generate a nonzero depth even though a contact constraint does do work. I've been meaning to change that now that I've got other examples of using the contact callbacks. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#146 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHGXRTGRUOANLYM7N24FXLUAUWDDANCNFSM5CYHQKZA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[RossNordby]

It is indeed perfectly fine to use different values for MaximumRecoveryVelocity (and the other contact properties) across different pairs.

But as far as the simulation is concerned, there's no strong reason to use a higher MaximumRecoveryVelocity for heavier bodies. The MaximumRecoveryVelocity is the maximum velocity that the contact constraint will try to separate the bodies, regardless of other spring configuration. Note that because it is a velocity, it is independent of the involved body masses. The reason I recommended increasing it proportionally to gravity was to keep the contact response proportional to the higher velocities the higher gravity implies.

Increasing MaximumRecoveryVelocity does not directly increase the cost of the simulation. It can reveal other unstable configuration in some cases (if contact constraints are too stiff for the timestep, or if velocities high enough that the passive speculative margin isn't enough to stop interpenetration, yielding excessive bounces due to excessive penetration), but those issues can be directly addressed.

That said, if you do just happen to want higher MaximumRecoveryVelocity in pairs involving bodies with higher masses for other reasons, then that's totally fine.

[damian-666]

if you revisit this in the solver, maybe this will help.

Erin didn't like this idea i ran it by him, i forgot why, but some researches used a graph of islands or groups to see the relation between say bottom box and top box, but that was in a general" physics informed machine learning" context that might be overly complex and generalized..

i see you have twisting ropes on tension and "chirality and geometric frustration" so maybe this isn't something you don't already know
but an old trick from Fedkiw and Bridson, but maybe just for stacking without other constraints its good.

To converge the solver without all the pairwise propagation.

I cant find the other paper but it basically circuments the whole pairwise piling slow convergence and mass ratio issues. via a graph and a couple only one or two iteration pairwise, Its a bit like neural network weights thats physics informed, but is just a graph. If you have already islands itf but there an simple idea in this that might help:

its in 8.1 and 8.2 shocks propagation

https://graphics.stanford.edu/papers/rigid_bodies-sig03/

[RossNordby]

Considered shock propagation long ago, but:

1. It does not magically converge to the true global solution, it just changes the character of the partial solution (and gets you other kinds of artifacts),
2. It adds complexity and cost, particularly if you want scalable intra-island parallelism,
3. You can get stability with fewer artifacts other ways, like frequency-tuned constraints and substepping.

There may be profitable uses of it in subsets of simulations, like semi-articulations where you don't want to pay for a proper solve locally and you've got a fixed constraint topology, but I don't have plans for that sort of thing right now.