BEPUphysics

Hi

Been a while, but I'm getting back in to using this wonderful simulation engine in some XNA hobby work. I've constructed a terrain object and placed it in to the simulation. I'm using re-purposed moon radar images (1024x1024) as the heightmap. I'm trying to be accurate in physics simulation with gravity as well (moon gravity of 1.6xx etc).

I have an oddity that I hope can be explained to me. I'm scaling the terrain quite large to match the moon scale (where 1 unit = 1 metre). So, scaling for say Copernicus Crater (approximately 93Km wide) means a (I believe) a scaling factor of approximately (100000/1024). I.e. The the total scaling needed in metres divide by the width of the height map (I've gone for 100km as the height map extends beyond the edge of the crater).

The simulation objects I'm placing on the terrain are compound. Two long box forms on top of each other with three cylinders (wheels) either side of the lower rectangle. These cylinders have RevoluteJoint attaching them to the lower box. I can spin up the RevolueJoint cylinders via the Motor property to control movement.

Now, at these scaling factors, the object hops (jitters) around on the terrain. When I go for a smaller scale, it settles. Is this a math precision issue in simulation? I've messed about with frictions etc to see if that is the issue, but I think not. Appreciate any guidance. I'm wondering if the solution is going to be breaking the terrain up in to smaller areas (1/4's, 1/8's of the heightmap) - Although does this hit simulation performance?

There could be a few issues at play, all related to scaling/precision in some way. Here are a few possibilities, roughly sorted from most noticeable to least noticeable in this kind of simulation:

1) The object's size is not suitable for the chosen scale. If the object is 1 unit wide but something like the demos ConfigurationHelper.ApplyScale method has been applied with a multiplier of 100, then collision detection for the object will behave poorly. The ApplyScale parameter should be based on the size of the objects that the player is interacting with. So, if the object is 0.5 to 10 units or around there, the default parameters (i.e. ApplyScale(1)) are probably a good bet. (The scale is often based on relative gravity, but since you're simulating a low non-earthlike gravity, the size of the interactive pieces is a better heuristic.)

2) Single precision floating point numbers do not have sufficient precision to represent a 100km area when dealing with a simulated object on the order of 0.5-10m. For that size, a standard desired precision for reasonably accurate simulation is at least one discrete value per millimeter. At 50km away from the origin, there's around one value per 4 millimeters. This would not be kind to the simulation (or graphics, for that matter). To get down to 1mm resolution, a maximum extent of around 10km from the origin would be needed. (It's all relative, though: if the object was 100x larger and the player cared about that scale instead, you could get away with 100mm resolution.)

3) The object is very small relative to the triangles. If it's sufficiently small, the size difference between a triangle and the object may cause collision detection accuracy issues on the edges of triangles. The faces of triangles should behave acceptably even at extreme scales. If edges are affected by relative scale issues, try increasing the terrain's tessellation (in other words, smaller triangles relative to the object).

I'm wondering if the solution is going to be breaking the terrain up in to smaller areas (1/4's, 1/8's of the heightmap) - Although does this hit simulation performance?

Having lots of terrains sitting around is technically harder on the broad phase than having one terrain, but a few dozens objects in the broad phase isn't going to meaningfully change anything performance-wise.

Splitting stuff up alone won't solve the issue, though. Recentering the simulation on where the player is would address #2 above, and splitting could be involved there to keep only the necessary data in the simulation while also keeping the terrain origin near the player (a slight benefit for precision).

Nice comprehensive answer/leads. Thanks. Reckon it's a terrain size vs object scaling issue. I'll tweak around with what you s suggest. Thanks for this ... Really useful!