What's the difference between these two calls? Refit says its cheaper, but what's an appropriate time to use refit instead of reconstruct? I'm asking because I've been using refit which works most of the time, regardless of whether I'm just adding/removing a small part of the mesh, or replacing it with an entirely new mesh, but on rare occasions I get an Index Out of Bounds error.
Also, is there any way to reduce the garbage overhead when modifying a mesh? Its my biggest source of garbage generation now.
StaticMesh Refit vs Reconstruct
Re: StaticMesh Refit vs Reconstruct
Refit goes through and updates the bounding boxes of nodes without any modifications to the graph structure of the tree. Refit can be used only when this topology of the tree does not change. This means there should be no additions to or removals from the mesh. (In other words, if the topology changes, assume a refit will fail catastrophically in some way at some point. Even if it happens to work for certain cases now, subtle implementation changes may blow it up.) Transforming the elements of a tree using a rigid transform is a great place to use a refit instead of a reconstruction; for most affine transforms, the original tree topology will still be good enough.
Like the name implies, reconstruction actually performs a full rebuild of the tree. Reconstruction must be used whenever the topology changes and can be used if the mesh is mutated so much that performance suffers due to the poorly fitting tree.
It would be possible to create a custom collidable that uses a custom data structure designed to handle the types of changes common in voxel grids. A common solution is to build a custom collidable based directly on the voxel data. That way, the acceleration structure is implicit and adds/removes are done in constant time. Going down this road requires familiarity with the inner API of BEPUphysics and collision detection, but a well-implemented specialized solution will almost certainly beat out the very general static mesh representation. That well-implemented solution might take too much work, though; insidious problems like the little bump between discrete convex objects, solved by triangle mesh connectivity in the StaticMesh, would have to be figured out for a non-mesh representation.
I've long had my eye on a more efficient and general mutable mesh and mutable static group. The dynamic hierarchy broad phase has all the necessary concepts, but I've not yet bothered to pull it into a system usable by collidables. There are a few annoying architectural issues to work out to make the integration nice and clean.
[I have, however, been fiddling with some graphics stuff for another internal project which relies heavily on large bounding volume hierarchies updating in very short periods of time to reflect arbitrary changes in shape and structure. There's a few appealing options down that road that might influence anything that goes into BEPUphysics. No promises, though
]
Like the name implies, reconstruction actually performs a full rebuild of the tree. Reconstruction must be used whenever the topology changes and can be used if the mesh is mutated so much that performance suffers due to the poorly fitting tree.
StaticMeshes aren't designed for much more than being static. There's no easy way right now to make frequent changes to the mesh allocation-free.Also, is there any way to reduce the garbage overhead when modifying a mesh? Its my biggest source of garbage generation now.
It would be possible to create a custom collidable that uses a custom data structure designed to handle the types of changes common in voxel grids. A common solution is to build a custom collidable based directly on the voxel data. That way, the acceleration structure is implicit and adds/removes are done in constant time. Going down this road requires familiarity with the inner API of BEPUphysics and collision detection, but a well-implemented specialized solution will almost certainly beat out the very general static mesh representation. That well-implemented solution might take too much work, though; insidious problems like the little bump between discrete convex objects, solved by triangle mesh connectivity in the StaticMesh, would have to be figured out for a non-mesh representation.
I've long had my eye on a more efficient and general mutable mesh and mutable static group. The dynamic hierarchy broad phase has all the necessary concepts, but I've not yet bothered to pull it into a system usable by collidables. There are a few annoying architectural issues to work out to make the integration nice and clean.
[I have, however, been fiddling with some graphics stuff for another internal project which relies heavily on large bounding volume hierarchies updating in very short periods of time to reflect arbitrary changes in shape and structure. There's a few appealing options down that road that might influence anything that goes into BEPUphysics. No promises, though
]Re: StaticMesh Refit vs Reconstruct
So I guess its just pure luck that refit isn't crashing more often. I'll switch it over to reconstruct.
It seems like once again a custom collidable would solve my problems, but I'm still afraid to go down that road
. For now it's not a major issue, so I'll hold off on it for the time being.
It seems like once again a custom collidable would solve my problems, but I'm still afraid to go down that road
. For now it's not a major issue, so I'll hold off on it for the time being.