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.
A bit unfortunate that the test needs ES3.2 and GS, but I got nothing
better right now. Not handling ObjectId yet, for that I need to
implement instancing first (so yes, GCC/Clang will still warn about an
unhandled switch case).
This turned the primitive from being fully defined at compile time to
being mostly dynamically allocated. Keeping just the positions+normals
case defined at compile time, and splitting the function into two
overloads so the extra code can be DCEd when people call the function
with no flags.
To allow introducing tangents and possibly other attributes. This means
the attribute data isn't defined at compile time anymore, but it
would make further additions too annoying to do due to combinatorial
explosion of all variants.
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.
I need a bunch of new test images for shader tests and this was rather
easy to do, considering RLE images are ten times smaller. Not doing the
converter side yet due to time constraints, temporarily relying on
imagemagick to handle that (StbImageConverter does RLE also, but
interestingly it produces larger files than imagemagick).
This code was apparently done before the batch casters were a thing. Now
it's no reason to do the same in two places, additionally in the future
the castInto() could get SIMD-optimized and this can benefit from that.