So it has 32k values for custom targets, instead of just 127. This
makes it consistent with MeshAttribute, which also provides 32k values,
while SceneField has a whole 31-bit range to make it possible to store
arbitrary ECS identifiers as well.
Since this is an ABI break, I'm also shifting the values by 1 to have
zero used for an invalid value, consistently with SceneField,
MeshAttribute etc.
If it crashes or does some other shit, it'll cause the tool to not work
at all. If it fails to load due to whatever other issue, it'll spam the
output for no reason.
The code right below is querying the `log` option, which wasn't added.
Becomes a problem when Magnum is compiled w/o GL support, e.g. for a
custom WebGPU renderer.
Passes for SceneData but fails for MeshData due to 32-bit types used by
accident. The two also have a vastly different calculations in the range
checks, should unify that first.
Done this way only in the Phong shader, everywhere else it's just the
MAGNUM_ASSERT_GL_EXTENSION_SUPPORTED() macro. Some WIP code that I
forgot to clean up?
So it's possible to have light culling enabled on, say, 64 lights, but
with only at most 3 applied each draw, allowing the shader compiler to
unroll the loop if it makes sense. This also better prepares for SSBO
support where the total light count would be unbounded and thus the
value ignored, and thus the value can be 0.
This prepares for SSBO support where the total count is unbounded (and
thus the value is ignored, thus it can be 0).
Also regroup the doc paragraphs so it's clear what's related to UBO
usage and what applies to classic uniforms as well.
I still expect the API to change slightly to accomodate for line
stipple or textured lines (such as possibly having different smoothness
alongside and across the segment), plus there are some TODOs that might
change how it behaves in certain corner cases.
Currently just the bare minimum, more features such as handling
multiple contiguous strips and loops inside a single mesh or an
overlapping layout will come later.
For generic code, which would otherwise have to invent some SFINAE
"use castInto() if the types are different and Utility::copy()
otherwise" nastiness in every such case, and that's just annoying.
The shader requires the input data to be laid out in a rather specific
way, and there will be a dedicated MeshTools utility for it in the
following commits. For independence though, the shader tests use a
custom helper.
The initial implementation has certain corner cases which will be
eventually resolved. For now they are pinned down with repro cases in
the test. But apart from that, it's pretty much usable in practice.
Remaining join styles (round and miter-clip) as well as stipple support
will eventually follow as well.
Otherwise it may be hard to guess which of them is failing. *Ideally*
the assert would also contain the stride vs type size, maybe I do
that next time I spend that much time investigating why it asserts.