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
Well, "basic". Practically mirrors glTF PBR materials:
- builtin metallic/roughness
- the KHR_materials_pbrSpecularGlossiness extension
- extra normal/occlusion/emission maps
- exposes the implicit metallic/roughness and specular/glossiness
packing, but also allows separate maps with arbitrary packings as
well as two-channel normal maps (instead of three-channel)
- provides convenience checks for the most common packing schemes
including MSFT_packing_normalRoughnessMetallic and the three variants
of MSFT_packing_occlusionRoughnessMetallic
- teaches PhongMaterialData to recognize packed specular/glossiness
maps as well
Next up is exposing at least one layer extension, and then I'm done
here.
The plugin interface version got bumped to avoid ABI issues when loading
plugins that weren't updated for the change, but apart from that this
shouldn't be a breaking change, as the API returns a type that can be
both an Optional and a Pointer.
AbstractMaterialData is now just a typedef to MaterialData, with all
existing public APIs moved to (and marked as deprecated, if they don't
make sense anymore). The new class doesn't have a virtual destructor as
that's not the desired use anymore -- and AbstractImporter::material()
APIs will be returning an Optional instead of a Pointer, which means any
potential subclasses will be sliced away.
PhongMaterialData is reimplemented using the new key/value store,
with no own members anymore -- thus having the same size as
MaterialData, and safe to be casted from it to access the helper APIs.
Better since it has the same prefix as other texture-related attributes,
such as *TextureMatrix(). Not using *TextureCoordinateSet() because
that's overly long, *TextureSet() is OTOH confusing (and especially so
if we'd introduce *TextureLayer()).
Those would be unfortunately very hard to preserve when switching to the
new MaterialData. These accessors mattered mostly only when populating
the instance (i.e., in importer plugins) so such breakage shouldn't be
too much of a problem for regular users.
* 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.
The old one is deprecated, and will be removed in a future release.
Unfortunately, to avoid deprecation warnings, all use of NoInit in the
Math library temporarily have to be Magnum::NoInit This will be cleaned
up when the deprecated alias is removed.
A breaking change, sorry, but I don't want to add yet another layer of
backwards compatibility on APIs that are in master for just a month or
so. This is a test for how many people actually use these APIs -- if
nobody complains, great!
Conflating the fuzzy operation with the discrete one wasn't a good idea,
as people could be unintentionally using the (slower) fuzzy variant on
data that could be easily deduplicated using the discrete variant. One
such case is in the icosphere primitive, and I'm going to look at that
right now.
Vladimír Vondruš