Such an unnecessary footgun -- I was already checking the other case,
having attribute data too short, but this I thought is fine because it's
not leading to any crash. Well it's leading to needless pain and
suffering, that's what it is doing!
And of course already found FIVE such bugs in just Magnum tests alone.
Logic mostly the same as with MaterialAttribute::*TextureCoordinates --
attribute not present is treated the same way as if the layer was 0
(since that's what a 2D non-array texture is, a single-slice array), and
conversely if the attribute is 0 it's the same as if it would be not
present at all. Plus it also gets checked in queries for packed
textures, if everything is the same but the layer is different, then
it's not a packed texture.
The rest of the commit is just busywork for convenience APIs.
In particular, returning true only if some coordinate set index is
non-zero -- the main use case is to know whether we need a complex
shader with multiple coordinate attributes or not.
Only PhongMaterialData do that, others not.
The 5000-line monster took 3.3 second and over 320 MB to compile. While
that may be fine for other projects, that's completely unacceptable here
-- and it seems that this one test is the cause for most of the recent
OOM issues on the CI.
Moreover, I'll be expanding MaterialData with thinfilm, sheen and other
properties that got recently added to glTF and expanding a single test
file with those simply wouldn't scale anymore.
Vladimír Vondruš