All animations play the same length

[markh777]

I'm not sure if this is a problem, but I can't figure out what is going on. I have a model with 2 animations that one is longer than the other, however, the shorter clip plays the same amount of time as the longer animation (by seemingly adding idle time to the end of the shorter animation).

Here is the command to convert the model.

FBX2glTF-windows-x64.exe -b -v -i c:\QBPass.fbx -o c:\gout\QBPass

Any help would be greatly appreciated.

QBPass.zip

[ehs035]

I have the same issue.

[zellski]

Thanks!

[zellski]

I went to look into this issue, but the ZIP file only contains a .glb. That's not meaningful, I need the .fbx file. Could either @ehs035 @markh777 supply one that demonstrates the broken behaviour?

[ehs035]

I sent 2 links in email one for the FBI and one for the glb file. Here is the link again. Let me know if it works for you. https://csod365-my.sharepoint.com/personal/rgeiser_csod_com/_layouts/15/guestaccess.aspx?email=zell%40fb.com&e=VaWnsl&share=EXeeRjg2xTVKp8TSv_RHGjwBH6ZDJRIFI98GrB2rdzSZPw&cid=91582df2-84cf-4e85-8a57-f162f02e06cd

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: Pär Winzell notifications@github.com Sent: Friday, May 3, 2019 6:28:36 PM To: facebookincubator/FBX2glTF Cc: ehs035; Mention Subject: Re: [facebookincubator/FBX2glTF] All animations play the same length (#181)

I went to look into this issue, but the ZIP file only contains a .glb. That's not meaningful, I need the .fbx file. Could either @ehs035https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fehs035&data=02%7C01%7C%7C0a1b17febbab4b4d504708d6d02fd4bc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636925301175636103&sdata=jk7uX5EdgAUg7klOU8lIfGLi%2BiW%2FkJITFmsOcQMigJY%3D&reserved=0 @markh777https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmarkh777&data=02%7C01%7C%7C0a1b17febbab4b4d504708d6d02fd4bc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636925301175646114&sdata=RLuROSsFhj8gBiNX84yrWq3vOHVdqPAdenRwVmel1os%3D&reserved=0 supply one that demonstrates the broken behaviour?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ffacebookincubator%2FFBX2glTF%2Fissues%2F181%23issuecomment-489282323&data=02%7C01%7C%7C0a1b17febbab4b4d504708d6d02fd4bc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636925301175656119&sdata=ylpjf7w1QSB60CDKC76KOsRrPunPToLXjFZxATUUChY%3D&reserved=0, or mute the threadhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADRMWPX3I2DFSYX3UWYUBJLPTTREJANCNFSM4HGR54QA&data=02%7C01%7C%7C0a1b17febbab4b4d504708d6d02fd4bc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636925301175666130&sdata=Rlr3OgLwvAYsyyOpbkshsCq0voOZU7Z%2BevESDPC89cY%3D&reserved=0.

[zellski]

@ehs035 haha, sorry, yes, I just remembered that email. thanks again.

[zellski]

@ehs035 Interestingly, I can't even successfully convert that FBX. It fails on one of the many assertion points in the code that are meant to reject complicated parts of the FBX specification that we don't even try to cover.

Luckily however, I think the test was just flawed. Once I fixed that, I uncovered the problem you're actually reporting –– that the animations are all artificially lengthened. At first glance it looks like it's the presence of morph targets (blend shapes) that's confusing the logic. I'll dig deeper –– this is certainly not correct behaviour.

[zellski]

I think the issue is that a FBX file contains animation "take" information separate from all the rest of the animation data, and that for whatever reason, the exporter you use is writing incorrect information in those fields -- they all come out of the import section of the FBX SDK as 858 frames long, even though that's only the correct count for one of them.

If I'm right, the fix is probably to stop using takes -- that's an outdated class anyway. I don't know if this is a simple tweak or a rewrite -- I'll look more in the morning.

[markh777]

Reallusion 3d Exchange is what I used to export to FBX. Not 100% what Take Information is, or how to stop using it. Here in FBX file I use that has two animations of different lengths, originally, but after conversion have the same length.

Guitar.zip

[zellski]

The exporter is probably not quite doing the right thing. However, FBX2glTF's solution is too fragile. The SDK documentation says this:

This "stop" time should be seen as a time marker. Typically it would represent the whole animation ending time but its use (and update) is left to the calling application (with one exception occurring in the BakeLayers). The FBX SDK does not use this value internally and only guarantees that it will be stored to the FBX file and retrieved from it.

The correct fix to the current approach is to stop looking at these fragile values, and calculate the full time bound from the real underlying data that the SDK actually uses. That should not be too much work.

Long-term, there are more low-level improvement that should be done to the animation baking, but that's a bigger project. More later.

[ehs035]

@zellski Thanks for spending time on fixing this. I agree the animation system seams to be fragile and inefficient. As a workaround for now we looping backward on the channel data and comparing the data. If they are the same we truncate them. This gives us a pretty accurate length of the clip. We also removed the times array on each track as the are the same across the clip. (see image below) We are storing the channel and time information in a string buffer (bin file) then we the save our model without the animations and load the bin file at run time and create new clips on the fly. This speeds up the model loading. I will provide some performance data next week if somebody is interested.

[ehs035]

Reallusion 3d Exchange is what I used to export to FBX. Not 100% what Take Information is, or how to stop using it. Here in FBX file I use that has two animations of different lengths, originally, but after conversion have the same length.

Guitar.zip

FYI: I use Reallusion IClone 7 and Reallusion Character Creator 3.0 to export my FBX.

[zellski]

After a couple of red herrings, I have what appears to be a working solution for all the test models I have — ones with broken (but deprecated) Start and Stop data, as with the exporter you use, and ones with clips concatenated after one another in a single stack (which is what Start and Stop is supposed to help with.)

Now we instead iterate over every curve of every curve node of every channel of each stack, and find the union of all their respective key time interval. That’s the animation’s source data. It then gets burned to glTF as starting at t=0.0.

This is s great improvement and I’m grateful for the report & the help. Will commit & fire off Azure builds tonight.

Sounds like you may have found a workaround with benefits anyway. :)

[markh777]

I'm not near as smart as @ehs035 so many thanks for working on this issue!

[zellski]

I believe this is finally fixed in https://github.com/facebookincubator/FBX2glTF/commit/df00e0538d3b152c2a3af87c08b870ec9f2bb692. If one of you is able to give it a whirl, I'd appreciate it. @ehs035 I am particularly interested in hearing if the extracted frame intervals are correct. I can't quite tell from the generated glTF.

Binaries are available under "Build artifacts" here.

Edit: Tweaked the artifact URL, had to rebuild.

[markh777]

Working great!

I'm not sure how to validate the extracted frame intervals, but visually when viewing in babylon js viewer, don m. viewer, and a-frame animation-mixer, the play length is perfect.

If it helps, according 3D Exchange, the Guitar Playing animation has 414 frames, and the raise hand animation has 896 frames.

One thing I did notice is a default animation (T-Pose) is explicitly put on the "stack".

Once again, many thanks, and let me know if I missed something in the validation.

Guitar2.zip

[zellski]

@markh777 Great to hear! Yeah, I just meant visually validated. Thanks much folks!

[ehs035]

@zellski looks like the clip duration is now correct. A beer on me when I’m back up north. The only problem I have with this solution is that the glb file size has doubled. (From 50mb to 100mb)

[zellski]

Uh... that’s confusing. You didn’t double the bake rate, right? :-) Is it possible that in addition it was actually skipping a ton of real frame frame content previously?

[ehs035]

Here are my first findings. The GLB file will have a default animation of a length of 0 with channels for all morph targets set to 0 if I export the same model with no animation. The size with the previous version of the converter 42MB, with this version 99MB. The FBX is the exact same file. I get different results by using the 2 different version of the converter. I also checked the model in THREEJS to check for bone or mesh duplication but all looks good to me. The difference in size if I add 0,1 or 4 animation is only 4MB.

[zellski]

Sounds like some dumb obvious logic bug. I probably just introduced it. Lots of this code remains fairly fragile; no time for a full rewrite, not to write a comprehensive regression test suite. I’ll peek tonight.

[cgdougm]

Possibly related bug: I'm only getting the first few frames of animation, in 'slow motion' It's as though the timeline is being interpreted as 'seconds' and it's actually 'frames?' (ie. the slow motion looks like it's running at 1/30th real time.)

The test input FBX (link provided) is a 96-frame Mixamo animation loop. I used the 0.9.6 build on Win10. I've tried different animation bake values (24 and 30) with no change. I'm not using draco. I use https://gltf-viewer.donmccurdy.com/ to playback the resulant GLB file (which has been quite good so far.)

32 meg FBX: https://drive.google.com/open?id=1xxOVbTjKfEYPro7RX_84lyhCC8lNqzmi

THANK YOU for the work you're doing.

[zellski]

@cgdougm As chance would have it, I spotted exactly this same bug only last night. I'll ty to figure out what's going on as soon as possible.

[zellski]

Well, now I'm confused -- I can't duplicate the error. I wonder if it's platform specific. Can you try playing this .glb file (inside the .zip)? The animation looks correct to me.

Jake_Burpee.zip

[cgdougm]

Good news! The GLB that you have sent me in the ZIP plays the entire animation correctly using https://gltf-viewer.donmccurdy.com/

[zellski]

Finally solved the size explosion problem; see https://github.com/facebookincubator/FBX2glTF/issues/218.