Build Strategy

[ghost]

This PR separates the BVH construction algorithm from the actual BVH. This will allow there to be multiple BVH construction algorithms without putting them all in the BVH.h file. The algorithms for building the BVH are referred to as "strategies", based on the strategy design pattern. There are currently two:

Build Strategy 0

This is sort of a "dummy" build strategy. All it does is build a single bounding box around the primitives. It's main purpose will probably be to determine the effectiveness of other strategies by relative comparison.

Build Strategy 1

This is the original BVH construction algorithm that was moved out of BVH.h. I wasn't quite sure if the algorithm had a name, but luckily the algorithms aren't differentiated by class name and they differentiated by a "variant index" template parameter. For example:

/* Refers to the "dummy" build strategy */
BuildStrategy<float, 0> strategy0;

/* Refers to the original build strategy */
BuildStrategy<float, 1> strategy1;

/* This will be the build algorithm referred to in issue #14. */
BuildStrategy<float, 2> strategy2;

There's a type definition for using this build algorithm, called DefaultBuilder.

Changes to BVH

The BVH structure went through some changes as well. Admittedly, this probably could have been left out to keep the PR a little bit leaner. Here's the gist of it:

• BVH no longer stores the primitives in a std::vector instance. I'd like to gradually remove the STL dependency, so that this project can be built with CUDA toolkit.
• Some extraneous data, such as the number of leafs in the BVH, has been removed. You can still get the number of leafs in the BVH by calling BVH::countLeafs().

Example

Here's a code example that uses the new class.

std::vector<Sphere> spheres;

/* Add the spheres */

SphereBoxConverter box_converter;

FastBVH::DefaultBuilder builder;

auto bvh = builder(spheres, box_converter);

/* traverse bvh */

This addresses the first item in #14.

[ghost]

Do you have a preference between single commit PR and many-commit PRs? I can squash these once I'm done handling the merge conflicts.

[ghost]

I'll be sure to run clang-format and make the new code consistent with the new line break style.

[brandonpelfrey]

Do you have a preference between single commit PR and many-commit PRs? I can squash these once I'm done handling the merge conflicts.

Good to squash in my mind, at least into logical blocks of functionality if possible. It doesn't need to be single commit, but each commit should be meaningful.

[ghost]

@brandonpelfrey I kept things simple and just squashed all my commits, then made a merge commit. In the future, I'll use fewer commits without squashing so that it's more organized.