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.
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.
And clean up the noise from there. This is some very old code, so the
coverage was rather poor, including two uncaught bugs causing
test failures. Fixing that in the next commit.
This is a -- long overdue -- breaking change to the rendering output of
this shader, finally adding support for lights that get darker over
distance. The attenuation equation is basically what's documented in
LightData, and the distinction between directional and point lights is
made using a newly added the fourth component of position (which means
the old three-component setters are all deprecated). This allows the
shader code to be practically branchless, which I find to be nice.
This breaks basically all rendering output so all existing Phong and
MeshTools::compile() test outputs had to be regenerated.
Otherwise the attenuation would explode to infinity at distance < 1,
which doesn't make any sense. This, together with the square of the
nominator, is different from the recommended glTF attenuation in
KHR_lights_punctial, but because I couldn't find any relevant discussion
on the equation used there, I'll assume it's just wrong.
Sigh.