Joint BEZIER animation baked to every frame

[ladiszlai]

Okay so I have an animated cube with 5 keyframes in 70 frames in my blend file: https://files.fm/u/ujs4w23g

As you can see:

Exported to glTF: https://pastebin.com/cD6Kpmii

My question is why I have "count" : 70 in the keyframe time accessor (input) ? Shouldn't be it just "count" : 5 ? For my project what I am working I need the correct keyframes, because I can't calculate them if it is storing all of the frames...

[donmccurdy]

What settings have you selected at export? Some, like baked skinning constraints, will cause animation to be resampled at every frame.

[ladiszlai]

I have these.

[emackey]

There are a set of rules in this exporter for when it thinks glTF 2.0 animations can't match what Blender is doing, and in such cases it labels the interpolation as CONVERSION_NEEDED which effectively means it will bake all the frames into keyframes.

I won't claim to fully understand these rules, but it sounds like you need to avoid triggering them if you want your number of keyframes to match.

[ladiszlai]

Based on that code I knew that it has something to do with the interpolation type, then I realized that glTF doesn't support BEZIER keyframes (I tought my keyframes are set to LINEAR but blender sets them BEZIER as default like in Cinema 4D) instead of it the exporter exports it as linear but with all frames to make that bezier animation. So I changed my interpolation to linear and it seems working, I have "count" : 4 now. Thank you for the answers !

[emackey]

Great, thanks @ladiszlai.

[donmccurdy]

It is not obvious to me from those rules that BEZIER keyframes would be baked... it looks like they should become CUBICSPLINE while preserving the number of keyframes, unless there is mixing of interpolation modes between keyframe points. Inclined to say we should keep this open until figuring out what is causing the data to be inflated by 15x.

[emackey]

My current thinking is that Blender allows the user to specify an interpolation per-keyframe, whereas glTF only allows per-channel. If the exporter finds mixed interpolation types within a single channel, it will bake everything.

[emackey]

I'm fine reopening this though.

[donmccurdy]

If the exporter finds mixed interpolation types within a single channel, it will bake everything.

That sounds right so far, but looking into the file...

action = bpy.context.object.animation_data.action
for fcurve in action.fcurves:
  for point in fcurve.keyframe_points:
    print(point.interpolation)

... all of the keyframe points are BEZIER. There are a number of other cases in gltf2_generate.py that trigger keyframes to be baked, including notably:

if interpolation == 'CUBICSPLINE' and node_type == 'JOINT':
  interpolation = 'CONVERSION_NEEDED'

That seems like an undesirable limitation, so let's keep this open until we can fix it or find and document the reason.

[donmccurdy]

I quickly tried a couple other formats and found the "Better Collada" loader also seems to bake keyframes in similar situations. Blender's FBX exporter appeared to preserve the input data better. Don't know yet whether that's a difference in format representation, or something we could implement in this loader.

In any case, if I disable those overrides and try to export with CUBICSPLINE on joints, it does look very broken.

[donmccurdy]

Likely a related issue — when animating shape keys with bezier interpolation, the animations are coming out with linear interpolation, baked from the original ~4 keyframes to 60 keyframes.

TwoShapeKeys.zip

[donmccurdy]

The new exporter (https://github.com/KhronosGroup/glTF-Blender-IO) has a rewritten implementation of skinning. We're still working out some issues there, but if this is still an issue afterward let's reopen it on that repository.