I was slowly getting cancer from having to write the unreadably awful
VK_FORMAT_R666G666B666A666_SRGB all the time. Besides that:
- All pixel formats are documented to show what's guaranteed for them
by the spec. Pretty useful I'd say.
- The old hasVkFormat() and vkFormat() converters operating on a
VkFormat are deprecated in favor of new hasPixelFormat() and
pixelFormat() that use the PixelFormat enum. Similarly as done in the
GL wrapper.
- All APIs that took a VkFormat before take a PixelFormat now, together
with having conveinience overloads for Magnum::PixelFormat and
Magnum::CompressedPixelFormat. Again similarly as done in the GL
wrapper, also the first step on being able to *directly* use data
imported with the Trade library with Vulkan.
It was printing 0 before, which isn't correct. Also why not print both
values? Printing just the first one would hide issues where the second
is accidentally 0 or some other wrong value.
Such as telling people Sdl2Application is not available on Android, or
that EmscriptenApplication needs WITH_EMSCRIPTENAPPLICATION enabled in
order to be built and installed.
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.
This is a bit huge because of all the new overloads that take a
MaterialLayer instead of a string, but all that is just boring
boilerplate. Additionally this:
* exposes glTF clear coat parameters (which, interestingly enough,
reuse existing attributes and don't introduce any new)
* provides a convenience wrapper in PbrClearCoatMaterialData
* and a convenience base for material layer wrappers that redirect
all APIs with implicit layer argument to desired layer instead of the
base material