So far it contains just the uniform definitions and utilities related
to line drawing, nothing else, but especially the line utilities were
needed to be able to build MeshTools tests on a GL-less build.
The shader requires the input data to be laid out in a rather specific
way, and there will be a dedicated MeshTools utility for it in the
following commits. For independence though, the shader tests use a
custom helper.
The initial implementation has certain corner cases which will be
eventually resolved. For now they are pinned down with repro cases in
the test. But apart from that, it's pretty much usable in practice.
Remaining join styles (round and miter-clip) as well as stipple support
will eventually follow as well.
High-level docs with examples will be written once there's corresponding
support in MeshTools::compile() *and* in importer plugins, as skinned
meshes are usually brought in from files, never set up directly.
Co-authored-by: Squareys <squareys@googlemail.com>
The class is rather heavy (strings, STL vector) and it'll stay heavier
than strictly needed even after the planned STL cleanup -- shader users
should not bear the overhead of Array, StringView etc. that it needs in
order to compile the shader sources.
I might eventually come to a different conclusion (maybe separating
GL::Shader population and usage like doing in Vulkan with CreateInfos),
but right now this commit has the best available solution -- converting
the instance to a lightweight class containing just ID and type, and
then converting that back to a GL::Shader upon checking compilation/link
status.
While at it, also removed the not-strictly-needed Optional usage from
the header. It wouldn't work with forward-declared GL::Shader anyway.
Similar to the change done in Corrade, see the commit for details:
878624ac36
Wow, this is probably the most backwards-compatibility code I've ever
written. Can't wait until I can drop all that.
It limits the support for CMake 3.12+, but it's much less verbose and I
don't expect people to use ancient CMake versions with IDEs like Xcode
or VS anyway, so this should be fine.
Fails spectacularly -- the geometry shader is aware only of instanced
object ID, and of vertex ID not at all. The former was a corner case
TODO while I was adding non-instanced object ID visualization in
033e56ec23 and which I kinda forgot about,
the latter was discovered while trying to fix the former.
Fix in the next commit.
Hah this took a while, as there was no texture scaffolding in place at
all. Thus all this had to be added and tested for the first time:
* 2D textures
* 2D texture arrays
* Texture transformation uniforms
* Texture transformation UBOs
* Instanced texture offset
This also means that MeshVisualizer can be used to visualize arbitrary
(single-channel) integer textures now, not just render meshes with
object ID textures. Yay for feature parity!
Mainly to have feature parity with Flat and Phong -- otherwise switching
to draw a wireframe on an instanced mesh would be too annoying. Also, if
we have multidraw there already, why not instancing as well.
Originally the uniform wasn't present with the assumption that users
could easily adjust color map offset to achieve the same effect. That
was however unnecessarily annoying and error-prone in cases where it's
essential to have the same object IDs from multiple draws have a
matching color, and it was complicating multidraw workflows as the color
map offset was not a part of per-draw data, but rather material data.
In cases when specular highlights are not desired, results in 30%
speedup (on Intel) and ~25% speedup on AMD, compared to setting the
specular color to transparent black.
Testing was easy thanks to already having a ground truth image for this
case.
Took me a while (several years?) to figure out a way to benchmark this
without basically duplicating the testing effort and without new
variants being too hard to add.
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.
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.
No matter how broken iOS is in CMake 3.6, $<CONFIG> seems to work there,
so reducing the amount of code and putting the configure into a single
place independently of what generator or what system/build is used.
Compared to current state it always adds Debug/configure.h instead of
putting it directly to the ${CMAKE_CURRENT_BINARY_DIR}, but the
alternative would be some CMake branching again and I just removed that,
so no.
This also prepares everything for plugin libraries being put into a
central place -- the config files don't depend on their location
anymore.
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.
Vladimír Vondruš