-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comparison with fcpw #26
Comments
Hello, great library! bvh::LocallyOrderedClusteringBuilder<bvh::Bvh, int> builder(bvh); I've started profiling the execution and found that 35% of the time was being spent inside std::fill, and I could track it back to
As I'm working with 3-dimensional vectors, I then replaced the call to fill with: My test scene rendering time went from 8 seconds to 3! Am I using the lib the wrong way? Is there an option that would disable/improve that initialization? Would my change break something somewhere? Thank you! |
Hello! @Janos95 I'll look into this. The library you link seems to be focused on closest point search, so chances are it is going to be slower than this library for ray-tracing. The numbers they give on their page at least seems to confirm that. @cignox1 Please create a separate issue for this, so as not to pollute this one. I suspect that you forgot to compile with optimizations on, or that your compiler is too old and effectively terrible at optimizing very simple code (see this for an example of how a decent compiler optimizes |
So, having a quick look at fcpw, plugging it into my path tracer, I get the following trace:
For reference, the combination
Embree (
This is of course with optimizations on and machine-specific flags ( Because this library can also generate higher-quality BVHs at a slight cost in build times, here's the result of running
So as a conclusion, this library is faster than
Edit: Please ignore the |
Thanks for the super fast response time and detailed benchmark + analysis. |
Hey,
first, great work with this lib, really like using it!
I think it would be great to have a benchmark comparing with fcpw,
which claims to be a very fast BVH implementation. It claims to achieve very fast query times,
by (presumably) vectorizing the slab test with enoki. My feeling is that the tree quality is much more
important, since queries should be latency bound.
The text was updated successfully, but these errors were encountered: