Now it's a field and its corresponding object mapping, instead of
field and "objects":
- Goes better with the concept that there's not really any materialized
"object" anywhere, just fields mapped to them.
- No more weird singular/plural difference between field() and
objects(), it's field() and mapping() now.
- The objectCount() that actually wasn't really object count is now a
mappingBound(), an upper bound for object IDs contained in the object
mapping views. Which is quite self-explanatory without having to
mention every time that the range may be sparse.
Because that way one can query a field with *AsArray() and iterate
through it in a single expression. This also resolves the pending issue
where it was more than annoying to fetch object mapping for TRS fields
when only a subset of the fields is available.
Was waiting for this to happen, as going through all the objects would
have been too messy. Plugins implemented using the legacy API will
now only show the parent field in SceneData, but since those eventually
get all ported, that's fine.
Reason is that Assimp custom material attribute names are also prefixed
with $ and other weird characters, which could lead to them appearing
before $LayerName, causing a layer to falsely appear unnamed. A space,
instead, is before all printable characters so it's guaranteed to be
always first.
Some things you just don't realize at first. Fortunately the binary
layout isn't pinned yet for the serialization format so this change is
mostly fine.
Memory-maps the file and uses openMemory() instead of openFile(). For
efficient data formats (such as glTF) can avoid reading the whole blob
if only the metadata or a part of the file is needed (for example the
peak usage for --info-materials with the Buggy.glb example model went
from 8.5 MB to 991 kB, as it reads just the JSON at the start and never
even pages in the buffer blobs at the end).
This currently only works for standalone files, files that reference
external images etc. would need to have file callbacks implemented. And
it's Sunday and I'm lazy.
Because it was getting annoying to scroll through the output, especially
with shitty files that duplicate materials etc. The --info is now a
shortcut for specifying all other --info options together.
Minor but very important convenience feature, especially useful when
dealing with command-line apps. This now works:
magnum-imageconverter a.png a.jpg -c jpegQuality=0.75
The AnyImageConverter gets the jpegQuality option and then
automatically propagates it to the concrete plugin (which is either
JpegImageConverter or StbImageConverter), possibly warning in case the
target plugin doesn't recognize given option (i.e., doesn't list it in
its default configuration). Previously the user had to always specify a
concrete converter implementation using -C, which was rather annoying
and nonintuitive.
It should be input first, output second, like with all other APIs. I
remember I was trying something else here, but that didn't really make
sense in the end. Also took that opportunity to get rid of one
std::string.
The original signature is a deprecated alias to the new one and will be
removed in a future release.
There will be Flag::FlipY for images at some point, enabled by default
for compatibility with existing GL code, and so it makes sense to start
discouraging setFlags() as early as possible to avoid people resetting
the default by accident.
Also update the imageconverter, sceneconverter and shaderconverter utils
to use these instead of setFlags().
If it's ignored, a warning is printed to catch accidents, but not an
error since it should be possible to just append --info to existing
command line to see what the input is about.
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.