BEPUphysics

I am trying to get a box to slide smoothly across a large, flat, StaticMesh. Problem is, the box keeps colliding with the edges of the triangles making up the flat surface. We've tried a large variety of triangle sizes now, and I've noticed that the problem actually gets worse with smaller/more triangles. Are there any settings I should be tweaking that will help sliding behavior?

I've currently experimenting with creating my flat surface out of several Box Entities. My objects are now sliding smoothly, and do not appear to jitter anymore. I still get the occasional catch on an edge, but not nearly as much as before. This doesn't feel like a real solution even though I am seeing improvement.

Boxes will necessarily have a 'bump' at boundaries. The triangles should work, though.

As long as the triangles are connected by an index buffer so that edges/vertices that are adjacent are actually sharing vertices, the boundary improvement system should be able to eliminate bumps.

You can see what is supposed to happen by going to the TerrainDemo in the BEPUphysicsDemos project and setting all terrain heights to 0 to form a perfectly flat tessellated plane. You can drive the vehicle around and push objects without any bumps. All meshes use the same boundary improvement system, so the StaticMesh in the StaticMeshDemo will also behave similarly. I am unable to reproduce boundary bumps in these situations.

If ImproveBoundaryBehavior is set to false, or the mesh's triangles form a disconnected triangle soup, the bumps would return.

By the way, if you are investigating the latest development version and see something weird when two convex objects deeply intersect, don't worry- it's a known bug that snuck in a few days ago that I plan to fix today.

Our triangles ended up not sharing vertices at all! There was an issue when they were being exported from Maya, but that is resolved now. It works much much much better now.

My objects still jitter slightly when sliding though.

Is that in the latest development version? Does the object have non-zero bounciness? If it has bounciness, try setting it to zero and see if that helps. If it does, then the CollisionResponseSettings.BouncinessVelocityThreshold needs to be increased (or you can just keep the bounciness at 0).

Is the surface of the object colliding with the ground larger than 0.5 units? Going below that can occasionally run into contact invalidation thresholds.

I expect a *tiny* amount of jitter when sliding due to persistent contact manifolds, but it should be very nearly invisible unless you're staring at a wireframe and contact data.

I just updated to the latest development version. I also set the object's bounciness to zero. The surface itself is about 60 units in length, but is broken down into triangles which *should* be around or smaller than 0.5 units.

It still jitters, but it does seem to jitter less than before.

but is broken down into triangles which *should* be around or smaller than 0.5 units.

0.5 is the lower bound; going below it can actually start causing problems.

If the sliding object is around 0.5 to 1 units across on its contacting surface, you should be able to easily get away with triangles 10 units long and probably more.

What are the dimensions of the sliding object itself now, and what is its collision margin?

So the size of the sliding object, is more important than the size of the triangles in the surface. Then the amount of triangles being touched by the object only matters when calculating normals (like after a bounce).

I think I've been getting this mixed up the entire time.

My object is around 0.7 units wide. I will try larger triangles in the surface.

So the size of the sliding object, is more important than the size of the triangles in the surface. Then the amount of triangles being touched by the object only matters when calculating normals (like after a bounce).

It's one of many factors.

The reason to increase the triangle count is to split up gigantic triangles that are known to cause numerical issues. If a triangle is large but doesn't cause numerical problems, splitting it up will just harm performance (a little) and increase the usage of less-robust edge case collision detection.

The size of the sliding object's contact surface matters because there are tuning parameters within the engine which manage the placement of contacts within the contact surface. If the contact surface is too small, some contacts may be rejected as redundant even though they are necessary. This problem occurs (mostly) independently from the triangle sizes.

I'm beginning to suspect that some of the jitter you're experiencing is actually due to the long timestep. Even slight persistent manifold jitter will be magnified proportionally with the length of the timestep. Higher quality could possibly be achieved by decreasing some quality parameters in favor of performance (if necessary), and decreasing the timestep to 1/60.

Just as a quick experiment, I tried setting the timestep to even lower at 1/120. There was absolutely no jitter as a result. Unfortunately, I do get some serious frame rate issues on the Windows Phone device when lowering my timestep past even 40. Particularly when there are several objects colliding.

What quality parameters would you suggest decreasing? At this point, I have just about everything at the default value.

The ConfigurationHelper class in the demos shows some options. The "Super speedy" settings might work. Primarily, this makes the solver more performance-oriented by lowering the minimum and maximum iterations. It may be possible to lower the maximum iterations even more.

Replacing complicated convex hulls with simple implicit shapes would help quite a bit in the worst case as well. Simplifying other geometry may help some too.

For reference, I've got 30 boxes (and a vehicle) running pretty comfortably at 1/60 with internal timestepping on the 'playground' demo (20,000 triangles if I recall correctly) on the device. That's without fiddling with any other tuning. If you end up going this route, it might be a good idea to reduce the per-frame max timesteps: Going as low as 2 will sometimes allow the simulation to fall behind a little without entering a vicious cycle where it tries to do 10 timesteps in one frame, taking so long that it necessitates another 10 timesteps in the next frame (and so on). That will smooth out performance spikes a bit.

I made some configurations to match the settings in the demos. I still get the occasional frame rate dip, but it is currently running pretty solid with a 1/60 timestep.

I am still seeing the occasional weird collision with triangles in the surface. I'm not convinced this is a result of the settings changes I made though. It's rare when it happens, but unfortunately it is still noticeable. It's still nowhere near as bad as it was when our triangles weren't sharing vertices. Should I try changing the collision margin next? It is currently still the default value.