Objects falling through trianglemesh

[ShreeK]

I'm working on porting a game over from JigLibX to BEPU, and I've run into a problem with my player (a simple sphere object) falling through the level.

My level is constructed from several triangle meshes, which are extracted using the example in the Playground demo:
StaticTriangleGroup.getvertsandindices -> trianglemesh(verts, indices) -> statictrianglegroup(trianglemesh)

I'm using angular impulses to propel the player.

Timescale is set to 5f, mass of the ball is around 300

The problem I'm running in to, is most of the levels are composed of platforms that are roughly a fifth to a quarter of the diameter of the player's sphere in thickness. I haven't had any problem with the player falling through the platform, but I have a curved ramp, which launches the player through the air, and he hits a hollow cone with the bottom cut off, which effectively funnels him onto the next part of the level. The ball almost always punches straight through the funnel, or, in the event that I have my aim just right and "swish", he'll punch through the platform below the funnel. If he manages to collide with the funnel (and not fall through), then he's usually moving slow enough that he won't punch through the platform below.

I'm assuming a possible solution would be to thicken up the platforms and funnel, but I'm still doing feasibility testing on BEPU, and would rather my level designers and artists not have to change a bunch of content and then end up not using it.

[Norbo]

If the problem is indeed the velocity of the sphere being such that it passes through an object in a single frame, then you can activate the continuous collision detection system or take more, smaller timesteps.

To enable continuous collision detection:

Code: Select all

space.simulationSettings.collisionDetection.collisionDetectionType = CollisionDetectionType.linearContinuous;

There is some overhead to using it, but not near as much as doing extra updates. There's a fullyContinuous option that takes into account angular motion, but it isn't necessary for spheres. I also plan to make a faster/more robust CCD implementation in an upcoming version.

Another thing that can cause 'fall-throughs' is floating point precision problems in some shape combinations at certain sizes. The sphere has a special case with other spheres, boxes, and triangles, so this won't be an issue. If at some point you see objects (like ConvexHulls or other collision pairings handled by the general-case collision system) jittering on collision or behaving poorly, excessive scale is usually the issue.

Note that excessive geometry sizes can also contribute to issues with the continuous collision detection system, though they are much harder to see. Generally, it's best to keep entity dimensions in a soft range of around 0.5-10 units. Entity dimensions can go outside of that range safely in many cases (I've done tests without visible behavior problems above 200x1x200), but staying in the range helps guarantee stability in all situations.

[ShreeK]

Changing the detection type seems to have done the trick, I'll check back in if I'm still seeing anomalies.

Thanks a bunch!