With the upcoming string field support, field<UnsignedShort>() will be
allowed to peek into SceneFieldType::UnsignedShort, but also
SceneFieldType::StringOffset16 or
SceneFieldType::StringRangeNullTerminated16. Most types still have a 1:1
mapping, which is why this delegates to the existing
SceneFieldTypeFor<T> trait (which is also still needed to autodetect the
SceneFieldType in a SceneFieldData constructor), but certain type will
be able to provide a specialized handling.
These APIs are mostly just for debugging purposes, not widely used, so
it doesn't make sense to have them as constexpr in the header. (Plus the
returned void view is useless in a constexpr context anyway.)
This header size is getting out of hand, so every stripped bit counts.
Also now that they're no longer constexpr, I can go back to using
regular assertions. The reinterpret_cast<> wasn't needed either.
I'm not sure why this restriction was there as nothing was preventing
them from being used. The attribute is only accessible through the
typeless attribute(), which gives back
`Containers::StridedArrayView2D<const char>` with second dimension size
being set to the full stride. And there it doesn't matter if the format
is an array or not.
This will be useful for joint IDs and weights, for example doing crazy
things like packing the IDs into an array of 8 4-bit numbers, saving
half the memory compared to the smallest builtin representation using
UnsignedByte[8].
A lot of pain went into creating owned mesh data even though it was
completely unnecessary in retrospect. Originally I thought "let's not
use any advanced feature" but the verbosity is just not worth it.
In the recent-ish SceneData tests I went with non-owned data already,
and it was much simpler. It's a learning process even for using my own
APIs, huh.
Otherwise it's really, REALLY hard to discover which data are missing in
the output. Especially for files with 1700 meshes, 800 materials, 3600
textures and such.
Which is consistent with about everything else. No idea why I picked
such a strange API name.
Backwards compatibility aliases in place, as these are likely used by a
lot of code already. To ensure I didn't break anything, I'm updating all
code to use the new API in the next commit.
They were documented in the convenience accessor classes, but here it
makes sense too. The only attribute for which I'm hesitating to specify
a default is Phong shininess -- the value of 80 feels a bit too
arbitrary to be useful.
It's four pointers, twice as much as what would be acceptable. Not sure
why this happened, maybe because all those cases used an ArrayView
before and so I just changed the type without considering the difference
in its size?
Unfortunately this change also means a bump in the plugin interface
string, thus all scene converter plugins have to be updated as well.
Of course I used the wrong `CORRADE_FAIL_IF(false, ...)` in a few
places. Yet another confirmation it was too hard to use and a dedicated
macro is needed.
For cases where the whole MaterialAttributeData instance is needed and
calculating the right offset into the array returned by attributeData()
would be too error-prone.
Similar accessor is in MeshData already, so this achieves better feature
parity between the two.
With the following invocation
magnum-sceneconverter --info-importer -I GltfImporter \
-i customSceneFieldTypes/foo=Int
the newly-added option wasn't visible in the configuration printout
because the printer exited right once encountering the Doxygen
[configuration_] snippet marker in the file, and the option got added
after it. Now it's continuing after the marker and the newly-added
option is visible.
Lists features, aliases as well as documented contents of the whole
configuration file. Useful to not need to look up online docs when
working on the command line.
They're each a totally different beast and putting them into the same
test file doesn't really make sense:
- We want to link certain plugins statically on static builds to test
certain code paths in the implementation. However this is
counter-productive for the executable tests because there we are
checking for plugin presence from the test with the assumption that
the executable and the test have the exact same set of plugins
available (or linked statically).
- The executable tests are implemented on Unix only at the moment,
thus it's wasteful to try to build it on any other platforms. Having
it in a separate file makes it much easier to deal with.
Because storing arbitrary data as a string was not good:
- It *never* followed alignment requirements due to the last byte being
used for size. Instead the size is now stored before the data, and
thus the data is always on the 64 byte boundary.
- As it could contain arbitrary binary data, it could cause
magnum-sceneconverter --material-info to print garbage, corrupt the
terminal or, worst case, crash. Not good.
- It stored an implicit \0, which was unnecessary.
Vladimír Vondruš