Long ago, during one of the few initial MeshData iterations. there was
no VertexFormat, but rather Trade::MeshAttributeType. I managed to get
rid of it mostly, except this place.
Originally I wanted to show how to convert a JPEG to an EXR directly,
however after trying and miserably failing to implement that inside
OpenExrImageConverter I realized the plugin is definitely not the place
where to perform such conversion. So this will have to wait until
there's some proper API in TextureTools or somewhere.
In case of --layers and --levels this only works if the input images
have a single level, otherwise --level has to be set. The internal
implementation would be too complex otherwise. As a consequence,
combining a set of 2D mipmapped images into a 3D mipmapped image means
one first has to combine particular 2D image levels to 3D levels and
then combine all 3D levels to a 3D mipmapped image, it can't be done in
a single step and it also can't be done by first combining levels and
then layers.
Because a MeshView might not be the best thing to have when you are
submitting a batch of thousand draws. It takes a strided array views to
allow for more flexibility, but can also detect if the input is already
contiguous and use it as-is.
UNFORTUNATELY the GL 1.0 legacy still continues to stink and so there
has to be a 64-bit-specific overload which is the *actual* variant that
doesn't allocate because glMultiDrawElements takes a `void**` for INDEX
OFFSETS and it's IN BYTES! Which foolish soul designed such a thing back
in the 1860s, I wonder. There's no reason to not have an index offset
in elements because all indices have to have the same type ANYWAY. And
yes, I wasted about three hours debugging driver crashes because I
THOUGHT this parameter takes offset in elements, not bytes.
Also note: on 32-bit platforms this depends on latest Corrade with the
CORRADE_TARGET_32BIT definition. Spent an embarrassing amount of time
wondering why all local builds but Emscripten work.
Or, the horror when I comment-out half of it and it still kinda passes.
The new code tests it more thoroughly, with actually checking that
different draw produce different results instead of one draw overwriting
the other.
Plus also verifying interaction with gl_VertexID and gl_DrawID to ensure
it really behaves correctly:
- gl_VertexID should get the same value regardless of whether we
perform a multi-draw or a one-by-one fallback, so this catches issues
where the mesh would get reconfigured in some nasty way, losing this
information
- gl_DrawID should get properly populated if and only if we use the
multi-draw code path, so this catches issues where the fallback would
get used instead of the actual multi-draw code path
The multi-level APIs still don't check anything regarding level sizes
and order since for example *.ico has no restrictions at all. But the
rest (like non-zero size) is a restriction for all file formats I'm
aware of.
TgaImageConverter test had to be adapted, I expect a lot of breakages in
plugins tests as well. But user code should be fine I think. Also
reduced the rather excessive dimensions in AbstractImageConverterTest,
since the allocation requirement now made the default Emscripten heap
OOM.
Preparing for the soon-to-be-merged KTX files. Not hooking up 1D/3D and
the compressed APIs yet, doing that only when the plugins get merged so
I have a way to test.
To avoid combinatorial explosion of functions that have to be
implemented on the plugin side, the single-image variants proxy to the
multi-level variants, if available.
THe plugin interface string had to be bumped because otherwise there was
a *really nasty* silent ABI break where instead of doSetFlags() it was
suddenly calling doConvert().
The "funniest" of all is that those get printed in a totally random
fashion. Some in Debug, some in Release, some not at all (like, half of
the MaterialDataTest doesn'ŧ initialize `state` and yet it doesn't
complain). Fuck these half-assed features that achieve nothing except
bullying people WHO KNOW WHAT THEY ARE DOING FFS.
Because::This::Is::Colon::Cancer. Also rename Cube to CubeMap and get
rid of the comment that said cube map images are six consecutive 2D
images. Now it's one 3D image instead because that makes more sense, in
the very rare case we'd need to have six different images again we could
probably add a CubeFace value or some such.
Vladimír Vondruš