It doesn't really work for tests that depend on more than one plugin
(because there i would need to handle all combinations, somehow), but it
does the job when the end user has such use case.
First of all, it's quite unusual to have an array of const chars. Then,
it was not really handling file opening errors, which is actually a VERY
BAD THING when you are wondering why your include isn't parsed.
Like, it's INEVITABLE to have a 100-line std::lerp() implementation for
questionable reasons but such dead-simple thing as std::pair doing moves
instead of copies where expected that should have been done CORRECTLY
back in 2011 still isn't working reliably across implementations?!
I guess I'm doing my Containers::Pair soon as well, then.
Those were initially implemented and documented when I thought glTF
uses a full cone angle, and I forgot to update them once I discovered
glTF has a half-angle. This is thus now consistent with glTF defaults
again.
Heh, I forgot to run the full test suite after the changes in
1eb1eec271 and then the CI accidentally
had all rendering tests skipped due to missing plugins (which got fixed
in the previous commit, d1ee0b7f7e), so
that didn't catch it either. Sigh.
And also test various potential false positives, which shouldn't be
detected as given format.
*Damn*, I need some utility class for printing this, this is
unsustainable.
Not that either way would be more correct than the other (this is what
three.js uses I think), but it was documented everywhere to be
1/(1 + d^2)
but the calculation instead did
1/(1 + d)^2
This now also means the analytical test equation works. I should have
paid more attention to it not matching before, because that obviously
pointed to this problem.
Point lights are now significantly brighter than before, the tests were
updated to use a larger distance to avoid issues with overflows. Does
not affect the (default) directional lights in any way.