Forgot that gl_VertexID includes the base offset in the multidraw
scenarios, so we need to take all vertices into account, not just the
largest view. The wraparound would cause nasty output differences among
drivers.
Mainly to have feature parity with Flat and Phong -- otherwise switching
to draw a wireframe on an instanced mesh would be too annoying. Also, if
we have multidraw there already, why not instancing as well.
Originally the uniform wasn't present with the assumption that users
could easily adjust color map offset to achieve the same effect. That
was however unnecessarily annoying and error-prone in cases where it's
essential to have the same object IDs from multiple draws have a
matching color, and it was complicating multidraw workflows as the color
map offset was not a part of per-draw data, but rather material data.
Do it always when Flag::TextureArrays is set, not inside handling of
some particular texture. Because that way it won't work when other
textures are added/tested.
Before the object ID was enabled and tested always, which may lead to
some error being undetectable. Plus this makes the test more flexible
for further additions.
The proper practice is to have GLES and WebGL requiurements separated,
as the two editions diverge more and more and treating one as a subset
of another no longer works.
This ended up being far more complicated than anticipated -- the utils
now make use of filterExceptAttributes() in order to properly preserve
the index type when passing a MeshData through. Before an
implementation-specific index type was lost in the process due to
passing just the view to MeshIndexData constructor and not also the
type, and because keeping the metadata is a bit involved process, this
had to wait until there's an alternative to reference() that allows me
to drop all attribute information. And that's what
filterExceptAttributes() does.
Then, interleave() implicitly doesn't preserve strided index buffers
because GPUs don't like them, and since implementation-specific index
types always result in strided index buffers, this was then immediately
dying inside interleave() as it's not possible to tightly-pack an index
buffer of an unknown type. Thus, the function now has to expose
InterleaveFlags and propagate them to interleave() in order to allow the
user to preserve the index buffer without repacking it.
Apmong other things where it's useful for end users as a more convenient
alternative to recreating the MeshData by hand, I need to use this
inside the transform() utilities to preserve all index buffer properties
without copypasting nasty code everywhere.
As implementation-specific index types cause the index buffer to be
strided. which is not allowed by default, these work only if
InterleaveFlag::PreserveStridedIndices is set. Originally I thought
about straight-out disallowing implementation-specific types here,
unfortunately that broke some valid use cases so I backtracked on that
decision.
In the future I might change the default to preserve
implementation-specific indices with sane strides (i.e., positive powers
of 2), but that will only be done once similar treatment is finished for
attributes (currently zero and negative strides are just disallowed
completely).
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
The type is now extended to 32 bits. In the GL and Vk libraries it means
one can now do things like
MeshIndexType type = meshIndexTypeWrap(GL_UNSIGNED_BYTE);
and passing that to GL::Mesh or Vk::Mesh will cause it to use the value
directly, instead of doing a mapping from a generic type. The *real* use
case for this is however to allow custom index buffer representations in
Trade::MeshData. Support for that will be hooked up in the following
commit.
Otherwise it makes a tightly-packed copy. This also means that arbitrary
padding before/after the index buffer is preserved only in case it would
mean the data can be transferred without a copy -- otherwise it's faster
to just drop the padding and copy only the used part.
Vladimír Vondruš