So far it contains just the uniform definitions and utilities related
to line drawing, nothing else, but especially the line utilities were
needed to be able to build MeshTools tests on a GL-less build.
Originally (2012? 2013?) I expected that there would eventually be
OpenGL ES 4.0, thus it made sense to differentiate between ES2, ES3 and
something else ES yet unknown. But as ES4 was increasingly unlikely to
happen, the internal code treated MAGNUM_TARGET_GLES3 as a simple
inverse of MAGNUM_TARGET_GLES2, and only in a very few places,
only adding confusion.
Thus it's now deprecated and defined as a simple inverse of
MAGNUM_TARGET_GLES2 on MAGNUM_TARGET_GLES builds, and none of the
internal code uses it anymore.
The policy makes it work for all find_package(OpenGL) calls,
possibly even in subprojects, without having to copypaste the same
OpenGL_GL_PREFERENCE override code to each.
Went undiscovered until now, when a magnum-extras Android build enabled
Primitives but not MeshTools and then later failed as FindMagnum linked
optional Primitives to (required) MeshTools but those weren't found.
Same as in Corrade, they still default to static because that's the
least painful.
Plugins however still need to be forced to be built static on platforms
where the PluginManager doesn't have any support for dynamic plugins
implemented. The logic is now only simplified, to not have to change it
again when e.g. Android gets the needed bits implemented in
PluginManager.
Co-authored-by: Vladimír Vondruš <mosra@centrum.cz>
Same as the corresponding Corrade change. Should make
MAGNUM_BUILD_STATIC_UNIQUE_GLOBALS working also in cases where Magnum is
linked to just DLLs but not the main application executable. Such as
various plugins or native Python modules.
It isn't a nice UX to force users to hardcode a DLL name of their own
application when building a *dependency library*, but is a simple enough
middle ground between global symbol deduplication not working at all and
having to loop through all possible DLLs with EnumProcessModules() until
a symbol is found.
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.
I'll be happy once I can delete all this brittle backwards compatibility
post-release. The problem is as follows -- when running CMake without
any options on Android, iOS, Emscripten or UWP, such as
cmake .. \
-DCMAKE_TOOLCHAIN_FILE=path/to/toolchains/generic/Emscripten.cmake
It sees that no MAGNUM_-prefixed options were used, and thus assumes the
backwards compatibility for unprefixed WITH_, TARGET_ etc is still
desired, which is the right thing to do.
But then, there was a branch that enables TARGET_GLES *unconditionally*
on mobile platforms, if the backwards compatibility mode is enabled.
That alone would be harmless on its own, just causing garbage in the
CMake cache, unfortunately right after it sees that TARGET_GLES was set
and enables also TARGET_GLES2, because that's the default behavior. So
then, when one does
cmake . -DMAGNUM_TARGET_GLES2=ON
It'll ignore that option and instead yells at the users that TARGET_GLES
was set by them and it's deprecated, even though none of that was
actually intended:
CMake Deprecation Warning at CMakeLists.txt:501 (message):
Unprefixed options such as TARGET_GLES2 are deprecated, use
MAGNUM_TARGET_GLES2 instead. Delete the unprefixed variable from
CMake cache or set both to the same value to silence this warning.
The fix is that it's no longer setting TARGET_GLES implicitly on mobile
platforms, but instead considers the mobile platforms as well in
addition to checking if TARGET_GLES is set. Which means the backwards
compatibility variable dependencies only get set if there's at least one
of them coming from the user, never by default.
Currently contains just one very silly Phong->PBR conversion utility,
but eventually it'll provide tools for simplifying, merging and
deduplicating materials.
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.
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.
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.
Vladimír Vondruš