The glTF importer plugin contains functionality that's present only in
deprecated builds (backwards compatibility for skinning mesh
attributes), which isn't causing any API signature difference but rather
a difference in behavior. So expand the docs to say it's not limited to
just APIs but features in general.
Somehow I forgot to cross-reference the SceneFieldData constructor and
mention which are usable for strings and which not, and that no builtin
fields are strings.
This got probably implemented long before the change in
c74b4c6b90. Or actually maybe not at all.
In any case, it'd cause an ambiguity with the 2D char view constructor
when the "updimensioning" StridedArrayView constructor gets introduced.
I spent some time wondering if as<PbrClearCoatMaterialData>() can be
used on a material that doesn't neccessarily have that layer. It can, so
hint that in the docs.
It was creating the pool with 7 buffers, which the driver could as well
just round up to 8 and then allocating 8 would not fail. The test used
to work on Mesa before but not anymore. So I'm creating the pool with 8
and askin for 80 which should definitely fail.
There's a lot more failures on NVidia, I "fixed" those by deleting the
NVidia Vulkan ICD file for now.
While UfbxImporter knows to import these directly, AssimpImporter tries
to load them as FBX and fails (heh!), and ObjImporter has no idea about
materials at all, so recognizing this extension would only add more harm
than good at the moment.
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.
To match the order (and thus also verbose log) in which they're added
inside addImporterContents(), and subsequently also the order
magnum-sceneconverter processes them manually. There's no reason to have
it different and cause confusion.
The number of items is known beforehand, so avoid unnecessary
reallocations. When mesh LODs are supported this won't be that clear
anymore, nevertheless it's never bad to pre-reserve.
Using the InPlaceInit constructor instead of an unnecessarily verbose
array<T>({...}) helper, indenting the command-line arguments so they're
easier to distinguish from the rest.
Because I got tired of having to manually postprocess ground truth files
for shader tests.
A bit strange / funny that the first ever version of my code manages to
produce smaller files than both stb_image and ImageMagick (with
-compress RunTimeLengthEncoded), for some reason both pick some strange
inefficient run combinations in various scenarios, such as "copy 2" +
"repeat 3" where I pick "repeat 5". And the difference is not
insignificant -- when testing with some shader test files, it resulted
in a ~17% smaller size!
The plugin follows the stricter variant of the spec by default (i.e.,
splitting runs across scanline boundaries) -- so that's *not* the
reason for the weird differences between my code and theirs -- but
provides an option to not do that for even smaller files. Which I'm
going to use for shader ground truth test files, because there every
byte counts. This option together with the above difference causes files
to be ~25% smaller, which is quite a lot.