I have been given some FBX cameras. When I load them in Flame I get the error:
ACTION: FBX Import: unexpected large animation interval detected, would you like to reset?
The only two choices are reset or cancel. If I hit reset I only get a keyframe on frame 1 and 2. Everything else is gone. The FBX loads fine in Maya LT and Nuke but I can’t get it to work in Flame. It is 3500 frames. I thought that might be a problem so I pared it down to 250 frames in Maya and exported that, but I’m getting the same error. I tried MikeV’s python script with the same results. I think I have tried all the options. Any ideas?
Thanks,
Brian
1 Like
Unless Im missing something, all that Flame is attempting to tell you is that the FBX you are trying to load does not have animation on frame 1. What is the frame padding that your Nuke and/or Maya users are using? Im guessing its not *.1.exr, its probably like *.1001.exr. Are you SURE that you are only getting keyframes on frame 1 and 2? Open the Animation channels as it’s likely that you have animation that just needs to be translated in time to line up with your frame padding in Flame, which I’m guessing is 1.
That’s what I was expecting to happen, too. The first frame of camera is 1023128 so I set Flame’s timeline to 1500000 thinking it would be way down at the end and I would just move it down to 1. I’m only seeing a keyframe at frame 1.
1 Like
Wanna send me the FBX and I can have a look?
Okay, something is funky. That is unlike any FBX I’ve ever loaded. I see what you are saying. The error message might be a little different than what I was thinking.
What is precise amount of frames this is based on? And is 11:50:30+08 the timecode of the first frame?
It it loads in Nuke, writeGeo it out again as an alembic or again as an fbx making sure that the frame increment is 1. You can offset it in time to start at something smaller, 1,1001 and give that a try.
Just an idea…
Randy, thanks for looking at that. Yes 11:50:30+08 is supposed to be the first frame. I will go back the people that provided it for troubleshooting. It would be nice to know why it seems to work in Maya and Nuke but not in Flame.
1 Like
Thanks, this workaround would be great, except… We are trying to set up a workflow that would involve doing this to hundreds, if not thousands, of shots. So reducing the steps to as few as possible is important. Hopefully we can figure out what Flame doesn’t like about it.
1 Like
Can you post the camera? We don’t need any of the imagery. I’ve seen this before, and I remember, at least once, going out to frame one million and translating keyframes back to zero, and I feel like one time I found all of my keyfames sandwiched inside of of frame 1 and once I scaled them back out, things worked. That may have been a daydream I had while translating the keyframes out at f 1,000,000.
Neither of these is an endorsement of how Flame is handling the issue.
2 Likes
I have the camera, and, it does look like its all crammed into a single frame. I’ll let @Brian5x5 share.
It’d be worth checking what Autodesk FBX exporter version thingy they are using, and checking with the hive mind here what everyone recommends as an Autodesk FBX version of choice. It used to be Autodesk FBX version 2010…I wonder what it is lately…
Here’s the camera:
101_z127_Take0004_CamF[3].fbx.zip (1.5 MB)
Interesting that it crams them all into one and moves them all down to frame one. Any way to tell how much to X scale it by to get back to normal?
What is the precise frame count?
It looks like 14,406 frames.
1 Like
damn. you have a 14,406 frame camera track? Dayumm…Im not aware of a numerical way to X Scale. So Im stumped there. Plus, with all these keyframes, its slooowwww and I cant really get any interactivity to eyeball an X Scale of 14,406 keyframes.
Anybody have any clever ideas?
This has been a really great help. I have something to bring back to them to refine the process. They are trying to capture live camera data and output an FBX camera. It turns out this one was several takes where they just kept the camera running. It was pretty slow for me, too. I think one of the next steps will be to have them deliver a camera that matches the edl. They were hoping I could find the timecode and slip it to match the plate. I asked which version of FBX exporter they are using. I’ll let you know when they answer.
1 Like
Yeah 10 minute takes with FBX cameras sounds possibly heavy. And, a fiver says this is where the real knowledgeable hive members mention Alembic, which, is historically lighter data-wise but with a 10 minute take…well, few of us have gone there technically me thinks.
Hmm…I wonder how I’d handle visually aligning cameras via camera keyframes…ya need like a 2 pop + blip + physical camera movement as a sync mark. Interesting. Unknown if the research into solving it is any better than brute force or just dealing with match moves after the fact.
Interesting challenge. Keep us posted with what you figure out!
There may be a Python solution, to parse an FBX, and to assign FBX keyframes to Flame keyframes. That’s beyond my expertise and likely more complicated than a brute force solve.
1 Like
This is weird. I thought I would be clever by importing the FBX, making the timeline 14,406f long and using the TRACKS to drag the tail out to f14,406.
but, after doing that, the keyframes, all of them, are STILL sandwiched between 0 and 1.
Weirder still, when I made a track with a high TC and tracked it in Syntheyes (which forces every track to start at frame 0, at least at my skill level) then brought it back into Flame I got a different (and more useful) warning regarding Syntheyes’ 1f discrepancy:
1 Like
This is the error message I thought @Brian5x5 was getting. But is a 14,406f FBX Sandwich all smashed into a single frame of a wet paper bag.