Recent searches
Search options
mesh_to_sdf 0.4 is out!
Featuring a new acceleration structure (r-tree) for generic sdf generation (3x faster than my bvh extension) and a fully parallelized version of the grid generation (15x faster than the previous version on a high end cpu).
Shout out to rust concurrency and to @superluminal for the amazing profiler.
https://crates.io/crates/mesh_to_sdf
https://crates.io/crates/mesh_to_sdf_client
https://github.com/Azkellas/mesh_to_sdf
The example below is a 256x256x256 grid sdf.
Finding the good approach to multi-thread the grid gen was not easy and it wouldn't have gotten as fast without profiling to identify bottlenecks.
My first couple attempts were 20% faster but 1000% more cpu intensive.
@Az Looks realy nice!! Looking forward to trying it.
I have a question thought: I take that you are using an r-tree built from the triangles, for triangle culling on the SDF gen, right?
I thought that they where way less coarse than bvh on the last level, so how come there is that much of a perf gain?
Is it a more parallelization friendly in your implementation?
Thanks!
@JsMarq96 Actually the rtree can't be built in parallel, so it's worse than the bvh on that point.
The main reason is implementation details. I extended the bvh crate to support distance queries with minimal modifications to ease upstreaming. So the bvh traversal only uses the bounding box of the triangles to make decisions. This means keeping a (min, max) range and not pruning the tree very efficiently. On the other hand, the rtree was built for this kind of queries and was optimized for it.
@JsMarq96 Since the upstream PR is stalled, I further extended the bvh crate to use the exact distance to the triangle when reaching a leaf node. With this the difference between the two implementations is much smaller. The rtree is still faster, but the bvh is not that far behind (20-30% faster queries for rtree). I guess I'm good for a new release tomorrow. Thanks for the remark!
@Az WOW, it is instant now! Thanks ^^