Warn about constant animation sampler output accessor values?

[javagl]

This is similar to https://github.com/KhronosGroup/glTF-Validator/issues/184 in some ways, but the differences in the technical details and implementation may justify bringing this up as an own issue:

Should there be a warning (or at least, a hint) when accessors that are used as animations[a].samplers[s].output have constant values?

(Or are there any cases where it makes sense to export such constant values? One could probably think about extensions that might need this data or so, but from the core spec perspective, this does not seem to make sense...)

---

(Apparently, some generators always export all properties (rotation, translation, scale) as animated properties as soon as one property is animated, and ... apparently, sometimes even when no property is animated at all 😕 - of course, one could shrug this off and say "Yeah, then that's just a bad asset generator". But the implications on memory and performance may be significant, so I think that this should be strongly discouraged).

[lexaknyazev]

The spec does not (and generally should not) cover inefficient glTF usage as opposed to invalid, although there may be cases that fall somewhere in between.

Some workflows may prefer using a common timestamps track for multiple outputs and/or constant rate of key values, thus adjacent output values may be equal in such a case. I think the validator may hint when all values of an output track are the same, except when there is only one frame with STEP interpolation.

[donmccurdy]

Or are there any cases where it makes sense to export such constant values?

I've seen at least once such case, in which the base pose for an animation is different from the skeleton's (e.g. idle vs. t-pose). In this case the exporter might create a channel for each bone, with 1-2 keyframes in each, and longer keyframe channels for the bones that are actually animated.

I think the case of repeated output values is probably not much different from the (very common) case of colinear outputs on a LINEAR channel, baked at 24-30 FPS. Inefficient but not invalid, and there are fair reasons an exporter might choose this. For example, authoring software might not want to throw away any keyframes the artist has manually placed, or might feel that resampling animation is out of scope. Tools like gltfpack and gltf-transform can resample for you and optimize the keyframe channels, but I don't know that optimization should be a prerequisite to passing the validation suite.