And also add a compiledPerVertexJointCount() helper which returns the
amount of components used in the primary and secondary joint IDs /
weights slots.
Co-authored-by: Squareys <squareys@googlemail.com>
Which is currently the case for any two attributes of the same name
(such as two texture coordinate sets), or bitangents and object ID used
together.
Plus extending the check for matrix attributes (such as instanced
transformation conflicting with secondary joint IDs and weights).
None of these attributes are builtin though, so the check can't be
verified at the moment.
And also documenting the behavior, for some reason the comment was
apparently not updated since the MeshData2D/MeshData3D days!
High-level docs with examples will be written once there's corresponding
support in MeshTools::compile() *and* in importer plugins, as skinned
meshes are usually brought in from files, never set up directly.
Co-authored-by: Squareys <squareys@googlemail.com>
With skinning the TransformationUniform*D structure will be reused for
two different UBOs and referencing it without the corresponding
bind*Buffer() API would be confusing. So just do that for all.
* No need to repeat the type for all variables, unnecessary redundancy.
* Reducing the amount of redundant local variables and if they stay
making their definitions more localized to where they get used.
* All uniform setters used the "initial value is" phrase instead of
"default is", this one didn't.
To make room for two more 16-bit skinning-related values in the
PhongDrawUniform -- joint offset for multidraw and per-instance joint
count for instancing.
Originally I made those full 32 bits because I wanted to provide an
option to have a 64-bit light mask there instead of an offset + count.
But the mask is not really driver-friendly as going over the bits and
skipping zeros was behaving like if each pixel was affected by 64 lights
-- an absolute perf nightmare. I might reconsider this again later, but
for now that doesn't seem to make sense, and I need to put the
skinning-related info somewhere without inflating the per-draw uniform
by another 16-byte vector.
The main property of this feature is that it prints the bounds *in a
canonical type*, not of the actual type that's used. Yet however that
wasn't ever tested. Now it is, and it's also testing behavior for custom
attributes, which don't get their bounds printed (because the canonical
type isn't known for those).
To be clear -- it would work even without, as it'd fall back to
calculating the range of the weights attribute and choosing an epsilon
based on that, but now it takes a shortcut as Weights are known to be in
a [0, 1] range.
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>
Note that the order is *reversed* compared to the originally reserved
attribute IDs. This is because the "joint <id> has <weight>" order
feels more natural and consistent than "<weight> is assigned to joint
<id>".
Co-authored-by: Vladimír Vondruš <mosra@centrum.cz>
Finally got an idea how to provide various options store these
efficiently, so it's implemented now. Five different storage variants
times four different type sizes.
With the upcoming string field support, field<UnsignedShort>() will be
allowed to peek into SceneFieldType::UnsignedShort, but also
SceneFieldType::StringOffset16 or
SceneFieldType::StringRangeNullTerminated16. Most types still have a 1:1
mapping, which is why this delegates to the existing
SceneFieldTypeFor<T> trait (which is also still needed to autodetect the
SceneFieldType in a SceneFieldData constructor), but certain type will
be able to provide a specialized handling.
These APIs are mostly just for debugging purposes, not widely used, so
it doesn't make sense to have them as constexpr in the header. (Plus the
returned void view is useless in a constexpr context anyway.)
This header size is getting out of hand, so every stripped bit counts.
Also now that they're no longer constexpr, I can go back to using
regular assertions. The reinterpret_cast<> wasn't needed either.
Those were originally named set*Buffer(), but in the process of
finishing up ef9da0ec96 got changed to
bind*Buffer() to avoid a false impression that the buffer stays bound to
the shader instance forever (which it doesn't, same as with textures).
However the documentation didn't get updated, apparently.
Vladimír Vondruš