We're going to eventually include this class in all Application classes
(need that in order to inherit a to-be-created Configuration class) and
the <string> and <vector> would be just too much. This change caused
magnum-gl-info.wasm (WebGL 2 build) to go down from 247 to 245 kB. Not
much, but that's I guess because there's still a lot other vectors of
strings elsewhere.
There's a lot more places to clean up, will do those in separate
commits. This change is the most atomic I could do, and it introduces a
breaking change to all APIs that returned a std::vector or a
std::string. Fortunately (or as I hope) those weren't used that much, so
it shouldn't cause build breakages for that many people.
Quite a lot of the optimization ideas is borrowed from the new Vk
library -- such as "interning" the driver workaround strings to avoid
allocating their copies.
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.
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.
It's needed to support the new material attributes supported by glTF.
The test output is slightly different as the normal coming from
the texture wasn't normalized before.
Interestingly enough / sadly none of the tests showed a clear difference
when removing the incorrect normalization, so here's a dedicated test
case. Sigh.
Making room for GenerateTangents in 3D, and keeping the 2D ones
consistent with 3D. Also renamed GenerateTextureCoords to
GenerateTextureCoordinates in the remaining places to be consistent with
naming in the rest of the APIs.
Except MeshVisualizer and VertexColor, which don't have any texturing,
so there it's not needed. In most cases the tests are reusing existing
ground truth files and only modifying transformations / flipping images.
Tested on WebGL 1 and 2, SwiftShader ES2 and ES3 and ARM Mali ES2 and
ES3 now, all pass. SwiftShader has a bit different output for zero
shininess, but that's a corner case so I'm not going to investigate
further, just adding the expected wrong output to check against as well.
Note -- since there are no visual tests for Phong yet, this is done in
the least intrusive manner to avoid breaking current functionality. It's
likely very underperforming due to the matric calculation per fragment,
it'll get optimized once I have proper tests.
Slow and ugly, is here only for making quick'n'dirty alpha masked
drawing without a need for blending or depth sorting. Oh and also to
support the glTF alpha mask feature. Again, beware: *slow*.