Setting changes for a large scale

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
Zuecafajm
Posts: 2
Joined: Mon Apr 11, 2011 4:25 pm

Setting changes for a large scale

Post by Zuecafajm »

Hello,
So to start off, we have a large, static mesh that is being used as our level. It is mostly cubed, for things like corridors. Through looking at other posts, as well as the examples it seems like there start to be collision issues when you start colliding objects with extreme scales. Our game seems to be starting to run into this as the level meshes are usually 2000x2000 units or larger. Although our scale is fairly uniformly larger, we aren't colliding extremely tiny objects with the huge level.

Just testing prefab collisions against our level, objects fall into the floor, usually up until somewhere near the center of the object before the collision is detected. They are then slowly pushed up out of the floor before stabilizing. Are there some settings that could be changed that would help detect the collisions faster, or correct them more quickly?

I'm not sure how sidedness works with static meshes, and thought the issue may be because we are inside the mesh - so I have that checking for both sides of the mesh. I also have continuous collision enabled.

Thanks for any help,
~Zuecafajm~
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Setting changes for a large scale

Post by Norbo »

Our game seems to be starting to run into this as the level meshes are usually 2000x2000 units or larger. Although our scale is fairly uniformly larger, we aren't colliding extremely tiny objects with the huge level.
What are the sizes of individual objects in the simulation? How big is a player, how big is a single triangle, etc.? Those are the primary factors in determining whether or not the scale is an issue. A level can be 10000x10000 so long as its individual components have reasonable scales.

Scaling everything up uniformly will not escape the problem, since you're still running up against both numerical problems and tuned engine parameters.
Just testing prefab collisions against our level, objects fall into the floor, usually up until somewhere near the center of the object before the collision is detected. They are then slowly pushed up out of the floor before stabilizing. Are there some settings that could be changed that would help detect the collisions faster, or correct them more quickly?
Where does this occur? Is it consistent everywhere, or does it only occur at the edges between triangles? Does it ever happen in the middle of a face?

The most common problem when using large scales is that the single precision floating point numbers used by some algorithms just can't handle it. When this happens, sometimes collisions are missed, sometimes incorrect collision data is found, and sometimes performance decreases (since it's trying harder to figure out the collision). Not all collision algorithms are equally affected by this, though.

For convex-convex cases where there is no special case (cone-minkowski sum, for example), MPR or GJK is used. These are the algorithms which usually fail under extreme scales. Continuous collision detection also uses a form of those algorithms. Box-box, box-sphere, and sphere-sphere all have special cases that have very good numerical behavior, and rarely exhibit any problems at extreme scales.

Triangle-convex is a special case, as well. Collisions on the face of triangles should not exhibit any numerical issues, since it is not using GJK/MPR. Collisions on the edges of the triangles, however, fall back to using MPR/GJK. CCD against triangles may also suffer since it uses a form of GJK/MPR.


All of that said, here's what you'd need to tune for a significantly different scale. These won't fix the numerical problems, but the system will be able to handle them better.
Increase CollisionDetectionSettings.AllowedPenetration
Increase CollisionDetectionSettings.ContactInvalidationLengthSquared
Increase CollisionDetectionSettings.ContactMinimumSeparationDistanceSquared
Increase CollisionDetectionSettings.DefaultMargin
May need to increase GJKToolbox.HighGJKIterations depending on other tuning
May need to increase GJKToolbox.MaximumGJKIterations depending on other tuning
Increase PairSimplex.ProgressionEpsilon
Increase PairSimplex.DistanceConvergenceEpsilon
Increase CollisionResponseSettings.StaticFrictionVelocityThreshold
Increase CollisionResponseSettings.MaximumPositionCorrectionSpeed
Increase CollisionResponseSettings.BouncinessVelocityThreshold
Increase Space.DeactivationManager.VelocityLowerLimit
Getting them properly tuned such that it runs as smoothly as regular scale will take a lot of effort. I would strongly recommend keeping to scales which fit the default tuning.
Zuecafajm
Posts: 2
Joined: Mon Apr 11, 2011 4:25 pm

Re: Setting changes for a large scale

Post by Zuecafajm »

Hello again,
Thank you for the quick response.
I changed those settings, and will continue to tweak them as needed. The problem still occurs but through changing those is resolved much faster than it was before.

To answer your questions, the problems occur in the middle of triangles, but are a bit more drastic near edges. As for the size of individual triangles in our mesh, at the largest end they are about 1500 units tall. The player is currently a capsule with a radius of 35, and most of the other objects have a size similar to the players or slightly smaller.
Thanks for the help,
~Zuecafajm~
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Setting changes for a large scale

Post by Norbo »

at the largest end they are about 1500 units tall. The player is currently a capsule with a radius of 35, and most of the other objects have a size similar to the players or slightly smaller.
While you will be able to eventually get something with somewhat acceptable behavior by changing the tuning, it may be easier in the end to just resize everything. Scaling by ~1/35 or ~1/70 would put everything into the preferred range by the sounds of it.

Generally, having entity dimensions in the 0.5 to 10 range keeps things working very safely. The occasional shape being a bit larger (10-50) than that probably won't be an issue.
Post Reply