I'm not sure why this restriction was there as nothing was preventing
them from being used. The attribute is only accessible through the
typeless attribute(), which gives back
`Containers::StridedArrayView2D<const char>` with second dimension size
being set to the full stride. And there it doesn't matter if the format
is an array or not.
This will be useful for joint IDs and weights, for example doing crazy
things like packing the IDs into an array of 8 4-bit numbers, saving
half the memory compared to the smallest builtin representation using
UnsignedByte[8].
A lot of pain went into creating owned mesh data even though it was
completely unnecessary in retrospect. Originally I thought "let's not
use any advanced feature" but the verbosity is just not worth it.
In the recent-ish SceneData tests I went with non-owned data already,
and it was much simpler. It's a learning process even for using my own
APIs, huh.
Except the base GL and Vulkan one. Because usually the nondeprecated
builds needs the most iterations and any builds that run after it failed
are just wasting credits.
What's especially nice is that the code snippets no longer need to
describe that there's "2 lights, 3 materials and 5 draws" because now
it's self-documenting.
Because it was no longer bearable with three UnsignedInt arguments in a
row, especially when some of them are only available on a subset of
platforms. And it would get even worse with introduction of planned
features such as multiview or skinning.
Backwards compatibility is in place, as always. To ensure nothing
breaks, this commit still has all tests and snippets using the old API.
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.
Vladimír Vondruš