It may soon start happening that those will have an
implementation-specific value that is neither a GL or a Vulkan
identifier, so people should not just pass them around without checking.
It was already done in removeDuplicatesFuzzy(), so just make it
consistent with the rest (shorter message, listing also the offending
attribute index).
Haha, I even had a TODO here. An exception in this case is when the mesh
is already interleaved -- then the layout is kept intact and thus it's
not needed to know what vertex format sizes to repack.
Was browsing the extension registry looking for something else and found
this instead. It used to be ES catching up with desktop, now it's the
other way around.
I kinda get the point, to avoid rogue third parties tainting my
ŕepositories with nasty backdoors, yes, but unless *everything* on the
way to the server including DNS queries is encrypted, then it's still
just a half of the solution and any silly corporate firewall can still
prevent me from cloning stuff from github dot com.
Highly experimental and very assert-y, as it doesn't handle mesh
primitive / attribute type incompatibility or conversion of
loops/strips/fans to indexed meshes yet.
Should have been done in f10d74041b
already, but somehow I failed to test for this case -- if there are no
scenes (materials/textures), it doesn't make sense to print reference
count for cameras/meshes/lights (textures/images).
And doing all the automagic of unpacking packed types, converting
positions *and* normals/tangents/bitangents, and also an overload for
transforming texture coordinates.
Such a simple thing and yet so complex and nasty to test.
No functional change, just splitting them to two separate headers and
two separate tests. These will eventually become public SceneTools
APIs... once I figure out better naming.
Probably a leftover from when these dependencies were handled in a
much shittier way? For as long as I remember, enabling WITH_GL_INFO
always enabled WITH_GL and WITH_WINDOWLESSWHATEVERAPPLICATION
implicitly.