The physics engine does not really care whether 1 unit is 1 m or 1 inch. However, the default settings are all specified in SI standard unit (m, s, kg, …). The default settings are optimized (hand tweaked) for typical action games where, for example, a character is 1.80 m, a crate is about 1m x 1m x 1m, … and the ratio between the smallest and largest object in the simulation is about 1:10.

So there are some cases to consider:

• If you use a different system of units, you have to convert all dependent simulation settings.
• If you use a vastly different scale, you have to make additional adjustments.
• If you simulate both extremely small objects and very large objects in the same simulation, you will have to increase the precision of the physics simulation.

Let's go through these cases one by one:

In this case you have to convert the default settings from SI standard units to the new units. Here is a list of the relevant settings and the units used by the default values:

• ContactPositionTolerance of SimulationCollisionDomain [m]
• ConstraintSettingsAllowedAngularDeviation [rad]
• ConstraintSettingsAllowedLinearDeviation [m]
• ConstraintSettingsAllowedPenetration [m]
• ConstraintSettingsMaxErrorCorrectionVelocity [m/s]
• ConstraintSettingsMaxPenetrationCorrectionVelocity [m/s]
• ConstraintSettingsMinConstraintImpulse [kg∙m/s]
• ConstraintSettingsRestingVelocityLimit [m/s]
• MotionSettingsCcdVelocityThreshold [m/s]
• MotionSettingsMaxAngularVelocity [rad/s]
• MotionSettingsMaxLinearVelocity [m/s]
• SleepingSettingsAngularVelocityThreshold [rad/s]
• SleepingSettingsLinearVelocityThreshold [m/s]
• SleepingSettingsTimeThreshold [s]

So there are quite a lot parameters to change. Therefore, we recommend using the standard units. You can also convert the game objects on-the-fly to or from standard units when interfacing with the physics engine.

Let's assume the game uses a larger scale: Objects are 100 units in size or larger. In this case you need to adjust the settings accordingly. For example, the default ContactPositionTolerance is 0.01 (= 1 cm) which does not make sense in such a scenario. The MaxErrorCorrectionVelocity is 100 (= 100 m/s) which is not enough for really large objects. Etc. Therefore, you should increase all lengths, linear velocities and impulses in the simulation settings by an adequate factor. (Factor 100 for lengths and velocities. Factor 100 or more for impulses - depends on whether the masses are also different.)

The opposite case is when the game uses a smaller scale where all objects are only 0.01 units or less. In this case you will need to decrease all lengths, linear velocities and impulses by an adequate factor. (Factor 1/100 for lengths and velocities. Factor 1/100 or smaller for impulses.)

There is one additional thing you need to do when your objects are really, really small: The DigitalRune libraries use two configurable epsilon values: NumericEpsilonF and CollisionDetectionEpsilon. The epsilon values are used in floating-point comparisons and are required because we are working with floating-point numbers with limited precision (internal: float = single precision = 32 bit). The first epsilon value is used in general math operations. The second is used specifically in the collision detection (and is much larger than the normal epsilon).

The libraries automatically scale the epsilon values when working with large numbers (values >> 1). So simulating a world with a larger scale is no problem. But the epsilon is not automatically scaled if the values are very small (values << 1). In this case the epsilon values need to be adjusted manually. (Note: We haven't yet encountered a case where we actually had to adjust the epsilon values. However, we usually do not simulate objects smaller than 1 cm.)

Consider a game that contains both large objects (e.g. a crate with 1 m) and very small objects (e.g. a die with 1 cm). Now, if the large object falls onto the small objects it applies a force that is extremely big in relation to the size of the small object. In order to solve this situation adequately the simulation needs to perform more time steps and iterations than normally.

You should do the following:

• Decrease the size of a single time step (see TimingSettingsFixedTimeStep),
• and increase the max number of time steps per update (see TimingSettingsMaxNumberOfSteps).

Another example of case #3 is when the game objects are very small (~1 cm), but the gravity is normal (9.81 m/s²). In this case the gravity accelerates an object by a great amount - even in a fraction of a second.

The physics Samples contain a sample, which shows how to set up the simulation for a different scale: "27-SmallerScaleSample"