Sometimes it's a vital piece of information, e.g. the file having no
default might lead to it being not displayed correctly as some end-user
application might think it has no scene.
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.
It doesn't discard meshes that are not a part of the hierarchy, but that
was the plan in the beginning. However, over the time I realized that a
better property for it is that the output is guaranteed to be in the
same order and size as the mesh field in the scene. Because that's what
I relied on in every use case, and every time I had to dig that property
out of the sources because it was deliberately not documented *because*
it was meant to change.
No longer. The compatibility with the mesh field ordering is now
documented, the behavior regarding loose objects also, and if there's
ever a need to discard everything that's not in the reachable hierarchy,
it'll probably get its own API. Because it's useful for general
asset cleanup and other use cases, not just meshes.
I'm still keeping the experimental tag here though, tp be sure.
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.
Until now this was silently ignored with the assumption that there
*might* be a TGA 2 header. But now that we actually recognize it, any
extra data are an error in the file, and so it should print a warning.
Since it's not an error that could potentially lead to a crash, it's
just a warning and not a hard failure. Same is done in ASTC, DDS and
KTX file parsing.
This significantly simplifies everything -- because a single type can
now handle both StringView lists and char* lists, we no longer need a
templated private helper to avoid allocating a temporary array of
unified type. Instead, the whole extension initialization can be done
directly in the initialize() helper, by simply iterating over the
argument.
Yay, this is probably the nicest improvement caused by StringIterable so
far.
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.
Currently contains just one very silly Phong->PBR conversion utility,
but eventually it'll provide tools for simplifying, merging and
deduplicating materials.
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.
The result of e.g. -15.0_degf is not Deg, but rather
Math::Unit<Math::Deg, Float>, and those didn't have a corresponding
TweakableParser defined. Now they do.
Funny how I didn't run into this until now.
Apparently can't even test that the returned time is in some range. So
I'll test only that the time isn't less than expected. Which it
sometimes is, on Emscripten, so add an epsilon for that as well.
Vladimír Vondruš