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.
There will be numerous additions to this one so it made sense to make it
a static library instead of a header-only library. That also allows
CMake users to just link to Magnum::OpenGLTester instead of going
through the pain of a huge branching in order to find a correct
windowless application just to run their tests. It could have been done
even without the static library using a INTERFACE target, but that
wouldn't work on CMake < 3.0 (which, unfortunately, quite a few people
are still stuck with).
Unfortunately it's already heavily used elsewhere so I had to go through
the pain of deprecating the old implementation. The old implementation
was header-only so it can't be just typedef'd to the new one as there
would be linker failures. So the old header is just kept as it was, with
only the macros reduced.
Everything what was in src/ is now in src/Corrade, everything from
src/Plugins is now in src/MagnumPlugins, everything from external/ is in
src/MagnumExternal. Added new CMakeLists.txt file and updated the other
ones for the moves, no other change was made. If MAGNUM_BUILD_DEPRECATED
is set, everything compiles and installs like previously except for the
plugins, which are now in MagnumPlugins and not in Magnum/Plugins.
Headers gl2.h and gl2ext.h shipped with NaCl are different to the
official ones, which is causing linker issues, thus using NaCl's own
gl2.h. They are otherwise similar, thus it should cause no compatibility
issues.
On the other hand, gl2ext.h shipped with NaCl is slightly outdated with
some recent extensions missing. We are including the NaCl's one and then
the official one over it (undefining the include guard). The symbols are
guarded also by extensions, so it should cause no conflicts.
Moved them to `OpenGL/` subdirectory, allowing them to be included
explicitly with e.g. <OpenGL/GLES2/gl2ext.h> overriding the system
<GLES2/gl2ext.h> header. Our versions of the headers are thus now
explicitly included in `OpenGL.h`, but they can be also included using
no-prefix path if no system version is available. It might break some ES
platforms, they will be fixed when found.
The headers are now installed into `Magnum/OpenGL` (not into any
artificial `external` directory). Now also installing GLES2 headers for
OpenGL ES 2 (previously ES3 headers were installed for both ES2 and
ES3).
Vladimír Vondruš