Exporters: Export causes mesh scale change in gltf/glb animation

[BaldSavant]

In Maya, I'm exporting a character rig which holds 3 unrigged, unconstrained props. The character and props animate over 8300 frames, performing various actions, each of which is contained in a clip (babylon calls them animation groups). The props are scaled from and to 0.001 scale to simulate disappearing during certain actions. This happens multiple times for each prop. On one such time, one of my props is being pulled out from behind the character. During this specific animation, and at no other time, the gltf/glb maintains the scale of the object at 0.001, making the object effectively invisible.

While debugging this issue, I've opened the file in the babylonjs sandbox viewer and was able to navigate to the clip where this happens, and the prop's position in the hierarchy and set its scale to 1, at which point it worked as expected. I've also confirmed the animation exports as expected as an FBX.

As far as I can tell, there's nothing different about this particular clip in Maya, and the entire section where this happens is contained in a single clip (animation group), so I'm suspecting there's some error during the export.

Any suggestions?

[deltakosh]

Pinging @PatrickRyanMS for guidance

[PatrickRyanMS]

@BaldSavant is there any way you can share your source file? It would be easiest to debug if we could look at your exact source to see if there is anything specific to your file that may be making the export fail to write the accurate data.

From what I am reading you have three meshes that have node animation on them mixed with different meshes with skinned animation and you are only experiencing the issue in the node animations, but I want to be sure I understand exactly how your file is built.

[BaldSavant]

That's an accurate summation. I figured you'd ask to see the file, so I've asked my bosses if it's ok to share, but I'll have to wait til I hear back. Hopefully won't take too long, but they're off on a business trip.

edit: and to further clarify, not only am I only experiencing the issue in the node animations, it's only happening on ONE of the node animations. All the rest work as expected.

[PatrickRyanMS]

edit: and to further clarify, not only am I only experiencing the issue in the node animations, it's only happening on ONE of the node animations. All the rest work as expected.

That was my assumption and tells me there is something specific to that node that we are having some difficulty with on export. Please take whatever precautions you need with the privacy around the model including NDAs and we are happy to do what we need to unblock you.

[BaldSavant]

Ok, so we can't release the file currently, but what I CAN do is send you a version of the file with just the props. That's where the problem is anyway, so hopefully that'll do just fine.

https://drive.google.com/open?id=1DDrzVlvDddi9_G0UNvMSTfx_zRG2Vvh5

I've tested the export and I still get the same scale issues with the prop. If you open the file, clip 023b is the one where it should be appearing and isn't. In this export there's a few other spots where it doesn't seem to show up either, such as "idle_03_holdingItems" which has consistently been my reference clip during each other export. However, it is properly scaled at clip 024. I'll assume the differences are due to the lack of a character rig here, but it still behaves close enough to the way it was that it should still test the same? Hopefully?

Let me know if this helps you figure out anything, or if you need new information!

[PatrickRyanMS]

@BaldSavant, thank you for sharing this asset with us as it was instrumental in identifying the issue quickly. We know what is going on and it is an issue with the exporter. We have a plan for a fix and should be able to have a new version of the exporter up quickly. I can't stress enough how helpful seeing the actual file was as we can't always predict how a file is built and that can elongate the investigation or lead to misses in reproducing the issue. So thank you again for finding a way to share the source with us!

[BaldSavant]

Happy to help! Do you have an ETA for when I might see a fix? We've got a project on hold until this export can happen.

[PatrickRyanMS]

@Drigax, who is the owner of the exporter code, is out of the office today but should be back in tomorrow. Barring any major complications, I assume we should be able to have a fix tomorrow but I can't truly speak for @Drigax. This will be our highest priority in the morning and we'll report back with an update asap tomorrow.

[Drigax]

Thanks for looking into this @PatrickRyanMS. This definitely helped me pinpoint where to look at in our animation export code. I'm taking a look at this right now.

[Drigax]

Looks like we're over-optimizing the animation data, and aren't respecting the "Bake Animations" flag.
In our GLTF exporter we do a pass to remove unnecessary animation keys, and leave the first and last and other significant keyframes for the animation frames included in the group:

https://github.com/BabylonJS/Exporters/blob/15f442f9689a975d49e2f4a3f9cec4d766274e83/Maya/Exporter/BabylonExporter.GLTFExporter.Animation.cs#L162-L163

After, we would do another optimization pass to remove animation tracks that would be equivalent to an identity

https://github.com/BabylonJS/Exporters/blob/15f442f9689a975d49e2f4a3f9cec4d766274e83/Maya/Exporter/BabylonExporter.Animation.cs#L477-L514

Which would remove the track in animation groups like idle_03_holding items that re scale the prop to 1, but does so before the animation group start and does not change at any time within the animation group frames.

I think the best way to fix this would be to remove this second optimization from our animation baking codepath, and instead bake all animation channels for a given group, but only export the ones that have any keyframing in the scene.

EDIT
The actual implementation ended up being a bit simpler, since our in-memory babylon scene has data for each frame for each element in the scene.

Instead of looking at the keyframe data (Which would be inaccessible for the GLTF exporter given its current design), we can look at the baked frame data for the animation channel for every frame in the scene. I now put the channel data through an optimization pass to remove redundant frames, and if there are any relevant frames in the channel, we then export the optimized keyframes for the given animation group.