* Showing a (preferred) CMake 3.13 syntax, as the features of treating
libraries starting with a dash as a link flag is just an internal
and not really documented CMake feature
* Removed reference to --pre-js, as this knowledge isn't needed to
accomplish this anymore. The last paragraph and code snippet was
also redundant.
It doesn't really work for tests that depend on more than one plugin
(because there i would need to handle all combinations, somehow), but it
does the job when the end user has such use case.
First of all, it's quite unusual to have an array of const chars. Then,
it was not really handling file opening errors, which is actually a VERY
BAD THING when you are wondering why your include isn't parsed.
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.
Makes more sense as the function isn't expected to fail (and thus any
kind of lazy population is not possible as it would be too late for
error checks anyway).
*Not* updating interface strings even though this is an ABI break
because we're doing that right after the skin import interface bump.
There's actually a lot of code involved in checking if all textures use
the same transform or coordinate set, especially when considering all
fallback variants and potential future expansion with separate texture
offset/scale/rotation attributes.
A lot of the complexity was thus hidden in plugin implementations, which
were each trying to find a common value for all textures to save the
user from doing the same. All that code can now be removed and left up
to the material APIs themselves -- now it's just about checking
hasCommonTextureTransformation() and then retrieving that one common
transformation, independently on how the material actually defines it.