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.
Originally I thought this was caused by the changes that happened in the
previous commit, but apparently not, and it was due to an unrelated
system upgrade I did -- the 1.2.202 Arch package had libvulkan.so link
to libpthread.so, but the 1.2.203 build not (and I couldn't reproduce
when rebuilding the 1.2.203 package from scratch, so I guess there was
some weird hiccup on the machine that used to build the package?). And
to make things worse, this caused a problem only when passing
`--magnum-device cpu` to select SwiftShader, which (unlike other
drivers, apparently) relies on pthread being linked in.
Nevertheless, Magnum should be immune against such issues same as it's
trying to be immune against Assimp regressions, so let's just link to
pthread always in the Find module, and do it via -pthread instead of
-lpthread so the same issue with the reference DCEd doesn't happen to
us.
Like, I can't even, why does it warn for function *definitions* for a
deprecated class which don't even use the deprecated class name anywhere
except the fully qualified name? Why does it warn here but not for, say,
ObjectData2D?
Warning that a *deprecated class* copy/move constructor/assignment is
deprecated is useless. Good thing the newer versions fixed that,
nevertheless it's still beyond annoying to see in the CI output.
Hah this took a while, as there was no texture scaffolding in place at
all. Thus all this had to be added and tested for the first time:
* 2D textures
* 2D texture arrays
* Texture transformation uniforms
* Texture transformation UBOs
* Instanced texture offset
This also means that MeshVisualizer can be used to visualize arbitrary
(single-channel) integer textures now, not just render meshes with
object ID textures. Yay for feature parity!
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.
Vladimír Vondruš