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.
* Shader compilation failed with vertex, object and primitive ID
enabled due to the NO_GEOMETRY_SHADER define not being correctly
propagated
* Enabling just vertex ID visualization on WebGL caused an assert in
constructor, complaining that "at least one visualization feature has
to be enabled", which is wrong
* Defaults were not correctly set up for vertex ID rendering, causing
all-black render when setColor() wasn't called
* Forgot to list/bundle some ground truth test images for the test
case, causing the test to fail due to files not found
* The test asserted when generating mesh data due to an unhandled
corner case
* The test expected an ES2 assertion message on WebGL 2
* Flag::Wireframe now implicitly enables Flag::NoGeometryShader also on
WebGL. This was done only for ES2 previously, but WebGL doesn't have
(and won't have) geometry shaders, so it makes sense to do the same
there.
So don't skip the test when rendering just object/primitive/.. ID. Turns
out due to the skip this test was never executed on SwiftShader, and it
thus needs some threshold bumping.
It was rendering everything with a plain color, which is rather useless.
Moreover it wasn't consistent with TBN visualization where you might
actually want only the lines rendered and not the triangle.
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.
This makes existing tests slightly broken, which is good (if it
wouldn't, the thresholds would be too huge). Since the addition of ES3.2
geometry shaders (which broke this) happened long before there were
rendering tests for shaders, this breakage wasn't caught until now. Of
course proper tests would include the perspective case from the previous
commit since the very beginning, but that's hard to do when you're
testing long after the code was written.
The test files are now RLE-encoded, which makes them significantly
smaller (tho I assume Git would further compress both anyway). Not
updating existing files to RLE yet to avoid repo history bloat, doing
that the next time they get changed.
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.
Vladimír Vondruš