In particular:
- listing the *very important* stuff -- such as what macro to define to
make the library usable at all -- in the header
- mentioning what to do if cross-SO/DLL visibility is desired
The actual generated single-header file will be updated once I find more
time. Not now.
Marking it as having "some" caveats right now, will change it to none
once the remaining features like camera & light export are added and
once the mesh buffer views get more compact.
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.
Vladislav Oleshko