TriangleMesh/StaticTriangleGroup collision issues

[vintagegames]

I have a .fbx model of a glass dome. I load it as a Model obj and then will use the following code to obtain a StaticTriangleGroup:

Code: Select all

// Create a StaticTriangleGroup based upon the 3D Model to be used for physics interaction
StaticTriangleGroup.StaticTriangleGroupVertex[] staticTriangleVertices;
int[] staticTriangleIndices;

StaticTriangleGroup.getVerticesAndIndicesFromModel(_displayModel.Model, out staticTriangleVertices, out staticTriangleIndices);
TriangleMesh mesh = new TriangleMesh(staticTriangleVertices, staticTriangleIndices, 0);
_object = new StaticTriangleGroup(mesh);

I then will add this StaticTriangleGroup to my BEPUPhysics Space obj so that I can have collisions happen off of the glass dome surface.


I'm having intermittent problems with Cylinder entities being able to completely pass right through this glass dome StaticTriangleGroup obj if the velocity is high enough, or if the Cylinder is positioned in such a way that only one part of the rounded edge contacts the StaticTriangleGroup obj first. I have a feeling that the collision detection between Cylinder and StaticTriangleGroup is not as accurate as Entity on Entity collisions.

So with a complex shape like a StaticTriangleGroup, how can I efficiently create an Entity obj so that I can get better collision detection? Am I going in the wrong direction?

I can submit code samples or even videos if needed to illustrate the problem.

[Norbo]

It sounds like there might be some scale issues going on. The StaticTriangleGroup uses normal entity-entity collision detection (individual triangles versus the colliding entities). If a triangle is irregular (very long, thin) or just too large, you may find that objects can 'punch through' or, in the case of resting entities, jitter. This is because of floating point precision issues in the generic entity-entity collision detection system.

Basically, if the triangles composing the dome are larger than around 10-20 units each or if they are very thin relative to their length, try tessellating or rescaling the dome to make the triangles more regular. 10-20 units isn't a hard limit and the system can often handle higher values, but it's a good starting point.

Of course, this assumes that continuous collision detection is enabled. It's on by default, so unless you set the collision detection type to discrete manually this won't be an issue.

A video of the behavior may help if it isn't related to scale.

Edit:
The collision detection system can also have problems with excessively smalls scales. If the puck is very tiny or if the entire mesh is very tiny, you could see issues. Generally the soft limits for sizes range from .5 to 10, though again, it can usually handle sizes outside of that.

[vintagegames]

I can provide a video in wireframe view which will show the sizes of the triangles of my "Dome" relative to the sizes of the Cylinder Entity I'm using to shoot at the Dome.

[vintagegames]

Here's a video I made illustrating:
http://www.gamecamportal.com/vpv.aspx?vidid=649


Also, it's important to note that I've tried variations of my "Puck" both with a simple Cylinder and with a Cylinder with 12 Spheres around the edges (to help it roll over flat and not on edge) and also with a WrappedBody around the Cylinder and 12 Spheres. (This video is with the Cylinder and 12 Spheres...)

[Norbo]

What are the overall scales like (size of puck and overall size of mesh)? Does the simple single cylinder puck behave any better or worse when it comes to going through the wall?

I couldn't tell for sure, but it looks a bit like the walls are composed of some long, thin triangles as well. If the overall scale is good, the collision detection system may still run into some issues with long, thin triangles. Splitting these into more, normal triangles might help.

You might also try setting the second row or all rows of the puck's inverse inertia tensor to zero and see how that works. It would keep the puck from flipping on its side, and the lessened rotation may make it easier on the continuous collision detection system.

[vintagegames]

I think the Triangle Entity collision detection with a Cylinder Entity has some bugs.

I've added the following Entities to either end of my "ice" (these will represent goal nets, 2 Triangles for sides and a 48deg sloped Box for the back of the net)

Code: Select all

Box goalBackHome = new Box(Vector3.Zero, 12.5f, 9.5f, .2f);
                goalBackHome.worldTransform = Matrix.CreateScale(1) * Matrix.CreateFromYawPitchRoll(MathHelper.ToRadians(90), MathHelper.ToRadians(48), 0) * Matrix.CreateTranslation(new Vector3(-43.8f, 2.6f, 0));
                space.add(goalBackHome);
                Triangle goalLeftSideHome = new Triangle(new Vector3(-40f, -1f, 6.35f), new Vector3(-40f, 6.5f, 6.35f), new Vector3(-48f, -1f, 6.35f));
                space.add(goalLeftSideHome);
                Triangle goalRightSideHome = new Triangle(new Vector3(-40f, -1f, -6.35f), new Vector3(-40f, 6.5f, -6.35f), new Vector3(-48f, -1f, -6.35f));
                space.add(goalRightSideHome);
                Box goalBackAway = new Box(Vector3.Zero, 12.5f, 9.5f, .2f);
                goalBackAway.worldTransform = Matrix.CreateScale(1) * Matrix.CreateFromYawPitchRoll(MathHelper.ToRadians(90), MathHelper.ToRadians(-48), 0) * Matrix.CreateTranslation(new Vector3(43.8f, 2.6f, 0));
                space.add(goalBackAway);
                Triangle goalLeftSideAway = new Triangle(new Vector3(40f, -1f, 6.35f), new Vector3(40f, 6.5f, 6.35f), new Vector3(48f, -1f, 6.35f));
                space.add(goalLeftSideAway);
                Triangle goalRightSideAway = new Triangle(new Vector3(40f, -1f, -6.35f), new Vector3(40f, 6.5f, -6.35f), new Vector3(48f, -1f, -6.35f));
                space.add(goalRightSideAway);

I will provide a video of my clicking and firing my Cylinder Entity (puck) at the Triangle sides compared with the sloped Box side of the goal. No pucks get through the Box, but every puck gets through the Triangle entity.

[vintagegames]

http://www.gamecamportal.com/vpv.aspx?vidid=657

[Norbo]

The triangle-cylinder collision detection system is the same as the box-cylinder collision detection system. The difference is the shapes themselves, mainly the triangle's thinness.

However, the main issue here is the the continuous collision detection system (CCD, which is also the same between box-triangle and cylinder-triangle) getting stuck in a situation where there is a very high angular velocity while the objects are already in contact. The CCD system basically gives up since the objects are already colliding and can't stop the rapidly spinning entity from penetrating through the obstacle in the next frame.

Every bit of thickness helps alleviate this effect, which is why you notice it less with the box. With persistence, you will probably see the cylinder ram its way through the box too.

There's a few ways to go about addressing this.

-Set the puck's inertia to infinity (puck.localSpaceInertiaTensorInverse = Toolbox.zeroMatrix;). If the puck can't rotate, it will be a lot easier for the system to deal with.
-Constrain the puck's maximum angular speed (and maybe linear speed too) with a MaximumSpeedConstraint.
-Decrease the time step. This is the brute force method. By taking more, smaller steps, the engine has time to adapt to the high speeds. (space.simulationSettings.timeStep.timeStepDuration = something lower than 1/60f, and space.simulationSettings.timeStep.useInternalTimeStepping = true if you want the engine to handle updating the right number of times).

A new continuous collision detection method may also be available in a future version (not the upcoming v0.11.0, but most likely v0.12.0). It's sort of a quicker approximation that will miss some collisions in chaotic situations, but would be more likely to catch the situations you're running into. Combined with some contact prediction, it may end up being the preferred method.

[Norbo]

Also, you can try increasing the triangles' collisionMargins. This has the effect of fattening them up.

[vintagegames]

1) I added collisionMargin of .4f to each of the (4) Triangle entities. It appears that I'm getting a Sphere of .4f radius around the center of the Triangle, because now when I fire pucks from 90deg perpendicular to the Triangle flat portion, it is bouncing off in every direction as if it is a round object. How does collisionMargin work? I would expect that the entire Triangle would essentially have "margin" applied to all sides and vertices as if it were wrapped in .4f width of "candy coating" in every direction.

Code: Select all

                goalBackHome = new Box(Vector3.Zero, 12.5f, 9.5f, .2f);
                goalBackHome.worldTransform = Matrix.CreateScale(1) * Matrix.CreateFromYawPitchRoll(MathHelper.ToRadians(90), MathHelper.ToRadians(48), 0) * Matrix.CreateTranslation(new Vector3(-43.8f, 2.6f, 0));
                space.add(goalBackHome);
                goalLeftSideHome = new Triangle(new Vector3(-40f, -1f, 6.35f), new Vector3(-40f, 6.5f, 6.35f), new Vector3(-48f, -1f, 6.35f));
                goalLeftSideHome.collisionMargin = .4f;
                space.add(goalLeftSideHome);
                goalRightSideHome = new Triangle(new Vector3(-40f, -1f, -6.35f), new Vector3(-40f, 6.5f, -6.35f), new Vector3(-48f, -1f, -6.35f));
                goalRightSideHome.collisionMargin = .4f;

I can supply a video to show this as well if needed.

2) Setting localSpaceInertiaTensorInverse is not an option, as the puck MUST be able to roll over and rotate and spin. The game just wouldn't be realistic without it.

3) I will try constraining angularVelocity and see if that helps.

[vintagegames]

For my #1, I think I had a different issue...an Entity was not translated property and was affecting physics right where my Triangle entity was located.

[Norbo]

If you still would like some more information about how collision margins work, you can take a look at this thread:
http://bepu-games.com/forums/viewtopic.php?f=4&t=409

It's basically a bit of extra width to allow a fast, general case collision detection system.