Advice on reducing floaty-ness of physics?

[aCallum]

Hey,

So we are using the vehicle class and everything is working nicely but we have tweaked all the numbers quite considerably (and in some cases quite ridiculously).

Are there any tips on creating 'good' 'solid' physics? for example, our gravity is -9.81 * 10 !, in order to get the vehicles to fall to the ground at a 'nice' looking rate.. this in turn means the vehicle has a mass of ~1200, and the suspension strength something like 24000..

My concern is that although this approach 'works' it may be causing issues with some of the internal physics - for example, collisions become extremely eratic in some cases.

Although I have implemented the physics config class and played with setting a scale this doesnt appear to have such a huge impact.

Are there any tips for setting up vehicles? Is it a scale problem? (Too small car, too big car? the wheel spans currently measure about 14 units wide and 20 units long) - Wheel diameters between 4 and 6 units (these all seem pretty sensible numbers?)

Cheers

PS - is adding some colidables around the wheels (like a sphere) a good solution to stop wheel colliders dropping into the floor or into other vehicle bodies? (this causes some really bad glitches at the moment with just the wheel colliders)

[Norbo]

Are there any tips on creating 'good' 'solid' physics?

Perceived 'floatiness' is generally just objects being large relative to the gravity, relative to expectations. Increasing gravity or decreasing object size usually addresses the issue.

If that doesn't seem to fix the problem fully, the space might not be simulating the expected amount of time. A fairly common source of this is passing in milliseconds to the Space.Update(dt) method. Space.Update(dt) will simulate as many time steps as it can to keep up with the accumulated time, but the number of time steps it will simulate is capped by the Space.TimeStepSettings.MaximumTimeStepsPerFrame. If milliseconds are passed into the update method but the simulation was set up to consider it to be seconds, the space is essentially being told to simulate ~16 (the number of milliseconds elapsed since the previous frame) seconds of time per frame, rather than 16 milliseconds. The cap limits this to 3 time steps by default, resulting in update rate coupling. Efforts to retune the simulation for the broken update rate never quite fix the issue and leave everything a bit wonky, either going too fast or too slow and never quite right.

our gravity is -9.81 * 10 !, in order to get the vehicles to fall to the ground at a 'nice' looking rate.. this in turn means the vehicle has a mass of ~1200, and the suspension strength something like 24000..

Note that masses do not depend on gravity or object size. Even if the whole simulation size is scaled up, the masses can be left exactly as-is while maintaining equivalent behavior without changing any mass-related tuning factors.

I would recommend keeping the mass at a smaller value, like the ones in the demo. Somewhere between 0.5 for extremely light objects, 1-10 for normal objects, and 50-100 for extremely heavy objects. This avoids any issues with mass-related tuning. (Mass-related tuning is fairly minor- ultraheavy objects just tend to undergo more solving, potentially unnecessarily.)

Watch out for bad mass ratios, though. If a heavy object 'depends on' a light object, solver stability will suffer. For example, if a 1200 mass vehicle rests on a 1 mass box, the box will tend to squeeze out because the system is too hard to solve. The same goes for heavy objects on the end of a chain of light objects- the heavy object will probably tear the chain apart in an ugly fashion.

Light objects can depend on heavy objects without any problem at all, though. A 1 mass object sitting on a 1200 mass object will be perfectly stable.

My concern is that although this approach 'works' it may be causing issues with some of the internal physics - for example, collisions become extremely eratic in some cases.

Could you reproduce the behavior in the BEPUphysicsDemos for me to look at?

Although I have implemented the physics config class and played with setting a scale this doesnt appear to have such a huge impact.

For vehicles or other simulations which don't depend very much on collision detection, the ApplyScale is indeed less important. However, given the gravity and object size, it still might improve behavior overall to call ConfigurationHelper.ApplyScale(10) given the apparent simulation size interpretation.

Are there any tips for setting up vehicles? Is it a scale problem? (Too small car, too big car? the wheel spans currently measure about 14 units wide and 20 units long) - Wheel diameters between 4 and 6 units (these all seem pretty sensible numbers?)

If the gravity of 9.81 * 10 is taken to represent an earthlike gravity, a car 14 units long would have roughly the same perceived behavior as a car that was 1.4 meters long on earth. In other words, it should behave like a smallish go kart. If that is what you intend and observe, then the relative numbers are about right.

Otherwise, there should not be much tuning required to get vehicles and physics in general working well.

PS - is adding some colidables around the wheels (like a sphere) a good solution to stop wheel colliders dropping into the floor or into other vehicle bodies? (this causes some really bad glitches at the moment with just the wheel colliders)

Adding collidables around the wheels can sometimes be a good idea if the wheels are outside of the vehicle body and fully exposed. I assume that's the case, since I'm not sure what else would explain the described behavior.

In general, when using the Vehicle class, the wheel should have a safe starting location within the geometry of the vehicle. That way, sliding up against a wall or something coming from above won't just shove the suspension cast up to maximum compression.

In some cases, vehicles with exposed wheels would be more appropriately simulated with a constraint-based vehicle like the TankDemo, SuspensionCarDemo, SuspensionCarDemo2, or ReverseTrikeDemo. Since they are constructed entirely out of dynamic physical entities, there's no weird corner cases with the suspension. They can be a little more expensive to simulate depending on the setup, though.

[aCallum]

This is great, some fantastic bits for me to investigate - most interestingly the width/length of the vehicles, as you say the current simulation does have some go-kart like behaviour to it!

I also discovered that all the suspension attatchment points had a Y value of 0 - meaning the vehicle was riding very high! I didnt notice because I had instinctively offset the localposition of the body collision info by 10.. I will be re-evaluating these when I look into your commens above.

While I'm on that, can you confirm the local attatchment point for suspension is essentially the point at which the top of the spring is positioned relative to the body?

Oh with regards to iratic collisions, what I should have said is iratic results of collisions - currently the results can be very.. cant think of the word, almost explosive? a seemingly small bump results in a lot of force objects (especially angular) (possibly something to do with the mass? or are there angular momentum limits that can be applied?)

[Norbo]

While I'm on that, can you confirm the local attatchment point for suspension is essentially the point at which the top of the spring is positioned relative to the body?

Yes, it is the top of the suspension spring in the local space of the vehicle's collidable.

Note that there's a difference between being in the local space of the vehicle entity and the local space of the vehicle entity's collidable. The vehicle entity's collidable is offset by the vehicle.Body.CollisionInformation.LocalPosition. So, the fact that the LocalAttachmentPoint is in the collidable's space means it will take into account that LocalPosition when transforming into world space.

Oh with regards to iratic collisions, what I should have said is iratic results of collisions - currently the results can be very.. cant think of the word, almost explosive? a seemingly small bump results in a lot of force objects (especially angular) (possibly something to do with the mass? or are there angular momentum limits that can be applied?)

Mass is unlikely. The inertia tensor is a more likely culprit. If your wheelbase is large but your vehicle body is small, like a tiny sphere floating between the wheels, it's easy to expect rotational behavior like a car with that wheelbase. Instead, since the actual body is just a tiny sphere, you get the rotational behavior of a tiny sphere.

To address this, make the vehicle's body more representative of the vehicle's expected mass layout if possible, or just arbitrarily scale up the vehicle.Body.LocalInertiaTensor. I would recommend the former. Avoiding hacks is a good idea. For similar reasons, I would recommend against applying arbitrary angular momentum limits.

If the inertia tensor isn't related to what you observe, I'll probably need to examine the behavior in the BEPUphysicsDemos to figure it out.

[aCallum]

Good news! The vehicles are behaving much nicer now.

One thing i have noticed is what happens to the suspension when the vehicle is upside down, the wheels return to the suspension attatchment point rather than pushing up to their uncomrpessed distance?

[EDIT] I think this is caused by the suspension dipping into the terran. I guess my wheel guards are not in the right place!