The test scene isn't rendering properly, presumably because
something isn't correct in the parsing (although it's not clear
it's in the mesh parsing). Need to investigate.
The AssemblyBuilder is responsible for collecting the data needed
to actually create an Assembly. AssemblyBuilders are now the
only way to create an Assembly, which guarantees that Assemblies
aren't half-baked.
Also got instancing working with transforms and such. It may not
be _really_ working because I don't have a complex test case for
it yet. But that will come later.
Apparently this is what UnsafeCell is for, and the code I wrote
before wasn't technically correct, even thought it worked in
practice. Hooray for doing things properly!
Includes:
- More scene parsing code. Making good progress!
- Making the rendering code actually use the Scene and Assembly
types.
- Bare beginnings of a Tracer type.
Weird, to be frank. It was a lot of work. Can't believe I don't
even remember doing it before. Oh well.
In any case, I've improved the 'old' one quite a bit. It should
be more robust now, and will provide errors that may actually be
useful to people when a file fails to parse.
Everything is done with indices anyway, so there was no reason
for it to store an internal reference to the object data. This
gets rid of the type parameter and lifetime parameter on the BVH
struct itself, which will also make it easier to bundle it with
the data it indexes, which will be important later on.
Before this the BVH traversal was always traversing into the
same child first regardless of the situation. Now it checks
the direction of the first ray of the batch and compares it
to the split axis of the node, and traverses into the closest
node first.
It yields the objects that the ray needs to be tested against.
Thus it is the responsibility of the code using the iterator
to actually do the object-level ray tests and update the ray's
max_t etc. accordingly.
This keeps all of the BVH-related code generic with respect to
what kind of object/data the BVH actually contains, which means
the same BVH code can be used for both scene-level and
triangle-level data.
The BVH is now generic over any kind of data. The building
function takes in a closure that can bound the given data type
in 3d space, and the rest just works.
Since it's generated code anyway, it doesn't need to be formatted
nicely, and rustfmt was spewing out a bunch of errors because of
too-long lines anyway.
The code here is a bit messy right now. Just did enough to get
it working. But it needs to be cleaned up and report parse
errors in a human-readable way, among other things.
It was using bounds-checked indexing in the basic operations. Now
it's using non-bounds-checked indexing, since all of the indexing
is constants that we know to be within the bounds.
