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.
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.
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.
To become the central piece of an upcoming SceneTools library, now I
need it just to implement duplication of objects that have more than one
mesh/light/camera/... assignment.
Same as with MeshData2D/3D, the original ObjectData API and plugin
interfaces are preserved to keep existing code as well as existing
importer implementations working. As Magnum's own importers will get
updated to the new SceneData workflow, a backward compatibility layer
provided that translates it to the subset that the legacy ObjectData
understands.
With this commit, both existing plugin code can build (and test against)
the new workflow, and any ports to the new workflow can test against the
legacy interfaces. Except that for now the compatibility layer doesn't
deal with objects that have more than one mesh or for example a light
and a camera attached, this will be done in a separate step.
This is a bit huge because of all the new overloads that take a
MaterialLayer instead of a string, but all that is just boring
boilerplate. Additionally this:
* exposes glTF clear coat parameters (which, interestingly enough,
reuse existing attributes and don't introduce any new)
* provides a convenience wrapper in PbrClearCoatMaterialData
* and a convenience base for material layer wrappers that redirect
all APIs with implicit layer argument to desired layer instead of the
base material
Well, "basic". Practically mirrors glTF PBR materials:
- builtin metallic/roughness
- the KHR_materials_pbrSpecularGlossiness extension
- extra normal/occlusion/emission maps
- exposes the implicit metallic/roughness and specular/glossiness
packing, but also allows separate maps with arbitrary packings as
well as two-channel normal maps (instead of three-channel)
- provides convenience checks for the most common packing schemes
including MSFT_packing_normalRoughnessMetallic and the three variants
of MSFT_packing_occlusionRoughnessMetallic
- teaches PhongMaterialData to recognize packed specular/glossiness
maps as well
Next up is exposing at least one layer extension, and then I'm done
here.
AbstractMaterialData is now just a typedef to MaterialData, with all
existing public APIs moved to (and marked as deprecated, if they don't
make sense anymore). The new class doesn't have a virtual destructor as
that's not the desired use anymore -- and AbstractImporter::material()
APIs will be returning an Optional instead of a Pointer, which means any
potential subclasses will be sliced away.
PhongMaterialData is reimplemented using the new key/value store,
with no own members anymore -- thus having the same size as
MaterialData, and safe to be casted from it to access the helper APIs.
So it can make use of all the APIs in here. Having the utility part of
Trade would make the cyclic dependency a bit weird. Not adding MeshTools
as a dependency just yet, will do that once it's actually needed.
With API analogous to the (relatively) new AnimationData -- with one
buffer containing all index data and one buffer containing all vertex
data, both meant to be uploaded as-is to the GPU.
This will eventually replace MeshData2D and MeshData3D, backwards
compatibility and wiring up to other APIs will be done in follow-up
commits.
This makes it possible to:
- finally use Magnum as a CMake subproject on Windows and have your
executables not fail to run with a "DLL missing" error (and the
setting is put to cache so superprojects just implicitly make use of
that)
- run tests on Windows without having to install first
- use dynamic plugins from a CMake subproject on any platform without
having to install first or load them by filename --- and the plugin
directory is now easily discovered as relative to
libraryLocation() of the library implementing given plugin interface
Doesn't make any backwards-incompatible change -- plugins can still
export the transformation as matrix and users can still access the
combined one even if separate transformations are used. Yay!
With the previous commits the original tests passed (which is
desired), but these were using deprecated functionality and not
covering the new stuff. These tests are not using the deprecated
functionality, which means I don't need to build them as part of
the GL library anymore.
The GL::BufferImage test is still using the deprecated
functionality though, in order to check I didn't break anything
by accident.
Vladimír Vondruš