StaticMesh With Large Mesh

[jsuffolk]

It's been a long time since I first integrated BepuPhysics into my XNA game, and I really appreciate the engine. I recently, however, ported to MonoGame and so I rebuilt BepuPhysics with implicit type conversions to MonoGame types. This works great except for one thing: StaticMeshes.

The older BepuPhysics version I used for years was very fast at creating a StaticMesh structure out of even a very detailed mesh, but with the latest bits the load time for highly detailed meshes is much higher, and it throws a stack overflow on MeshBoundingBoxTree.InternalNode.GetOverlaps(...). I use collision hulls with simpler hull meshes for other ships and those work fine, but creating an accurate set of hulls would be a ton of work for this behemoth.

To be precise this code is:

Code: Select all

TriangleMesh.GetVerticesAndIndicesFromModel(Model, out vertices, out indices);
ExactMesh = new StaticMesh(vertices.ToArray(), indices, new AffineTransform { Matrix = World });

Any suggestions to get past this? Is my only option to decompose my huge meshes into cleaner hulls?

The huge model I'm referring to is the big ship in this image:

[Norbo]

A stack overflow on a query implies the tree is extremely poorly balanced. In fact, I'd guess it's as bad as it possibly could be, with tree depth roughly linear with the number of leaves rather than logarithmic. A very long build time may also imply something else strange happening like dealing with infinities or NaNs.

That's definitely not expected behavior.

Is the vertex and index data coming in correct, and is the applied transform correct? If the World transform got oopsed into all zeroes by an implicit conversion such that all vertices end up in the same spot, bad things would be expected.

If everything looks correct despite failing, try reproducing it in a BEPUphysicsDemos demo. If it still happens there, I can take a look directly. If it doesn't happen, the conversions or other external stuff would be implicated.

[jsuffolk]

I finally got to the bottom of this. Your advice to try in the BEPUphysicsDemos was invaluable; with the exact same code and model it worked in the demo solution... So not a BEPUphysics bug, but rather a MonoGame issue.

After some investigation I discovered that the GetData(...) methods to extract vertex/index data for a model behave differently for MonoGame (Windows DX11 in my case) return results differently than XNA (I couldn't seem to discern if it was a different format or if it was just plain buggy). I could've went down the route of fixing the MonoGame versions of these methods, but instead I decided created a utility to decode FBXs in XNA and then serialize the vertex and indices arrays into another format (XML) that I load in my MonoGame pipeline instead of the collision FBX. This may be better than the GetData method anyway, since that strategy reads from the GPU and probably contributes to slower load times.