38 frame PAL clip. (So, on DS, 37 frames active)
Import Fraws.
Each keyframe is progressively later than the previous by a fraction of a frame, so that by the end of the clip the keyframes are almost exactly 1.5 frames late. There are the correct number of keyframes, they’re just spaced slightly too far apart. It’s reasonably easily corrected, but it’s nevertheless wrong. I can’t imagine what I could be doing wrong, so I assume it’s a Mocha bug.
Also, the FRAWs come in with Bezier nodes whereas they’d be better as Linear. Perhaps that’s a DS limitation?
I guess it could be, though each key can have it’s own slope which is what the other 2 columns are on each key, set to 0.000000.
But as I said, I have no official information
Why do you want the keys to be linear? Does it do wierd things when you render in fields or something? I almost always am tracking on frame-based material so I’ve never tried. Just curious what the issue is. Monet/Mocha can track in fields and it looks like it makes keys for each field when you do that.
Interestingly, the first line of the .fraw files Mocha is generating says
600 20
where 600 is the number of keys (in my case) and 20 which is the interpolation of the fcurve… however, the only values I know to be valid are 0 for Constant, 1 for Linear, or 2 for Spline (but I don’t have an SDK so maybe 20 does mean something? )
Well, for interlaced material yes I could track in fields, but that’s twice as much tracking as tracking in frames. If there’s no wild inter-field movement then frame tracking will be just as precise.
DS’s guides have always stressed the importance of making tracks linear, and I’m used to that workflow.
And to answer the first bit of your question last, yes, if you leave the curve Bezier as it imports, then every other field is incorrect and you get a blurred result.
>From what you’ve noted, it looks like it might be pretty simple for the fraw export to be linear by default.
—Quote (Originally by Bob Maple)—
Interestingly, the first line of the .fraw files Mocha is generating says
600 20
where 600 is the number of keys (in my case) and 20 which is the interpolation of the fcurve… however, the only values I know to be valid are 0 for Constant, 1 for Linear, or 2 for Spline (but I don’t have an SDK so maybe 20 does mean something? )
—End Quote—
Hey Hi Bob & Jef,
Maybe (just maybe) 20 is 2 for Bezier, and 0 for the slope of the keys. It would explain why we get curves with all the keys with ‘flat’ bezier handles.