Compared to Corrade, the improvement in compile time is about a minute
cumulative across all cores, or about 8 seconds on an 8-core system (~2
minutes before, ~1:52 after). Not bad at all. And this is with a
deprecated build, the non-deprecated build is 1:48 -> 1:41.
When writing high-level documentation for those I realized that it's
easier to just add the r-value variants than trying to explain why one
has to be careful to not pass r-values there.
Matching what's in MeshTools, because I need them to implement other
algorithms that match what's in MeshTools. In other words no idea why I
didn't make these along with copy() already.
Doxygen 1.12 has no longer a completely insane matcher and discards
those as it should. With 1.8.17 classes had to be referenced with
Corrade:: but functions, typedefs and variables didn't need to be and it
was a complete utter chaos.
Amazing, I haven't been in this corner of the codebase for over six
months but the test setup and code coverage still makes it quite
straightforward to add a rather complex new feature without breaking
unrelated cases or leaving certain areas completely untested.
To be used with the recently added MaterialTools::removeDuplicates() for
example, or internally by other upcoming scene tools such as importer
filtering.
Not that C++ STL and exceptions would be anything to take inspiration
from, but there's std::out_of_range. Python IndexError is also specified
as "index out of range", not "bounds".
Partially needed to avoid build breakages because Corrade itself
switched as well, partially because a cleanup is always good. Done
except for (STL-heavy) code that's deprecated or SceneGraph-related APIs
that are still quite full of STL as well.
Such as Emscripten or Android. The hypothetical use case is converting
shader files directly on an Android device to debug things, or having a
Node.js build of a scene/image converter for "portability".
Static plugins can be linked to these if Magnum is built together with
Magnum Plugins in a CMake superproject and the plugins are then linked
via the MAGNUM_*CONVERTER_STATIC_PLUGINS CMake variable.
The fontconverter and distanceconverter tools cause a CMake error on
Emscripten as it's not currently possible to access the GPU through a
command-line Node.js app. On Android they work though.
The KTX and glTF plugins now print a commit identifier in their
generator string for better tool trackability, have to disable that to
have predictable output.
The DDS plugin now Y-flips compressed pixel formats, leading to a
different message. Disabling the flip to not have to deal with any
message at all.
Not sure what was I thinking here -- if a field size wouldn't fit into a
32bit number, it won't fit into memory of a 32bit system anyway, so
there's no real use for the size to be returned as 64bit always.
Internally it *is* stored as a 64bit number, yes, to have compatible
binary layout on 32bit and 64bit systems, but that doesn't mean the
public API should return that too. And SceneData::fieldSize() is
std::size_t, so this feels really like an accidental brainfart.
The changed return type also means a lot of existing code doesn't need
to do any explicit casting to std::size_t anymore. Yay.
A bit sad it took me three years to invent the right name for this
utility, heh. Also moving it together with others to a new
MeshTools/Copy.h header because *this* is the mainly useful API, not
reference() / mutableReference().
MaterialTools and SceneTools will get similar copy() APIs doing the same
thing.
A somewhat inverse / complementary utility for parentsBreadthFirst() --
while the former is useful mainly for convenient parent referencing,
this is for children and nested children. Currently the main use case is
extracting scene subtrees, which is also what the example snippet shows.
Getting a list of direct children is also possible, although for that
it's possible to use the parentsBreadthFirst() as well as the Parent
field directly, simply by scanning for all field entries with given
value.
This allows to filter individual field entries in the scene, such as
for example removing certain mesh assignments that were collapsed
together. A higher-level API that allows filtering all data belonging to
a certain set of objects will be then implemented on top of this one.
Same reasoning as before, the verb suggests it's transforming the
SceneData in some way, which isn't true, it just retrieves the data in a
certain way. And if an API that actually operates on SceneData got
added, it would be easily confused with this one.
Plus, the "order" isn't just one, this orders objects so they're grouped
with a common parent, but what if I wanted to instead order depth first?
Thus it's explicitly saying this is a breadth-first order.
The API got moved to the Hierarchy.h header, removing a need for a
dedicated file and test.
Vladimír Vondruš