INSTEAD IT JUST TAKES THE NEXT ARGUMENT (WHICH IS -R IN THIS CASE) AS
THE PARALLELISM VALUE, WITHOUT FAILING, AND THEN IGNORES THE FOLLOWING
VALUE (WHICH IS THE ARGUMENT TO -R), HOT FUCKING DAMN HOW DARE YOU
WRITE SUCH BROKEN COMMAND LINE PARSING FOR SUCH AN ESSENTIAL
APPLICATION!!!
Of course I discovered it only now that I *finally* managed to work
around all test failures on my new machine. FFS.
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.
They're each a totally different beast and putting them into the same
test file doesn't really make sense:
- We want to link certain plugins statically on static builds to test
certain code paths in the implementation. However this is
counter-productive for the executable tests because there we are
checking for plugin presence from the test with the assumption that
the executable and the test have the exact same set of plugins
available (or linked statically).
- The executable tests are implemented on Unix only at the moment,
thus it's wasteful to try to build it on any other platforms. Having
it in a separate file makes it much easier to deal with.
Because storing arbitrary data as a string was not good:
- It *never* followed alignment requirements due to the last byte being
used for size. Instead the size is now stored before the data, and
thus the data is always on the 64 byte boundary.
- As it could contain arbitrary binary data, it could cause
magnum-sceneconverter --material-info to print garbage, corrupt the
terminal or, worst case, crash. Not good.
- It stored an implicit \0, which was unnecessary.
The line segment direction length is crucial for knowing where the
intersection happens so normalizing it beforehand will have unintended
consequences. OTOH, in case of the second (non-segment) variant, the
second parameter can but doesn't have to be normalized.
It was implemented only for the Half type and not the others, and I just
felt like using it on a vector now, 12 years after the Vector class got
first added.
What was there didn't really check that the output of one converter was
used as input for the next one. Especially with the upcoming rework for
full scene conversion that could lead to dangerous regressions.
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.