[TODO] Implement spatial split BVH builder

[syoyo]

[syoyo]

Partial implementation is done in sbvh branch : https://github.com/lighttransport/nanort/tree/sbvh

Would an LBVH algorithm count as a spatial split BVH? I have an existing LBVH header only library that builds Sponza in parallel in about 25 ms, under the MIT license. You could use that, if you'd like. It's based on this paper. Even though it has a linear structure though, I'd hesitate to call it GPU friendly, even though it's not recursive, since it requires interleaving integer and floating point types.

There's also this header only BVH library, which provides high quality BVHs with SAH and builds them in parallel as well. On my laptop, which has four logical cores, it builds Sponza in about 133ms. With eight logical cores, that time goes down to about 70ms. The author is also very knowledgeable about BVHs in general. I think the 18ms build time he mentions on the page is from a pretty decent processor. The numbers I gave are from a pretty low end laptop.

[syoyo]

Would an LBVH algorithm count as a spatial split BVH?

No. LBVH does not consider spatial splitting. I have also implemented LBVH in another project(and it also does not consider spatial splitting)
https://github.com/avr-aics-riken/SURFACE/blob/master/render/render_prefix_tree_util.h

As you may know, spatial splitting requires PrimRef data structure(indirect access to primitive).

There's also this header only BVH library, which provides high quality BVHs with SAH and builds them in parallel as well

this BVH library looks nice, but it also does not implement spatial split BVH.

Hey! I'm terrible sorry! It's probably obvious at this point that I didn't know exactly what spatial splitting was when I wrote that comment. My bad!

[cesss]

this BVH library looks nice, but it also does not implement spatial split BVH.

It seems they did implement SBVH now! (actually, the commit seems to be from April 17). However, if you look at the performance comparison chart, you'll see that SBVH is not substantially faster than other algorithms they provide...

[syoyo]

@cess Oh nice! > It seems they did implement SBVH now!

[cesss]

@cess Oh nice! > It seems they did implement SBVH now!

Yes, but I encourage you to improve nanort anyway, because that other BVH library is very demanding in terms of C++ version (it requires C++17, and I prefer to have the freedom of not being tied to too new C++ versions --in fact I decided to move from C++ to C for my main work, because I like C more... I'm wrapping the BVH library for the moment, with a C layer on top of it)

[syoyo]

@cess Yes, we plan to cleanup NanoRT code but it still stick with C++11(e.g. more modern use of C++11 templates, better Python integration with pybind11). After of it we may consider backport madmann91/bvh to nanort(still NanoRT uses C++11). Fortunately the code of madmann91/bvh is rather simple and easy to tweak.