This would be causing an ambiguity in the upcoming shader setup rework.
It's unlikely to be used in practice like this, so I don't think I
should be accounting for such ambiguity.
I'll be happy once I can delete all this brittle backwards compatibility
post-release. The problem is as follows -- when running CMake without
any options on Android, iOS, Emscripten or UWP, such as
cmake .. \
-DCMAKE_TOOLCHAIN_FILE=path/to/toolchains/generic/Emscripten.cmake
It sees that no MAGNUM_-prefixed options were used, and thus assumes the
backwards compatibility for unprefixed WITH_, TARGET_ etc is still
desired, which is the right thing to do.
But then, there was a branch that enables TARGET_GLES *unconditionally*
on mobile platforms, if the backwards compatibility mode is enabled.
That alone would be harmless on its own, just causing garbage in the
CMake cache, unfortunately right after it sees that TARGET_GLES was set
and enables also TARGET_GLES2, because that's the default behavior. So
then, when one does
cmake . -DMAGNUM_TARGET_GLES2=ON
It'll ignore that option and instead yells at the users that TARGET_GLES
was set by them and it's deprecated, even though none of that was
actually intended:
CMake Deprecation Warning at CMakeLists.txt:501 (message):
Unprefixed options such as TARGET_GLES2 are deprecated, use
MAGNUM_TARGET_GLES2 instead. Delete the unprefixed variable from
CMake cache or set both to the same value to silence this warning.
The fix is that it's no longer setting TARGET_GLES implicitly on mobile
platforms, but instead considers the mobile platforms as well in
addition to checking if TARGET_GLES is set. Which means the backwards
compatibility variable dependencies only get set if there's at least one
of them coming from the user, never by default.
A bunch of new GLES- and WebGL-specific draw() variants got added in
b30d313ecd over a year ago, but so far
they weren't exposed in any of the Shaders because it'd mean a lot of
nasty copypasting and I just didn't like that.
So instead, there's a new macro to handle this messy work, and also
tested in order to ensure everything is still as it should be and that
it works even outside the Magnum namespace. This makes it much easier to
add new draw() variants (such as indirect draws, *finally*), without
having to update every shader implementation under the sun.
One difference is that I'm now allowing drawTransformFeedback() always
-- because that makes sense. It *is* possible to use a regular shader to
draw a result of a XFB, so it doesn't make sense to attempt to block
that.
The change to Shaders will be done in the next commit.
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.
Vladimír Vondruš