The main use case is being able to specify what concrete plugin gets
used for a particular alias, e.g. to be able to use SpngImporter instead
of PngImporter for faster PNG image loading.
So far the option is implemented only here, as the imageconverter,
shaderconverter and other tools don't really deal with plugins
that delegate to other plugins. Yet.
When using the -P or -M options on a large scene, it can happen that
the conversion would fail for a small number of outliers. For example
there can be some line meshes which aren't supported by MeshOptimizer,
or there are 16-bit images not supported by a certain image conversion
plugin.
Failing the whole operation in that case may be too radical, especially
if the only alternative would be to write a Python script that deals
with the outliers in a custom way. The option simply makes the
processing step pass through the original data unchanged, which may be a
simple and good-enough solution in many of those cases.
Originally I thought I'd save plugins some time if I just give them the
custom indices directly, without being wrapped in a SceneField /
MeshAttribute enum. But in practice that didn't really save anything,
made the interfaces more error-prone due to there being no concrete type
anymore, and all code that delegates to nested importers or converters
had to re-wrap the IDs again, which is *again* error-prone.
Bumping the interface strings because this is a breaking change for the
implementations. Not for users tho, there nothing changes.
If it crashes or does some other shit, it'll cause the tool to not work
at all. If it fails to load due to whatever other issue, it'll spam the
output for no reason.
Exposes MaterialTools::phongToPbrMetallicRoughness() that got added some
time ago. Most of the code and tests is scaffolding needed for direct
material import and processing outside of the addImporterContents()
automagic, similar to what was already done for meshes and images.
In particular, adding more material conversion options such as
canonicalization or deduplication will be significantly easier now that
the basics are done and tested.
The number of items is known beforehand, so avoid unnecessary
reallocations. When mesh LODs are supported this won't be that clear
anymore, nevertheless it's never bad to pre-reserve.
Lists features, aliases as well as documented contents of the whole
configuration file. Useful to not need to look up online docs when
working on the command line.
Just a minimal support to get single-mesh conversion working with
GltfSceneConverter. The whole thing has to be subsequently reworked to
not be oriented around meshes, but this is the first step.
I'm going to add quite a few features to this one, and doing that
without any regression tests whatsoever would be a misery. Same needs to
eventually be done for the imageconverter and other utils. No bugs found
here, fortunately, except for one message update -- otherwise the
verbose output would contain (1/2) but never (2/2) which may be
confusing.
At the moment the testing is done only on Unix -- originally I wanted to
postpone this until something like Utility::System::execute() is
implemented, with proper argument escaping and output redirection, but I
simply DO NOT HAVE TIME to do that properly now. So instead it's calling
into std::system(), assumes there is no whitespace in the arguments, and
assumes a Unix shell with stdout/stderr redirection to a file. Ugly and
probably way slower than necessary, but works.
For some reason, it was adding also the magnum / magnum-d directory,
which isn't really useful, especially in cases where the directory is
not at all or it's desired to pick a debug plugin from a release
executable and vice versa.
Also the distancefieldconverter was still attempting to join with an
absolute path -- somehow 7fb63a9434 missed
this one.
I really need to write regression tests for all this, sigh.
It was quite a pile, and all of it was written just once, relying only
on hopefully-available model files that would hopefully touch most code
paths. Which means, extremely annoying to make changes in.
I extracted the code to a header that can be tested with a mocked-up
importer and without having to execute the utility itself, deduplicated
the image info printing code, fixed various inconsistencies (such as
data/field flags sometimes denoted with superfluous "flags:" and
sometimes not) and TODOs (such as 2D/3D skins, where there was no format
whatsoever that would have 2D skin support, so the code couldn't get
written).
Now it's finally possible to easily add the remaining missing features,
such as printing camera info.
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.
Vladimír Vondruš