The red and blue boxes are kinematic collision boxes attached to the player for doing ground checks. If the box is at the position of the red box in the above image, BEPU finds a collision between the box and the level geometry, several units down in Y from where the box actually is. However, if the box is at the position of the blue box, there's no collision. Since the blue box is outside of the entire level geometry static mesh, while the red box is inside it
I'm not sure I follow completely. What I'd expect to see in that situation is that the red box will have a pair handler with the mesh, created whenever two collidables have overlapping axis aligned bounding boxes. The blue box, being outside of the mesh's AABB, does not have a pair. But based on the image, neither object should find any contact points. If there are contacts in that configuration, then the graphics are likely offset or incorrect in some way relative to the actual collision mesh.
my guess is that BEPU doesn't handle this case well. Is that an accurate assumption?
As a workaround, we've thought of splitting the collision into individual pieces (in this case, one for the top platform, and one for the bottom/right side). Would this be effective?
The problem shouldn't be happening/isn't expected in the first place, so the workaround may do nothing; fixing the core problem will likely be necessary.
The only difference is the complexity of the level geometry, so our working theory is that it's doing triangle-* collision tests for every triangle in the mesh with every other collidable, since everything is a broadphase hit with the mesh.
A convex-mesh collision pair performs deeper tests against the mesh's own hierarchy, decomposing the problem into triangle-convex tests only for triangles which have AABBs which intersect the convex's AABB. For example, the playground model in the BEPUphysicsDemos is 20,000 triangles, and it runs quite quickly even on the phone because it's only actually testing a handful of triangles at any time.
We think the same workaround will probably help here as well. Does that make sense? Any other suggestions?
In a normal situation, splitting meshes up a bunch will have either no benefit, or possibly lower performance a tiny amount. It amounts to shifting the hierarchy traversal load from specialized mesh trees to the overarching broad phase acceleration system, which, while fast, does not have all the guarantees that the mesh hierarchy has.
Given the very low performance and seemingly incorrect contact points, my first guess may be an old bug in the XNA framework. An overload of the VertexBuffer.GetData method that is usually used for runtime mesh vertex extraction does not work properly on the phone hardware. This may have been fixed by now (I haven't tested the problem directly since before NoDo), and the problem never occurred on the phone emulator or PC/Xbox360 versions.
If I misunderstood and the contacts are being generated in expected locations, and the performance is just very low, then it might be something else. How many triangles would each object collide with generally, and how many objects are in play at any time? The BEPUphysicsPhoneDemo may be a useful baseline to compare expectations against.