The whole point of these formats is to compress down to less
space, so let's not leave actually putting it in the space-saving
form on the client code.
It is identical to the 32-bit format, except with more precision
and range due to using more bits. This format should comfortably
store any color information with precision easily exceeding the
limits of human vision.
This also makes encoding faster. However, it no longer does
rounding to the nearest precision when encoding, and insead does
flooring. This seems like a reasonable tradeoff: if you want more
precision... you should use a format with more precision.
It was a worthwhile experiment, but for it to really work it needs
a really proper luma-chroma separation, which is both slower than
I really want, and requires knowing the colorspace being used.
I might make another go at this based on the TIFF LogLUV color
format, requiring XYZ as input.
After thinking about this and after some discussion with other
people, I now believe that hierarchical instancing isn't actually
that useful in practice for rendering.
Single-level instancing is still supported, of course.
This allows the error messages to be more informative by including
dynamically determined information.
Also made a utility function for ensuring that nodes get closed.
All rendering code is commented out for now. It will need to be
largely rewritten after this refactor is done, most likely.
This commit gets the basic new scene parsing working, with the basic
new data structures.
Specifically:
1. Factored out color exporting.
2. Switched floating point writing to use .format() with 6 digits
of precision. The main gain here is that numbers like 1.0
don't print with a bunch of useless trailing zeros.
The importance change here is bundling object data and its
instances together. This makes it possible to process the
scene data (e.g. for splitting, dicing, and de-instancing)
without having to cache arbitrary amounts of scene data.
In other words, this should allow for much more efficient
scene processing down the line.
Before this it needed SSE 4.1, which is not strictly present on
all x86-64 platforms. This will still compile the faster path if
SSE 4.1 is available, but has an alternate path as well for all
x86-64 platforms.
The biggest one is avoiding a bunch of bit reversals by keeping
numbers in bit-reversed form for as long as we can.
Also reduced the hashing rounds: just 2 rounds seems to be enough
for a reasonable amount of statistical independence on both the
scrambling and shuffling. I tested both independently, keeping
the other with no scrambling/shuffling respectively. This makes
sense because in normal contexts 3 is enough, but in this case
both act as input to yet another hash which is effectively doing
more rounds.
