Scale wrong - when using keyframes in GLTF file

[wave-electron]

@kcoley I'm currently chasing another bug relating to scaling after adding keyframes to the GLTF. What you may not have picked up on the cubeBounce example I posted yesterday. The floor scale was not correct relative to the 3 cubes for the usdz version (that was because it was not key-framed).

So in a nutshell, whenever you keyframe a mesh, that key-framed mesh changes its scale, and it is not correct. The attached files is the same file, 1 without keyframing - the scale is correct. 2 with key framing the scale is wrong. If we can fix this issue, we might finally solve the issue with multiple animations getting out of whack. cubeBounce_scale_issue_with_keyframing.zip

[wave-electron]

@kcoley Just to be clear. This is how the scene is constructed flat hierarchy in Cheetah 3D. In the first file, I have no key-framing against any of the mesh, in the second file I keyframe each mesh, but don't actually move the mesh. I merely keyframe the start and end over a 4 second period. I purely studying the effect of no keyframes versus keyframes. Does that make sense?

[wave-electron]

@kcoley This is what the preview in usdz looks like, the file has no keyframing and its scale exactly the same way as the GLTF file.

After just keyframing each mesh of the GLTF file, they all become spread apart by a factor of something. They are so small the cubes and floor you can hardly see them!

[wave-electron]

@kcoley Ok, I just manually edited the usda file with keyframing and removed everything related to scaling in the timeSamples and it fixed the scaling issue. Not surprising I know, but I just wanted to confirm that scaling is the culprit.

 float3 xformOp:scale:scale.timeSamples = {
            0: (0.01, 0.01, 0.01),

cubeBounce_with_keyframing_edited.usda.txt

[kcoley]

I think this is related to https://github.com/kcoley/gltf2usd/issues/76 as well

[kcoley]

@wave-electron just merged a fix for this https://github.com/kcoley/gltf2usd/pull/83