For animations, scenes, meshes and images, where the memory impact is
measurable. For others such as materials or cameras the memory impact is
either unclear (depending on the final representation) or so small it's
not important.
I realized those are too annoying when writing a glTF exporter which
contains a lot of switches over enums. And as further shown by the diff,
those were only inflicting additional pain in *all* switch statements,
nothing else, no other added value. And everywhere else the helpers are
the designated way to deal with those, so there's no point in having an
explicit enum value denoting start of a "custom range".
It wasn't even any convenient to have it in the enum, as the extra
effort needed for casting actually made it *exactly* the same length as
if I'd just use a separately-defined constant.
As it's expected that there's a lot of objects, this prints just a
compact two-line info for each -- reference count, name and a list of
fields, with [n] in case a field is repeated. The field types are listed
in SceneData.
Field contents don't seem to be that important in this case (compared to
knowing which meshes/.. are referenced and how much, which is quite
essential) and would bloat the output a lot. I might add this as some
verbose option eventually, if needed, but I don't think it will be.
Because the uncolored overly verbose output was ridicilously ugly and
hard to navigate for larger scenes. Like with TestSuite executables,
there's a --color option that defaults to automatic coloring based on
whether printing to a TTY and can be both explicitly enabled and
disabled.
We don't have a string-to-int API that can take non-null-terminated
string views yet, but we have this. And that's a much better fit in this
case.
This stripped further 4 kB off the release binary size (178 kB before,
158 after). Fully inlined STL containers and algorithms are a very good
idea, yes.
What a stupid idea, cuz now it's impossible to know which attribute has
which ID, so using --only-attributes is just a total guesswork,
resulting in meshes that have no positions or other nightmare scenarios.
NOT a good idea, past mosra.
By the way, removing the std::sort() stripped 16 kB off the release
binary size (178 kB before, 162 after). Fancy, C++, very fancy.
This is not something the classic GPU vertex pipeline can handle
(except maybe Vulkan, which can handle zero strides for instanced
attributes?), but useful for other scenarios. This means existing code
needs to be aware of and handle the new corner case.
Highly experimental and very assert-y, as it doesn't handle mesh
primitive / attribute type incompatibility or conversion of
loops/strips/fans to indexed meshes yet.
Should have been done in f10d74041b
already, but somehow I failed to test for this case -- if there are no
scenes (materials/textures), it doesn't make sense to print reference
count for cameras/meshes/lights (textures/images).
Probably a leftover from when these dependencies were handled in a
much shittier way? For as long as I remember, enabling WITH_GL_INFO
always enabled WITH_GL and WITH_WINDOWLESSWHATEVERAPPLICATION
implicitly.
Similar to sceneconverter's --profile option, measuring import and
conversion time. This also means that sceneconverter's --profile now
includes image import time, which wasn't done before.
Because this tool is often useful to debug broken importers, it's not
wise to parse scenes even if just --info-materials was specified to
gather material reference count. The new behavior is that reference
count will be listed only if both the referer and referee data type info
is specified.
This also allowed me to remove the redundant `references` field from
Info structures -- now just the arrays are used, and if the array is
empty, then it covers both the case when refcounts were not calculated
(in which case the displayed info would be wrong) and when there's no
refered data at all (in which case the reference count info would be
superfluous).
There was also an issue that texture reference count was not calculated
when --info-materials was not set, this is now the desired behavior
(except that it's not printing the invalid zero count at all).
Because a texture can be referenced by multiple attributes in a single
materials, the reference count might be higher than actual material
count, which would be confusing. Since this is mainly for informational
purposes (finding unreferenced data in a file), it doesn't make sense to
spend time working on a proper material counter right now.
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.
Vladimír Vondruš