Similar to the change done in Corrade, see the commit for details:
878624ac36
Wow, this is probably the most backwards-compatibility code I've ever
written. Can't wait until I can drop all that.
The boring dry usage info grew significantly, and listing it as the
first thing on the page would scare people off. Put the examples first
instead, and for the imageconverter and sceneconverter add --info
listing examples, as that's what is eye-catchy.
Counterpart to d07b6a2bb4, which did this
for sceneconverter (I should really do changes in both at the same
time). Additionally, it's not saying "uncompressed" for images anymore,
since it's more confusing than just saying nothing, especially when
block-compressed formats are involved.
For animations, scenes, meshes and images, where the memory impact is
measurable. For others such as materials or cameras the memory impact is
either unclear (depending on the final representation) or so small it's
not important.
I realized those are too annoying when writing a glTF exporter which
contains a lot of switches over enums. And as further shown by the diff,
those were only inflicting additional pain in *all* switch statements,
nothing else, no other added value. And everywhere else the helpers are
the designated way to deal with those, so there's no point in having an
explicit enum value denoting start of a "custom range".
It wasn't even any convenient to have it in the enum, as the extra
effort needed for casting actually made it *exactly* the same length as
if I'd just use a separately-defined constant.
As it's expected that there's a lot of objects, this prints just a
compact two-line info for each -- reference count, name and a list of
fields, with [n] in case a field is repeated. The field types are listed
in SceneData.
Field contents don't seem to be that important in this case (compared to
knowing which meshes/.. are referenced and how much, which is quite
essential) and would bloat the output a lot. I might add this as some
verbose option eventually, if needed, but I don't think it will be.
Because the uncolored overly verbose output was ridicilously ugly and
hard to navigate for larger scenes. Like with TestSuite executables,
there's a --color option that defaults to automatic coloring based on
whether printing to a TTY and can be both explicitly enabled and
disabled.
It limits the support for CMake 3.12+, but it's much less verbose and I
don't expect people to use ancient CMake versions with IDEs like Xcode
or VS anyway, so this should be fine.
We don't have a string-to-int API that can take non-null-terminated
string views yet, but we have this. And that's a much better fit in this
case.
This stripped further 4 kB off the release binary size (178 kB before,
158 after). Fully inlined STL containers and algorithms are a very good
idea, yes.
What a stupid idea, cuz now it's impossible to know which attribute has
which ID, so using --only-attributes is just a total guesswork,
resulting in meshes that have no positions or other nightmare scenarios.
NOT a good idea, past mosra.
By the way, removing the std::sort() stripped 16 kB off the release
binary size (178 kB before, 162 after). Fancy, C++, very fancy.
This is not something the classic GPU vertex pipeline can handle
(except maybe Vulkan, which can handle zero strides for instanced
attributes?), but useful for other scenarios. This means existing code
needs to be aware of and handle the new corner case.
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).
Vladimír Vondruš