Because, when it fails, it'd attempt to print them as strings,
inevitably leading to a crash or garbage in the terminal. Moreover, with
the upcoming fix that makes StringView *actually* convertible from an
ArrayView, it would become ambiguous.
Triggers the new OOB assertion in ArrayView element access APIs.
"Technically" this was okay, since converting a BufferMemoryBarrier to
VkBufferMemoryBarrier is just `return this;` (and a cast), which if
`this == nullptr` returns `nullptr`. But practically this probably
triggered all sorts of UB. Haha.
Stone age APIs used here again, I can't fathom how I could live without
member slicing for so long. This also fixes an OOB access which trips up
the new ArrayView assertions -- accessing element 0 in the constructor
isn't a good thing to do if there's no data at all.
This still contained the original message which didn't say the index.
Times changed significantly since then, and the printed index really
proved to be useful.
Also fixing a OOB assertion in the test triggered by the new ArrayView
element access assertions -- the graceful assertion returns the first
element, so we have to have at least one there to return.
The memory wasn't accessed in that case so everything is fine, but this
started tripping up the new assertions in ArrayView element access.
Fixed by moving (and thus duplicating) the access to where it is
actually needed.
Also removed the outdated comment -- there's no _currentData anymore
anywhere, not sure what was that meant to be.
It's not a GL error, and allows the application to compile just a single
shader for all skinned meshes, not one for each skeleton size. Together
with the dynamic per-vertex joint count this means the app only needs a
single shader for all skinned meshes, which is nice.
Those were temporarily added until Trade::AbstractImporter is ported
away from std::string, and that's done for quite some time already, so
these are no longer needed.
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>
Kleis Auke Wolthuizen