Yup, a bunch of relatively small separate meshes interacting with high speed objects is close to worst case for a lack of boundary smoothing.
SpeculativeMargin seems to have no effect.
Is that after modifying both the mesh
and the problematic objects interacting with the mesh? The effective speculative margin of a pair is the max of each member of the pair. To see a change, you'll need to set both to values closer to 0. (This is not without tradeoffs, of course, so it's not the solution I would want to rely on in the long term.)
There is no easy and high quality solution for that specific use case right now. Usually I'd recommend bundling more geometry into a single mesh so you get boundary smoothing, but that's harder for a game with streaming dynamic geometry.
Elaborating on some of the things I mentioned earlier, there are a few classes of solution:
1) Use contact callbacks to modify the normals of manifolds or reject the contacts outright. You can get a sorta-okay solution with heuristics sometimes, but getting all the way to robust behavior is complex (
see MeshReduction). Common failure modes in halfway solutions are not getting rid of all the bumps or just letting objects fall through the world.
2) Combine more geometry into a single Mesh to allow MeshReduction to eliminate all bumps. Wouldn't be able to use the default constructor anymore; the sweep builder would be too slow. It would likely involve constructing per-node subtrees, inserting those subtrees into the Mesh tree, and running incremental refinement on the top level tree-of-subtrees as geometry is added/removed/changed. Done properly, this would let you store the entire geometry in a single Mesh efficiently.
3) Create a custom collidable with a layout compatible with the streaming/dynamic content and use the MeshReduction on its output.
4) Create a version of Mesh which is aware of adjacent border triangles and can use them as a part of MeshReduction to prune out surface-violating contacts. This would look like redundant triangles that don't generate contacts, but are included in the MeshReduction process.
5) Create a top-level contact post-processing step that examines every collidable that could conceivably overlap a contact. Perform a general purpose version of the mesh reduction across all collidables. Most forms introduce significant overhead, so it'd have to be some opt in process.
All of these things
could be done by an enterprising user, but they're pretty difficult. As far as my own plans go:
1) The long term plan does include something like a combination of 2, 3 and 4. Not sure when, >>2 months.
2) #5 is an interesting research project I'd like to fiddle with, but it's kind of hard to justify working on in the near term when there's so much else to do. Wouldn't expect to see it this year.
3) A Tree builder/refinement revamp that would make #2 easier is in the relatively near term plans- <2 months is possible.