Bug Report

[andorov]

I have a large triangle soup terrain, on which a capsule slides.

Very rarely (this is hard to reprorduce), the space.Update() function will hang forever, this is the exact function is is forever stuck at. I'll use reflector to look at any possible sources of errors, but obviously, w/o source, debugging this for me is going to be very difficult.

Is this a known issue?

BEPUphysics.dll!BEPUphysics.Toolbox.findConservativeDistanceEstimate(BEPUphysics.Entities.Entity objA = {BEPUphysics.Entities.Triangle}, BEPUphysics.Entities.Entity objB = {BEPUphysics.Entities.Capsule}, ref Microsoft.Xna.Framework.Vector3 positionA = {Microsoft.Xna.Framework.Vector3}, ref Microsoft.Xna.Framework.Vector3 positionB = {Microsoft.Xna.Framework.Vector3}, ref Microsoft.Xna.Framework.Quaternion orientationA = {Microsoft.Xna.Framework.Quaternion}, ref Microsoft.Xna.Framework.Quaternion orientationB = {Microsoft.Xna.Framework.Quaternion}, float marginA = 0.0, float marginB = 0.0, out Microsoft.Xna.Framework.Vector3 separatingDirection = {Microsoft.Xna.Framework.Vector3}) + 0x4c5 bytes

[Norbo]

That particular method is used by the continuous collision detection system, which for a temporary workaround you can turn off by setting space.simulationSettings.collisionDetection.collisionDetectionType = CollisionDetectionType.discreteMPRGJK. This is the default setting in v0.11.0 as well.

However, this sort of freeze shouldn't manifest under normal circumstances. One possibility is that the geometry involved has excessive dimensions. The findConservativeDistanceEstimate is iterative and sensitive to floating point precision problems. Do any of the triangles or capsule have very large or small sizes? Generally, a good rule of thumb is to keep shapes' sizes within a fairly normal range (.5 to 10 units is very safe). This range can be exceeded safely in most cases, but if the system is pushed (1000x1x1000 box) it can create strange inaccurate behavior or, in this method's case, an infinite loop apparently.

v0.12.0 is slated to include rewrites for the GJK/MPR systems as well as for the CCD system in general. While it will still be a good idea to stick to normal sizes, these systems should get both faster and more robust.

[andorov]

The capsules have fairly decent sizes.

Though I suppose the triangle soup could have very small sizes. This is odd though, because the problem is really incosistent. I get it only about once every hour. And it doesnt occur near any particular area. I will test with the other solver and see if I can recreate the problem.

[andorov]

Alright, I'm encountering the error across the board in one form or another.

It turns out, the world transform of player character is getting corrupted. (NaNs)

Now, all I'm doing is pushing around a capsule by modifying its linear velocity directly.

I've checked everywhere, and at no point am I corrupting the data myself (by passing in NaNs or anything like that)...

The problem is also quite infrequent.. maybe once a day.

[Norbo]

The NaN's are probably coming out of the collision detection/contact generation system. With geometry it doesn't like, a degenerate case could theoretically make its way through and maybe get normalized along the way. As soon as something as simple as a single contact normal is infected, the simulation will go down.

The rarity would fit this cause. The corruption could be influenced by things as subtle as the order of updating. A very precise set of circumstances have to be met (relating mostly to floating point precision problems) for it to sneak through.

The findConservativeDistanceEstimate freeze would fit as well. Assuming it ran before the NaN's propagated, it may be a little more sensitive than the other systems and may function as a sort of canary in the mine.

The leading possibility for this sort of crash is still 'bad' geometry, like excessively large or small or otherwise degenerate triangles/entities. If you have any precise numbers or example content, I could try taking a look to see if there are any visible issues.

[andorov]

In some places, the geometry isn't particularly stellar.

But the problem doesn't discriminate where it occurs. Most of the playing field is just flat, nice triangles. Some of the buildings have more funky triangles, but the problem can occur nowhere near those cases.

Is there some way to do post processing on the statictrianglegroups and just throw out near-degenerate cases?

The game is too far in dev to give a small sampling. >.>

[Norbo]

Some post processing might be possible on the loaded version, but it would be much easier to robustly deal with it beforehand at content creation. However, to verify the problem, some kind of example numbers/content would be extremely helpful. I don't need the whole game or anything, just a mesh where the problem can happen or some specific numbers. Otherwise, I'm sort of shooting in the dark

If it is in fact floating point precision problems affecting collision detection and contact generation, you could also try changing the sliding capsule into a sliding sphere. Sphere-triangle has a special collision detection case which handles numerical problems a lot better.