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.
Because We Can. No, actually, this will be used for upcoming material
layers, it's not a bloat. However, this means you can do things like
Trade::MaterialData weDoCssHere{{}, {
{"color", "navy"},
{"highlight", "rgba(35, 255, 78, 0.75)"},
{"dropShadow", "var(--shadow-color)"}
}};
Suited mainly for custom app-specific material properties (e.g., actual
texture pointers and handles), not really planning on using this in
Magnum itself.
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.
Compared to previous AbstractMaterialData, which was always just a
single type, the new data can describe several different materials at
once. This is the case for example with glTF, where a material can be
metallic/roughness but also have an alternative description using
specular/glossiness.
Currently the usage is undocumented, but when everything is in place, if
a material advertises given type, it can be then cast to one of
its convenience subclasses.
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.
The array size is always last, defaulting to 0. This makes it consistent
with the offset-only constructor and removes two unnecessary overloads.
It's a breaking change, but I don't think array attributes have many
users yet -- and better to do this now than later. In any case, sorry
about breaking your code.
While 27f6cc309d made it easier to create
references to attribute-less meshes by avoiding a branch on
attributeCount() (and then using a constructor with explicit vertex
count), code still had to branch on isIndexed() because indices() could
be called only on indexed meshes. This change allows code like
Trade::MeshData reference{data.primitive(),
{}, data.indexData(), Trade::MeshIndexData{data.indices()},
{}, data.vertexData(), Trade::meshAttributeDataNonOwningArray(data.attributeData()),
data.vertexCount()};
which works correctly for all cases and doesn't introduce extra branches
and code paths that would need to be tested. While definitely better, I
might still give up at some point and introduce some
Trade::MeshData::nonOwningImmutableReference() helper for this.
So it can make use of all the APIs in here. Having the utility part of
Trade would make the cyclic dependency a bit weird. Not adding MeshTools
as a dependency just yet, will do that once it's actually needed.
Put the pointer that differs in size on 32 and 64bit platforms last so
we have at least the prefix always stable. This also makes it possible
to extend the class to store 8/16 bytes of arbitrary data in there
(bounds etc.). Not doing that yet, just preparing for possible
extension.