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.
Makes a lot of use cases significantly simpler -- apart from the trivial
"convert an OBJ to a glTF" scenario, many processing steps are about
passing most data through but only doing a pass on meshes, or images, or
materials. And this simplifies that use case quite a lot.
This is only "driver" code, with no new interfaces for the plugins. For
them it still looks like all data, their names and related metadata were
added one by one.
Also, a suprisingly large amount of code for this feature.
This was done correctly in the Find module, but here somehow not -- if
MAGNUM_TARGET_EGL is enabled, then [Windowless]GlxApplication and
GlxContext were linking to MagnumSomeContext_LIBRARY, which is EGL. Whic
is wrong. Those should always link to GLX, if it exists, and nothing if
there's just the old libGL.
I.e., if the build is static including plugins and the corresponding
application is actually enabled. The options will work even if not
(because it's easier that way), they will just not appear in the CMake
option list.
Funny/sad that this possibility took me so long to realize. Until now it
was "you can have command-line utilities or static plugins but never
both", and only with CMake 3.13+ it was possible to link static plugins
to these executables from outside. Now it's a builtin and supported
option.
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.
A large portion of the needed changes was in the previous commit
already, this does just the remaining part, in particular ensuring EGL
is linked and SDL is told to use EGL as well -- GLFW was told so in the
previous cleanup commit already.
These two options were mutually exclusive, and both were doing the same
thing -- switching to EGL on desktop GL, or switching away from EGL on
GLES. That made all logic vastly more complicated than it should be, and
unfortunately it took me half a decade to realize that. The new logic is
significantly simpler everywhere.
As usual, the old options are still recognized by CMake on a deprecated
build (with a warning), and are still exposed both as CMake variables
and a preprocessor define. But the logic for them was quite complicated,
so I don't guarantee all cases are covered.
I also tried to clean up the dependent CMake options to allow building
GLX and WGL apps on GLES independently of whether EGL is used, but it's
quite a mess due to the limitations of CMake < 3.22. Build directories
that have the options switched randomly over a long time might start
misbehaving, but the initial build should work well.
The whole class was a bad idea, why create something that's 99% similar
to another application and has just one platform-specific workaround? Of
course it resulted in this code being completely untested and not even
built anywhere, because it served a tiny insignificant use case.
To avoid losing all the code, I did my best in attempting to merge this
into the WindowlessEglApplication. But since, again, EGL isn't
really used on any Windows platform, I can't even say it builds
properly. Maybe not even the original code built.
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.
Vladimír Vondruš