Deforming a StaticMesh

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
ntd master
Posts: 10
Joined: Wed Nov 24, 2010 9:29 pm
Location: United States
Contact:

Deforming a StaticMesh

Post by ntd master »

Hey guys,

I was wondering what the best way is to deform a StaticMesh at runtime. Is there a good way to do it?

Right now all I can think of is to re-calculate my StaticMesh's vertices and indices everytime it gets a crater like impact that deforms it...and then remove the StaticMesh, and create a new StaticMesh with the updated vertices and indices.

This method gives me the exact result I want, which is the good part....unfortunately, the bad part is that creating a new StaticMesh every time there's an impact causes a very noticeable performance hit even when using multithreading. I've tried to just put my calculated values into staticMesh.Shape.TriangleMeshData.Indices and staticMesh.Shape.TriangleMeshData.Vertices, but that doesn't seem to do anything. Anything obvious I might be missing here?
Follow on Twitter: Vulture Games
Official Website: Vulture Games Studio, LLC
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Deforming a StaticMesh

Post by Norbo »

If the impact does not change mesh topology (meaning the number of vertices and the index buffer are unchanged), then all you need to do is:
-Change the vertex values as necessary.
-Call the StaticMesh's hierarchy's Refit method to update the structure. (staticMeshInstance.Mesh.Tree.Refit()).

A Refit is much faster than creating a new StaticMesh because the hierarchy is not reconstructed; there is no garbage created and the computations involved are much simpler as well.

If the topology changes, then it is going to be harder computationally. That requires a mesh reconstruction. You can force this using the tree's Reconstruct method, though this will create garbage and is quite a bit slower. It's the primary cost associated with creating new StaticMesh instances.
even when using multithreading.
Multithreading does not apply to one-off things like mesh reconstruction or refitting. You could implement a multithreaded version yourself, but it would be a bit annoying and probably not worth it.
Anything obvious I might be missing here?
One option may be to have multiple, smaller StaticMeshes. Not a huge number of them, but enough such that one impact won't have to recompute data for the entire world. Handling the boundaries between the meshes would be a little tricky. If multiple impacts occur at once or multiple meshes are affected at once, the changes could be trivially handled in parallel (apart from the boundaries, anyway) for an extra speedup.

If topology does't need to change, then you may want to just use a Terrain if possible. A Terrain has no reconstruction time for changing heights; its acceleration structure is implicit in the heightmap grid.

There may be some additions to the BoundingBoxTree later which would be useful for this scenario. If the fracture simulation is found to benefit substantially from hierarchy removals (for topology changes), it will probably be added. It's too early to tell if it's really needed though.
ntd master
Posts: 10
Joined: Wed Nov 24, 2010 9:29 pm
Location: United States
Contact:

Re: Deforming a StaticMesh

Post by ntd master »

Hey Norbo,

Thanks for the help. I had fooled around with Reconstruct a little, but as you mentioned it creates garbage and definitely was slower so it didn't really give me the results I was looking for. Refit() seems to work great though, so it looks like I can just use that.

So now after I get my mesh info, it's just:

Code: Select all

_deformableMesh.Mesh.Tree.Data.Vertices = collisionMesh.Vertices;
_deformableMesh.Mesh.Tree.Data.Indices = collisionMesh.Indices;
_deformableMesh.Mesh.Tree.Refit();
Norbo wrote: Multithreading does not apply to one-off things like mesh reconstruction or refitting.
I was wondering about that. Good to know.
Norbo wrote: If topology does't need to change, then you may want to just use a Terrain if possible. A Terrain has no reconstruction time for changing heights; its acceleration structure is implicit in the heightmap grid.
If I have to deform a mesh that's bigger in the future, I might try to take this approach.
Norbo wrote: There may be some additions to the BoundingBoxTree later which would be useful for this scenario. If the fracture simulation is found to benefit substantially from hierarchy removals (for topology changes), it will probably be added. It's too early to tell if it's really needed though.
That'd definitely be a sweet feature down the line.
Follow on Twitter: Vulture Games
Official Website: Vulture Games Studio, LLC
Post Reply