This is the first builtin array attribute, with one of the objectives
being an ability to support an arbitrary count of per-vertex weights in
a single contiguous attribute without the complexity of having to go
through several four-component attributes.
On the shader side it still needs to get cut into at most four
components per attribute, but there's no reason for such limitation to
get propagated here as well.
Co-authored-by: Vladimír Vondruš <mosra@centrum.cz>
I realized those are too annoying when writing a glTF exporter which
contains a lot of switches over enums. And as further shown by the diff,
those were only inflicting additional pain in *all* switch statements,
nothing else, no other added value. And everywhere else the helpers are
the designated way to deal with those, so there's no point in having an
explicit enum value denoting start of a "custom range".
It wasn't even any convenient to have it in the enum, as the extra
effort needed for casting actually made it *exactly* the same length as
if I'd just use a separately-defined constant.
Like, it's a *debug printer*, why an inline call would matter in there.
Or maybe it's that the debug printer was done way earlier than the
helpers? ... and then copied, without a brain attached to my head, from
MeshData to the new SceneData?
Again not publicly documented because I don't like the naming and I
don't have the full behavior and interactions figured out yet -- i.e.,
an array of VertexFormats would be printed with Debug::packed as a long
string of characters without any whitespace. Not good, thus this
feature probably needs to be split in two, with this being named
"compact" or something else.
It was a clever harmless trick. Well, it was way more harmless than it
was clever, but even then it caused UBSan to complain. And that's Not A
Good Thing for various reasons, so let's just comply.
The main bad effect of this change is a *slightly* larger list of
exported symbols but until we actually get rid of the major bloats like
<iostream>, <string> and the like, this is not going to have any
measurable impact.
The previous commits changed *nothing* related to this code, yet somehow
a Release build started warning about this variable maybe being used
uninitialized in the attribute checking loop even though it's *clearly*
not the case.
Tools are getting less useful and more annoying DAY BY DAY.
This mirrors what's done already for implementation-specific vertex
formats, thus:
* Ability to construct the classes without tripping up when trying to
check for type size in various asserts
* Providing a zero-size type-erased access in indices() and
mutableIndices()
* Disallowing typed and convenience access
Also not something the classic GPU vertex pipeline can handle, but
useful for other scenarios. Subsequently a support for array indices
will be added, allowing to directly represent for example OBJ files,
where each attribute has its own index buffer.
This is not something the classic GPU vertex pipeline can handle
(except maybe Vulkan, which can handle zero strides for instanced
attributes?), but useful for other scenarios. This means existing code
needs to be aware of and handle the new corner case.
Those have 3 pointers at least, my limit for passing by value is trivial
copyability and two pointers. I hope that reflects the actual HW at
least vaguely, heh.
And add a comment explaining why we don't check the pointer for empty
meshes -- otherwise empty interleaved meshes would fail with stuff like
Trade::MeshData: attribute 0 [0xc:0xc] is not contained in passed
vertexData array [0x0:0x0]
which ... helps nobody.
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.
This code was apparently done before the batch casters were a thing. Now
it's no reason to do the same in two places, additionally in the future
the castInto() could get SIMD-optimized and this can benefit from that.
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.
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.
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š