Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Warn about constant animation sampler output accessor values? #200

Open
javagl opened this issue Oct 26, 2022 · 2 comments
Open

Warn about constant animation sampler output accessor values? #200

javagl opened this issue Oct 26, 2022 · 2 comments

Comments

@javagl
Copy link

javagl commented Oct 26, 2022

This is similar to #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
Copy link
Member

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants