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.
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.
Originally wanted to offload this to someone else, but then realized I
need those for generic vertex attribute definitions, which I need for
instancing, which I need now. So here it is, at the bottom of the
dependency chain.
It now supports both color+texture (instead of just one or the other)
which made it much simpler to use (and implement as well), also can
reference normal maps and specify texture coordinate transformation now.
The old APIs are depecated, but no tests or other code is updated yet in
order to ensure everything continues to work as before.
Until now, except for an attribute-less index-less mesh, the vertex
count was only implicitly taken from passed attributes, but it was
severely limiting:
- There was no way to set vertex count for an attribute-less
indexed mesh, which didn't make sense
- All code that made non-owning MeshData instances referencing another
MeshData had to explicitly handle the attribute-less corner case to
avoid vertex count getting lost
- Offset-only attributes couldn't be used to specify static layout of
meshes with dynamic vertex count, causing unnecessary extra
allocations especially in the Primitives library.
Similar to image mip level import, but this is largely left to be
importer-specific. For example PLY defines per-face data and sometimes
one might want to import them as-is, without them being turned into a
per-vertex property.
Originally this was done in order to make handling of deserialized data
much simpler (as for those attributes also need to only contain an
offset into some unknown data array), but seems this could be very
useful elsewhere as well -- for example when the layout is known
beforehand but the actual data not yet -- such as in the Line and
Gradient primitives (going to switch them to this in the next commit).
What still unfortunately has to be known in advance is the actual vertex
count (as supplying it directly to MeshData would mean adding 6 new
constructor overloads, and there's enough of those already). Might
revisit later.
Before it was a 32-byte structure with 3 bytes free (or a 20-byte
structure with 3 bytes free), now it's a 24-byte structure with 5 bytes
free. Exploiting the fact that strides can't be too high for a GPU
anyway (so 2 bytes is enough instead of 8), and vertex count is capped
to 32bit by MeshData anyway (so no need for 8 also), saving 10 bytes on
a 64-bit build.
Vladimír Vondruš