This happened because I made an early implementation of the batch
AbstractSceneConverter APIs, stashed it away, then implemented image
flags and then continued working on the stash, unaware that it's
outdated.
It makes no difference in this case, the State struct is not exported
even without the attribute. OTOH, it would need to have an EXPORT
attribute if it was desired to be exported, for example like done with
nested classes in GL::Framebuffer.
The enum-to-string conversion was just a private API and we need to use
it in various material filtering code. It was also a private class member
for some reason, even though it has no relation to / dependency on the
MaterialData class. So it's made a free function instead.
The MeshData and SceneData find APIs had the complexity documented, do
the same for MaterialData too. Plus cross-link this API from
hasAttribute() / hasField() so it's easier to find.
Unlike most other options, where a plugin can support 3D but not 2D or
compressed but not uncompressed data, the "levels" option is orthogonal
to the rest -- if a format supports multi-level data, it obviously also
supports a case where there is just a single level, and if it supports
multi-level images, then it likely supports them for 1D, 2D and 3D, not
just some.
I used the same reasoning for the new SceneConverterFeatures interfaces
already, just "backporting" it here as well.
The bit pattern actually followed this already, but for some reason I
still went ahead and stamped out all possible combinations. Because
of that, nothing really changes on the ABI side either and the
deprecated aliases are now exactly as they were before, so no need to
bump the plugin interface version.
And properly test the behavior as well. While it's rare that a batch
and immediate conversions would be mixed on a single converter instance,
if it happens by accident it should not lead to unexpected internal
state.
Initially I thought there was no reason for this to fail, but then
realized AnySceneConverter would need it. And also any other plugin
relying on something external that might fail during initialization --
there's no other moment after plugin instantiation where it could
signalize a failure, and deferring that to the first add() call,
whichever would it be, is really not a sane idea.
Wasn't really possible to split this into multiple commits, so here's
the whole thing including delegation from and to the single-mesh APIs.
What's not done here and postponed for later is:
- an ability to feed the whole importer to it, filtering away data that
aren't supported by the converter
- corresponding changes in AbstractImageConverter, where it would now
primarily accept ImageData to future-proof for arbitrary extra
key/value data
These headers are included quite often and because
<Corrade/Utility/StlForwardString.h> expands to the whole <string>, it
has quite a significant impact.
Other cases like Math/ConfigurationValue.h are not changed at the
moment, as that header is only included together with Utility::Arguments
or Utility::Configuration -- and these classes are still STL-heavy, so
avoiding std::string usage in just the ConfigurationValue
specializations doesn't help anything at the moment.
Same as the previous commit in MeshTools -- allows to pass a
Containers::Array<DescriptorSetLayoutBinding> to it without having to
form a list of references first.
This allows people to directly pass Containers::Array<Trade::MeshData>
there, without having to put them to an annoying temporary
Containers::Array<Containers::Reference<const Trade::MeshData>.
The Iterable header is included for backwards compatibility, apart from
that there should be no breaking change.
Apart from returning const T instead of T it kinda worked, but in case
of floating-point vectors it tried to operate with
`std::pair<std::size_t, const T>` internally and failed miserably.
I wondered if I should put them into the GL/VK startup log, but
while definitely useful, they don't really have any relation to GPU
drivers. So it's just here for now.
Funnily enough, this broke building of anything depending on the Audio
library with OpenAL Soft 1.22.2.
It now sets the OPENAL_INCLUDE_DIR variable for backwards compatibility
purposes, but in 1.21.1 and before such variable was not set in
OpenALConfig.cmake at all, thus this expression did nothing. But now
using this variable by accident led to
CMake Error at src/MagnumPlugins/AnyAudioImporter/CMakeLists.txt:46 (target_link_libraries):
Error evaluating generator expression:
$<TARGET_PROPERTY:OpenAL::OpenAL,INTERFACE_INCLUDE_DIRECTORIES>
Target "OpenAL::OpenAL" not found.
which is rather strange -- the OpenAL::OpenAL target (which is a local
alias scoped only to the Magnum/Audio directory from where
find_package(OpenAL) was called) *is* propagated correctly from the
target_link_libraries() call, but at the same time it's not propagated
if it's passed via target_include_directories(). I don't know why (and
probably don't want to know), in any case the expression is not needed
and removing it altogether fixes everything.
Vladimír Vondruš