GLTFExporter: Support individual morph target animation.

[donmccurdy]

• Adds AnimationUtils.insertKeyframe().
• Adds AnimationUtils.mergeMorphTargetTracks().
• Adds AnimationClip.prototype.clone().
• Adds KeyframeTrack.prototype.clone().

While three.js allows animation clips to manipulate a single morph target at a time, glTF currently does not. This PR enables GLTFExporter to automatically merge animation tracks affecting individual morph targets, and write filler data if needed. I used a version of this code to complete #14747, converting the Rome models to GLB, which relied heavily on morph target animation.

The addition of track.clone() and clip.clone() provide a methods I've needed before — both also appear in #13430.

/cc @takahirox @fernandojsg

[takahirox]

I locally do the similar thing to convert from MMD to glTF. This's very helpful for sure.

Can't we move mergeMorphTargetTracks to AnimationUtils?

[donmccurdy]

Yeah we can certainly move mergeMorphTargetTracks to AnimationUtils. That does mean it would be in src/ rather than examples/js, I just wasn't sure if that was OK.

[takahirox]

I'm ok with that but it's very up to @mrdoob. IMO at least mergeMorphTargetTracks would be better out of the exporter for the reusability of the function and the simplicity of the exporter.

[donmccurdy]

Hm just realized this isn't quite right, even though it was sufficient for the Rome models. If mergedTrack and sourceTrack contain:

mergedTrack:
0 0 0 0 // frame 1 
0 0 0 0 // frame 2
0 0 0 0 // ...
0 0 0 0
0 0 0 0

sourceTrack:
0 // frame 1
1 // frame 4
0 // frame 5

... we need to overwrite frames 2-3 with interpolated values from sourceTrack, not just overwrite frame 0, 4, and 5. Will fix this...

[donmccurdy]

This is fixed. ✅

[donmccurdy]

I've moved mergeMorphTargetTracks() into AnimationUtils, and fixed the issue in my earlier comment. If we'd rather keep the extra code in GLTFExporter I'm also fine with that.

[donmccurdy]

@takahirox other than the remaining question of whether insertKeyframe and mergeMorphTargetTracks should be in GLTFExporter or AnimationUtils, any other issues with this PR?

[donmccurdy]

The only remaining question on this PR is whether the new code (insertKeyframe, mergeMorphTargetTracks) should be inside of GLTFExporter, or the AnimationUtils class — @mrdoob any preference on this?

[mrdoob]

@donmccurdy I think I would put it in GLTFExporter for now.

[donmccurdy]

Ok, I've made the changes. @takahirox this could probably use another round of review when you have the chance. I put the new functions onto GLTFExporter.Utils.* so the unit tests can access them; the tests were pretty helpful for this code.

[fernandojsg]

Just added a comment out of curiosity, the rest of the code lgtm, and I prefer too to have it directly on the GLTFExporter.Utils until we will have modules available on /examples.
Nice job on the tests too, really useful for this kind of issues 👍

[takahirox]

Hm, I'm still in favor of putting Animation clip operation in AnimationUtil but yeah we could move another chance if necessary.

BTW I couldn't check functionality because of lack of time...

[donmccurdy]

IMO using AnimationUtils would be an easier decision if it weren't in src/*. Maybe moving it out or splitting AnimationUtils would make sense eventually. In the meantime lets go with GLTFExporter.Utils here.

Thanks @takahirox and @fernandojsg!

[mrdoob]

Thanks!