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.
Using the InPlaceInit constructor instead of an unnecessarily verbose
array<T>({...}) helper, indenting the command-line arguments so they're
easier to distinguish from the rest.
The main property of this feature is that it prints the bounds *in a
canonical type*, not of the actual type that's used. Yet however that
wasn't ever tested. Now it is, and it's also testing behavior for custom
attributes, which don't get their bounds printed (because the canonical
type isn't known for those).
Sometimes it's a vital piece of information, e.g. the file having no
default might lead to it being not displayed correctly as some end-user
application might think it has no scene.
Otherwise it's really, REALLY hard to discover which data are missing in
the output. Especially for files with 1700 meshes, 800 materials, 3600
textures and such.
It doesn't discard meshes that are not a part of the hierarchy, but that
was the plan in the beginning. However, over the time I realized that a
better property for it is that the output is guaranteed to be in the
same order and size as the mesh field in the scene. Because that's what
I relied on in every use case, and every time I had to dig that property
out of the sources because it was deliberately not documented *because*
it was meant to change.
No longer. The compatibility with the mesh field ordering is now
documented, the behavior regarding loose objects also, and if there's
ever a need to discard everything that's not in the reachable hierarchy,
it'll probably get its own API. Because it's useful for general
asset cleanup and other use cases, not just meshes.
I'm still keeping the experimental tag here though, tp be sure.
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.
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.
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.
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.
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.
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.
Vladimír Vondruš