BEPUphysics

What scale/units does BEPU use exactly (cm's, inches, light-years)? Wasn't really able to find this information, and tried searching the forum but the search results told me to take a long walk off a short plank. This has probably been asked before, so I apologize in advance.

The engine is unitless. You can consider a unit to be anything- within some guidelines.

1) Don't go crazy with the numerical values of things in general.
The engine uses single precision floating point numbers by default. Floating point numbers have more values at smaller magnitudes. For example, there's a ton of values between 9 and 10, but many fewer between 999,999 and 1,000,000.

2) Masses are fairly resilient to numerical error, but crazy values can have side effects. Excessive mass ratios can also cause problems.
The solver uses a heuristic to escape early. This can save some time. If masses are super tiny, it may early-out too fast. If masses are super heavy, it may fail to early-out. The minimum impulse associated with a constraint (a default can be set through the SolverSettings.DefaultMinimumImpulse) can be used to tune this behavior.

A very heavy object will 'squish' a light object. This can sometimes be acceptable, but can also be a bit ugly. The solver has a hard time working out a rigid solution for a system where a heavy object is dependent on a light object in general. The reverse situation of a light object on a heavy object is perfectly stable. To avoid this problem, keep the mass ratio between interacting objects relatively small- the problem can be visible even at ratios of 10:1.

3) Some types of collision detection are more susceptible to numerical error from excessively large values.
It's a good idea to keep object dimensions in the range from 0.5 to 10 units. This applies to individual entities and to individual triangles within a mesh.

There are many special cases built in which typically have better numerical robustness. Box-box, for example, will handle odd sizes very robustly thanks to the directness of the test. Complicated convex hulls colliding with an odd, supergiant, curved minkowski sum shapes will have a much harder time. The tests involved will be more expensive and produce worse results.

4) There are tuning factors in the engine built for the usual range of sizes.
These tuning factors are the source of some behavior problems when sizes get too small (as opposed to problems caused by floating point problems at large scales). The 0.5 in the range above comes from a bunch of little things in the default configuration, like contact invalidation and refreshing. Technically, they can be retuned for other scales, but this is often more work than just keeping things at the right scale.


The 0.5 to 10 unit range is conservative. If you have a bunch of boxes and spheres, you could use a much, much larger range. Even in the worst cases between pairs with no special collision handling, you could most likely get away with anywhere from 0.2 to 200 units, or more. The conservative range just avoids nasty surprises and is a good rule of thumb.

Thank you for your detailed reply Norbo. In reading all that I guess my question can be slightly altered. Seeing as the engine is unitless, if I export a square model, which is 5x5x5cm, and I treat it as 1 unit = 1 cm, am I correct in saying that creating a Box prefab with the dimensions 5x5x5 and a mass of 1 for example, and render my model according to the Box's position and orientation, that model will interact with the rest of the world (in the same scale) as you assume it would?

I did a small test where I created a floor surface and a small box, placed the small box above the floor and allowed it to drop. However it seems to hit the floor slightly above the actual rendered model suggesting that the scale/size of the collision is slightly larger than the rendered model.

This is my first time integrating 3D physics into XNA, and as you can probably tell, having a bit of trouble.

if I export a square model, which is 5x5x5cm, and I treat it as 1 unit = 1 cm, am I correct in saying that creating a Box prefab with the dimensions 5x5x5 and a mass of 1 for example, and render my model according to the Box's position and orientation, that model will interact with the rest of the world (in the same scale) as you assume it would?

Not necessarily.

Sometimes, exporters will 'helpfully' scale models based on some configuration. For example, while in the modelling program it might say 5 units, once it's exported and processed it might become 500 units. You can re-scale the model to match if it is indeed wrong by applying scaling matrices to the world transform prior to rendering.

Another possibility, which seems more plausible given your description, is that the model is not centered on the same origin as the physics object. In the case of a box, a common scenario is that the model was built with the bottom face on the origin. In the physics engine, shapes are centered around their volumetric centers. To address this, the graphic would either need to be offset down by applying a translation matrix to the world transform prior to rendering or by recentering the model on the origin in the modelling program.

Yeah I've made sure that the dimensions have not been scaled after export, I know the FBX exporter in some cases scales everything up by x100, however I'm exporting as .X and it's keeping true to 3DS Max's custom units settings. Does XNA follow this unit-less system as well? I've been exporting my objects in cm's and it seems to line up with XNA's units, so I am assuming there's a relationship of 1 XNA unit = 1 cm.

the model is not centered on the same origin as the physics object. In the case of a box, a common scenario is that the model was built with the bottom face on the origin.

This was exactly the case, solves my floating box issue!

Thank you again for your assistance so far, it's much appreciated.

Does XNA follow this unit-less system as well? I've been exporting my objects in cm's and it seems to line up with XNA's units, so I am assuming there's a relationship of 1 XNA unit = 1 cm.

XNA is mostly or all unitless. The only place you might see it is in a content importer/processor somewhere, but I've never bothered to look close enough to see if it handles unit type metadata or anything like that.

Even if the content was made in a program which labelled the units centimeters, you can still consider it whatever you'd like once you've loaded it. Being unitless means you can pick whatever interpretation you want and, as long as you're consistent (and stay within the bounds of numerical considerations), it'll work fine.

The values you get through the content creation -> content importer/processor can be hard to predict thanks to lots of little fiddly things in the way various programs export. If you find a path which gives you good absolute values with minimal effort, great