Issues with Instanced Mesh (tiny triangles, frequent moving)
Posted: Tue Aug 16, 2016 4:32 am
Hello!
First of all, thanks for creating BEPU Physics, I love it. Having a well designed, performant physics engine in pure C# is a godsend (saves the pain of updating wrappers for a native one and recompiling for each target platform for starters, plus it's fun to play with! I'll be throwing some money your way soon ).
I have encountered a few minor issues. I managed to find solutions for two of them, but I'd like to check, as I'm not 100 % sure they won't cause some problems down the road.
Performing ConvexCast on a very hi-poly instanced mesh is very expensive when the cast encompases large chunk of triangles. I only need to detect whether there's an intersection or not, but I don't need any details or the number of triangles. What is the best way to do this efficiently?
When I use InstancedMesh collider with a high density mesh, raycast against this collider ignores triangles smaller than certain threshold, while convex body sweep works fine. I have found that this is caused by too large (relatively speaking) Epsilon in the "FindRayTriangleIntersection" function, where it checks for a degenerate triangle. Decreasing epsilon or skipping this check seems to work, as I have decided for the former (so that actual degenerate triangles are still filtered). Could smaller epsilon cause some inefficiencies (or other problems) in other scenarios (most other objects have "regular" sizes).
Sometimes the instanced meshes move every single frame for a period of time. I have found that for very hi-poly meshes (dozens of thousands to millions of triangles - usually 3D scans) this caused frame drop. I have found out that this was caused by recalculating of the bounding box each time I modified the affine transform property, as the recalculation uses all of the vertices.
I have modified this behavior, so it calculates the bounding box for the mesh only once in its default position (that's actually done in my own mesh class, so I just use that data) and then I calculate new bounding box by transforming the vertices of the old one and building a new bounding box from these (essentially treating it as if the original mesh was a box).
I realize this will result in suboptimal bounding boxes for rotated meshes, but stable framerate is crucial (it's VR application). Could having larger bounding box cause some other problems though? Would it be okay/worth-it if I ran an efficient bounding box calculation on background thread once its stops moving and then just assigned it once it's done (I'm not using asynchronous updating at this point)?
Additionally, is there a nicer way to do this, that wouldn't require me to use a modified version of the library (it's not a big problem, but I'd like to avoid making modifications to the library itself if possible)?
First of all, thanks for creating BEPU Physics, I love it. Having a well designed, performant physics engine in pure C# is a godsend (saves the pain of updating wrappers for a native one and recompiling for each target platform for starters, plus it's fun to play with! I'll be throwing some money your way soon ).
I have encountered a few minor issues. I managed to find solutions for two of them, but I'd like to check, as I'm not 100 % sure they won't cause some problems down the road.
Performing ConvexCast on a very hi-poly instanced mesh is very expensive when the cast encompases large chunk of triangles. I only need to detect whether there's an intersection or not, but I don't need any details or the number of triangles. What is the best way to do this efficiently?
When I use InstancedMesh collider with a high density mesh, raycast against this collider ignores triangles smaller than certain threshold, while convex body sweep works fine. I have found that this is caused by too large (relatively speaking) Epsilon in the "FindRayTriangleIntersection" function, where it checks for a degenerate triangle. Decreasing epsilon or skipping this check seems to work, as I have decided for the former (so that actual degenerate triangles are still filtered). Could smaller epsilon cause some inefficiencies (or other problems) in other scenarios (most other objects have "regular" sizes).
Sometimes the instanced meshes move every single frame for a period of time. I have found that for very hi-poly meshes (dozens of thousands to millions of triangles - usually 3D scans) this caused frame drop. I have found out that this was caused by recalculating of the bounding box each time I modified the affine transform property, as the recalculation uses all of the vertices.
I have modified this behavior, so it calculates the bounding box for the mesh only once in its default position (that's actually done in my own mesh class, so I just use that data) and then I calculate new bounding box by transforming the vertices of the old one and building a new bounding box from these (essentially treating it as if the original mesh was a box).
I realize this will result in suboptimal bounding boxes for rotated meshes, but stable framerate is crucial (it's VR application). Could having larger bounding box cause some other problems though? Would it be okay/worth-it if I ran an efficient bounding box calculation on background thread once its stops moving and then just assigned it once it's done (I'm not using asynchronous updating at this point)?
Additionally, is there a nicer way to do this, that wouldn't require me to use a modified version of the library (it's not a big problem, but I'd like to avoid making modifications to the library itself if possible)?