BEPUphysics

Hi,

I'm again here with my earth-sized planets
The planets scale is 2, so I using the Configurationhelper.ApplyScale to scale the BEPU engine down by 4.8 million times.

But now my boxes (pulled to planet by a forcefield) stop in air.
When I spawn them, they start falling down correctly, exactly like they should. But after 1 or 2 seconds they freeze.

I think this is because BEPU freeze them because ApplyScale doesn't affect the minimum speed. So BEPU sees an object to move extreeeeemly slow on normal scale, that it appears to stand still and can be frozen.

Is there any minimum speed value that needs to be scaled too?

Is there any minimum speed value that needs to be scaled too?

There is indeed- Space.DeactivationManager.VelocityLowerLimit. I'll add that to the ApplyScale method.

With such an extreme scaling, you'll probably want to also look into some of the more esoteric values: Toolbox.BigEpsilon, Toolbox.Epsilon, MPRToolbox.SurfaceEpsilon, MPRToolbox.DepthRefinementEpsilon, MPRToolbox.RayCastSurfaceEpsilon, and SolverSettings.DefaultMinimumImpulse.

On the other hand, working on a more regular scale may be easier in general. Floating point numbers have a set amount of precision (23 + 1 bits in singles, 52 + 1 in doubles). Compressing the entire planet into 2x2x2 cube does not actually improve numerical behavior because there's still only that fixed amount of precision.

From a simulation standpoint, you just need to guarantee that you have numerical resolution of around 1/1000 the size of an average-sized object or better (smaller). So, if an average object is around 2e-7 units across, you'll want a resolution around 2e-10 units. To span the entire globe with that detail, you'll need numbers spanning from -1 to 1 with resolution no less than 2e-10. If an object is all the way out at 1 whole unit from the origin, values must be of magnitude ~1 with discrete values available at least every 2e-10 units.

That is around 33 or 34 bits of precision required already, even though numbers are only spanning from -1 to 1. The important thing to note here is that simply rescaling the simulation does not change the bits of precision required. The radix 'floats' as the exponent changes. So, you don't lose anything by sticking to a more regular scale of ~1 unit for the average object and ~6 million units for the planet's radius. If you have enough bits of precision for one, you have enough for the other.

[Of course, to get those 33 or 34 bits of precision, you'll need to use doubles, but if I recall correctly you already are.]

Hi,

Norbo wrote:There is indeed- Space.DeactivationManager.VelocityLowerLimit. I'll add that to the ApplyScale method.

I corrected the value and it was working fine. No freezes here.
But then I activated the StaticMeshes (aka planet surface) again and it was horrible slow. Spawning my shoot box makes BEPU 'think' for 5 to 10 seconds. So I checked

Norbo wrote:Toolbox.BigEpsilon, Toolbox.Epsilon, MPRToolbox.SurfaceEpsilon, MPRToolbox.DepthRefinementEpsilon, MPRToolbox.RayCastSurfaceEpsilon, and SolverSettings.DefaultMinimumImpulse

and played arround with it. I'm not a math pro and checking the methods that make use of the values just confused me even more (and make me feel like a primary-school pupil ). But I was assuming that they defined somewhat of the precision borders of floats. However this didn't solve the extreme performance issues working on this tiny scale.

That made me think of what you said about the regular scales would be more handy. The reason why I decided not to scale up everything was because of this:
You get the best accuracy when working between -1 and 1 (for floats at least). Since I use BEPU on double, the problem is nearly vanished so I scaled the planet up to get 1unit becomes 1 meter in real scale. This isnt just pretty, it solves the performance issue . Internally I still work with the tiny scales, but graphics and physics are now on the new scale (which is the one for what BEPU is designed for, I think).

Only problem left is the creation of StaticMeshes takes arround 20ms to 40ms. The surface is created of voxel volume data and is converted to a smoothed triangle surface made of 64*64 vertices. The conversion and smoothing is just a milisecond. The more mountains we got the more time consuming is the StaticMesh creation

As always thanks for your really detailed answer you do a great job here