Question about physics unit :)

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
-=Magic=-
Posts: 41
Joined: Thu Jun 30, 2011 11:32 am

Question about physics unit :)

Post by -=Magic=- »

I restarted to work on my "old" slot-car game.

I would like to know if the unit size that I'm using are ok.

Here the "real" size of a car:
* Length 150mm = 0.15m
* Width 64mm = 0.064m
* Weight 90gr = 0.09Kg
* Wheel diameter 21mm = 0.021m
* Wheel width 11mm = 0.011m

In order to stay into the range of 0.5 - 10 units, I'm using 1cm = 1 unit
So I've a gravity of -981

But what about mass? could be ok if I use a mass of 0.9 [in order to stay into the range 0.1-100] ?


Are the units well sized in order to have a good collision response from the engine?
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Question about physics unit :)

Post by Norbo »

The sizes would be acceptable for the default tuning, yes. It may be marginally better if it was more like 5 units rather than 15, but the difference is probably negligible.

You can also use something like the BEPUphysicsDemos's ConfigurationHelper.ApplyScale method to retune the engine for your desired scale.
But what about mass? could be ok if I use a mass of 0.9 [in order to stay into the range 0.1-100]
Mass is independent from the size scale choice. The important thing is that the mass ratios between objects are well controlled to avoid instability when something very heavy rests on something very light.

The only secondary concern is the SolverSettings.DefaultMinimumImpulse, which affects the solver's ability to early-out. Very light objects will tend to hit this threshold more frequently. That said, 0.9 should work pretty well with the default value. If you end up seeing instability on light objects but not heavy objects, increasing this value may help.
So I've a gravity of -981
The size of gravity relative to the objects is likely going to be a problem regardless of whether the size scale is a meter or a centimeter. It's an extremely fast acceleration relative to the standard time step duration of 1/60f. Consider that you start having to worry about tunnelling at around a velocity of objectSize / (2 * dt). For a 15 unit car falling along its long axis, this corresponds to 450 units per second. That value of gravity would reach 450 units per second in ~28 frames, or less than half a second of free-fall. Heavy interpenetration will happen much sooner than half a second, too.

While continuous collision detection can help with this issue, I would not recommend relying on it too heavily. Instead (or in addition to CCD), I would recommend using a much faster time step duration, like 1/240hz or even higher. This will also significantly improve the behavior of the cars moving around the track, since they're probably very quick relative to their size.
-=Magic=-
Posts: 41
Joined: Thu Jun 30, 2011 11:32 am

Re: Question about physics unit :)

Post by -=Magic=- »

Another important thing that I forgot to mention is the siz of the "slot", where the "paddle" of the slot-car should be inserted, in order to drive the car through the track.

the paddle is a deformed cylinder, like the central image:
Image

the width of the slot is 4mm, and this is the most important aspect to tune, in order to reduce penetration and bouncing.

which are the parameters that I should set in order to better reduce penetration?

I'm trying with 1cm = 1 unit, but I also would like to follow your suggestion of 0.33cm = 1unit ("It may be marginally better if it was more like 5 units rather than 15").


With a slot of 4mm, this means that the slot is 0.4 unit with [1cm = 1 unit], or 0.132 unit with [0.33cm = 1 unit].
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Question about physics unit :)

Post by Norbo »

which are the parameters that I should set in order to better reduce penetration?
If the sizes are in the default tuning range, there should not be much extra tuning required. You may find it useful to fiddle with individual settings later, like the CollisionResponseSettings.MaximumPenetrationRecoverySpeed, but that's hard to predict without testing the behavior. The most important parameter is the Space.TimeStepSettings.TimeStepDuration; a sufficiently short update rate is the best way to improve simulation quality.

The rest of the tuning parameters can be found in the BEPUphysicsDemos ConfigurationHelper.ApplyScale function. This can be useful if you want the engine to work with a scale which isn't the default.

Also, for keeping a slot car in a slot, it may be better to use a dedicated constraint that pulls the car around (like a SingleEntityLinear/AngularMotor) rather than a colliding object. This would reduce the update rate requirements a little and make it less sensitive to fine details of collision detection.
-=Magic=-
Posts: 41
Joined: Thu Jun 30, 2011 11:32 am

Re: Question about physics unit :)

Post by -=Magic=- »

Also, for keeping a slot car in a slot, it may be better to use a dedicated constraint that pulls the car around (like a SingleEntityLinear/AngularMotor) rather than a colliding object. This would reduce the update rate requirements a little and make it less sensitive to fine details of collision detection.
Right now i apply an impulse on the back of the car which has a revolutejoint constraint with the paddle (can rotate only arou d the Y axis).

May you explain a bit more your suggestion?
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Question about physics unit :)

Post by Norbo »

May you explain a bit more your suggestion?
Relying on paddle collision with the slot is asking a lot of the simulation. It would likely require a very short time step due to the speeds the car moves at relative to the size of the paddle. If you have the compute power available, then making it this short isn't really a problem and you don't need to worry about implementing any tricks. Indeed, doing it the physically 'correct' way is preferred if you can afford it.

If you do not have that much compute power available, then getting rid of the paddle as a control mechanism completely and controlling the car's motion directly along the track would make the simulation much easier to solve properly. This means longer time steps would work.

One possible implementation of this would be to just set the LinearVelocity and AngularVelocity directly to whatever values accomplish the motion you want. This would require some kind of path representation for the track that is evaluated to find the next frame's position.

Similar to the above, you could use SingleEntityLinear/AngularMotors to control the motion instead of setting the velocity properties directly. The constraint version may be more stable when many different constraints are fighting each other. If you don't expect constraints to fight in normal operation, using constraints instead of just setting velocities won't have much value.

It would also be technically possible to create your own constraint to bind the car to the track. This would be a little more physical than the full velocity control methods. Basically, instead of relying on collisions, there would be a dedicated point-on-path constraint. This would require some familiarity with the engine and solver to implement, though.

All of these alternate options would need some mechanism to choose to 'release' the car from control if the car should fly off the track. This could be done by checking for collision or measuring acceleration.
Post Reply