StaticMesh penetration / collision problems

[NetSavant]

Hey -

Wanted to get some advice on getting a StaticMesh to reliably prevent entities from falling through - I've searched the forums a fair bit and tried some of the suggestions from earlier posts.

You can see the behavior in this test vid:

http://www.youtube.com/watch?v=qvt0i1_DuLk

Main problems are the planks slipping through the StaticMesh without detection, and also the unchecked spinning through the floor when the planks have some angular velocity.

For reference the floor mesh shown is a grid with 1 x 1 unit triangles, and that cube sticking out is 1 x 1 x 1. The doghouse there is composed of 1.0 x 0.25 x 0.05 planks, stuck together with some custom "breakable weld" constraints. I know the 0.05 dimension is pushing my luck a bit - those overall proportions look nice and play well for parts of the game though, so I'd love to be able to get that shape to work.

My basic settings are:

Code: Select all

BEPUphysics.Settings.CollisionDetectionSettings.DefaultMargin = 0f;
BEPUphysics.Settings.CollisionDetectionSettings.AllowedPenetration = 0f;
BEPUphysics.Settings.CollisionResponseSettings.PenetrationRecoveryStiffness = 0.005f;
// ...
space.Space.ForceUpdater.Gravity = new Vector3( 0, -9.81f, 0 );

I'm updating the space 60 times per second, and with everything going on on some of the more complex levels I'm running close to my CPU budget, so doubling the update interval would be a bummer. If it were the only option I could potentially do it level-by-level though.

What I've tried without much success:

* Scale everything by 10x, 20x (so planks are 10 x 2.5 x 0.5, etc.) including gravity
* Different grid spacing (have tried down to 0.1 x 0.1 squares, so smaller relative to the planks)
* Reverting to the default penetration, margin, recovery stiffness, etc. settings (simulation gets less stable)
* Use continuous position update mode (via the static MotionUpdate settings)

In contrast, a very large floor Box entity does a good job - the planks penetrate sometimes, but usually get corrected within a few frames.

Would stacking a few copies of the mesh on top of each other help, maybe using InstancedMesh, so that the floor isn't just a skin but is backed up by some volume?

Any advice / pointers are appreciated!

[Norbo]

Those dimensions wreak havoc on the general case penetration depth finder used by triangle-convex. The triangle is already a particularly difficult shape due to being infinitely thin. When two very thin objects start intersecting, it gets a bit confused. The collision normals and penetration depths it finds become far from optimal.

Using a box as the ground will practically eliminate the problem because box-box has its own (very robust) special case.

Beyond the MPR implementation getting confused, there are also micro-tuning issues going on. The default margin is 0.04, and, for boxes, the margin is embedded in the shape. 0.05 is so tiny that the shape 'inverts,' causing some pretty weird behavior. Unfortunately, while setting the margin to 0 stops the inversion, it also forces the system to use MPR far more often. It looks like you've tried to tune away the MPR implementation's problems by lowering penetration recovery stiffness, since it tends to generate some spurious penetration depths in hard situations. At that scale, you may also run into issues with contact invalidation thresholds. 0.05 should just barely be okay, but using a slightly larger scale would be more comfortable.

I strongly recommend not setting the allowed penetration to 0, though. That will introduce jitter to the simulation. In addition, I would recommend tuning the margin on a per object basis (entity.CollisionInformation.Shape.CollisionMargin, for an entity using a convex shape) rather than setting the default margin to 0. Other objects will still benefit from having a nonzero margin.

As for solutions, setting them to continuous will stop the 'regular' tunneling problems. MPR or tuning related issues require something more. Scaling up can help to some degree, but the size ratio will still really mess with MPR. Increasing the margin as much as possible will let the more robust surface contact system work in lieu of MPR, just take care not to invert the shape.

In a quick test, I found that scaling up by 5 and setting the collision margin to .1 worked quite a bit better than the default. It's not perfect, and there's probably a slightly better combination of tunings that could be found, but it's functional. If you end up scaling things up, try to scale them up as little as possible. If it goes too far, you'll start to see a whole different kind of problem due to a lack of numerical precision.

Stacking meshes would alleviate some symptoms, but it would not solve the core problem and it wouldn't work really well.

The real solution is something I'm working on. The current MPR implementation is one of the largest problems in the engine at the moment. You may have noticed in the development changelog a new MPR implementation I've been fiddling with. So far I haven't been able to get it to a really decent stage yet, but I'm hoping I can (I'm currently bouncing between about 5 different subprojects).

[NetSavant]

Interesting, thanks - I tried scaling by everything 5x, enabling continuous position updates, leaving AllowedPenetration at 0.005, and setting the collision margin to .1 - the tunneling problem was much improved (I'm assuming that refers to things slipping through the mesh). Still a lot of planks rotating on the mesh surface though.

Re: the tuning settings, most of what I had was based on uninformed trial and error - I'm going to try and devote some time to studying the engine internals and really understand what I'm doing, I think that'd help a lot. Looking forward to that new MPR implementation too, will keep an eye on the changelog.

Along the development vein - are you looking for any contributors now that BEPU's open source? I wouldn't be much use for architectural things and complex physics math with my current knowledge, but would be happy to submit potential changes/patches for any little code-level bugs I might find as I work with the library, proofread inline documentation, etc.

[Norbo]

tunneling problem was much improved (I'm assuming that refers to things slipping through the mesh)

Yup, when an object's displacement in a single frame is greater than the geometry can stop, it can fall through (unless continuous collision detection is on).

Along the development vein - are you looking for any contributors now that BEPU's open source? I wouldn't be much use for architectural things and complex physics math with my current knowledge, but would be happy to submit potential changes/patches for any little code-level bugs I might find as I work with the library, proofread inline documentation, etc.

Certainly, I would appreciate it

[NetSavant]

Got some really nice results using ConvexHull, the collision handling seems really solid on that - so I can probably just divide my scenery collision meshes into convex pieces. Would some kind of ConvexHull + binary space partitioning be a good way to handle StaticMesh's internally I wonder, or are there performance issues etc.? Guess the hulls are solids while the meshes are just a surface, so some conceptual difference there.

[Norbo]

The triangle-based representation is unique and has some advantages, like explicit connectivity information from the index buffer, few assumptions about the content, and extra easy optimizations. ConvexHulls do indeed avoid the current MPR implementation's cantankerousness by adding thickness, but I'd like to eliminate the problem entirely In addition to MPR changes, I'll probably be able to find some ways to improve the triangle-convex manifold's managing of contacts for another quality boost.

I'm in the final stages of testing the base components of the new MPR implementation. Once they're solid, I'm going to try out some new heuristics which should get rid of the thin object problem. A nice side effect of this work is that I may be able to improve other systems (with applications to the new character controller).

[Norbo]

A fairly functional version of the new convex-triangle manifold and MPR implementation is available in the development fork: http://bepuphysics.codeplex.com/SourceC ... evelopment

I've actually been testing with 0 margin and 1x0.25x0.05 planks. The new version is far, far better at handling them. There's still a little extra work to be done, but the vast majority of the problem should be gone now.

[NetSavant]

Awesome - just pulled the latest dev revision, that static mesh demo #10 is impressive.

Been composing my scenery with groups of kinematic boxes so far - I'll try a StaticMesh again with the new dev build and let you know how it goes.

[NetSavant]

So yeah, big improvement with the planks and the StaticMesh - I restored the global PenetrationRecoveryStiffness back to the default and set the margin to zero / PositionUpdate to continuous on the planks specifically. I did get the occasional tunneling or mexican-jumping-bean board, but pretty seldom, not to where it's a problem. The tunneling happened mostly at concave/convex corners where two triangle edges meet, faces and flat surfaces seemed solid.

So thanks for that! Hope to check out the new MPR code - I've been studying the codebase phase by phase, just got done with the DBH broadphase. Onto the challenging stuff next

[Norbo]

I did get the occasional tunneling or mexican-jumping-bean board, but pretty seldom, not to where it's a problem. The tunneling happened mostly at concave/convex corners where two triangle edges meet, faces and flat surfaces seemed solid.

I've got a few ideas left to try. There's two main/known problems left:
-One sided triangle meshes may sometimes reject the normal created from an edge contact since it's facing the wrong way. The subsequent face-based penetration depth tests take over and give a much deeper, incorrect estimate. This should be fixed by correcting the edge contact rather than rejecting it entirely.
-Contact position isn't exactly coincident with where penetration depth/normal is computed. As the penetration is resolved, the contact position may end up in a weird separated state. This may be fixable through changing how MPR computes contact position. The effect is fairly minor, but is more noticeable for smaller objects.

[Norbo]

-Contact position isn't exactly coincident with where penetration depth/normal is computed. As the penetration is resolved, the contact position may end up in a weird separated state. This may be fixable through changing how MPR computes contact position. The effect is fairly minor, but is more noticeable for smaller objects.

My attempt to address this failed, but I did find another bug which would crop up on corners. The first stage would sometimes decide to stop too early based on the configuration of the triangle plane and the convex, stopping supportive contacts from being created. This one is pretty easy to fix.