-
Problem with The Foundary’s Camera Tracker for AE *Z-axis*
AE CS5.5, Camera Tracker 1.0v6, Windows 7 64 bit, 3.07 GHz i7 quad core, 12 GB RAM, Matrox MXO2 LE, NVidia Quadro 4000.
I have some footage shot from an RC helicopter on a DSLR (converted to lossless MOV because the original codec didn’t play well with AE). The shot is a crane-like pedestal/arc/dolly shot.
It tracks great, and motion-tracked text looks awesome.
However… there’s a problem with the solved camera’s z-axis keyframes. For the first half of the footage (about 8 seconds), the z-axis wavers around -180 degrees. All of a sudden (near 8 seconds) the z-axis spinns around to +180 degrees and stays in the positive for the rest of the track.
This wouldn’t be a problem, since the spin happens between keyframes (one keyframe is negative, the very next is positive). BUT, when I turn on motion blur, one of the keyframes puts this crazy circular motion blur on my text as the camera spins 360 degrees on the Z-axis.
OK, fine, I’ll just change the first half of the keyframes to positive and all will be well. After all, a 360 degree spin won’t be any different, visually. Right?
Well, I copied the negative keyframes to a 3D null, put this expression on it [value*-1], baked the expression to keyframes, then copied the new positive keyframes to the camera, replacing the negative ones.
But when I do that, the 3D elements in my scene shift (rotate on the z-axis) slightly, as if the value was odd a tad. But I’ve compared the numerical values for the negative keyframes with the values of the positive ones, and they are identical, but for the +/-. Even out to the 10,000th decimal place!! (-179.5459)
So I can’t figure out
A) why the camera spun 360 degrees on the Z-axis to begin with, and
B) why the positive keyframes cause my scene to shift shift (rotate on the z-axis) slightly.
It’s driving me nuts!
-
13 Replies
-
you shouldn’t set the value to just positive, you’ll have to add 360 to it. -179 would be 181. That’s why they shift. I goes to negative because its a matter of the orientation conversion (imho).
You can also just try to set the last of the negative keyframe to hold. Thus breaking the oddly motion blur on that frame, though you would also probably lose the smooth motion blur there.
-
360. Not positive. You’re a genius.
And I don’t want to hold the last negative keyframe because there’s more movement after it. The track would get thrown off.
But thanks for the fix! I’ll try it and report back.
-
[Tim Parsons] “And I don’t want to hold the last negative keyframe because there’s more movement after it. The track would get thrown off.”
Sure, I understand this is not a real solution. But you said every single frame is keyframed so this would not break the track just the motion blur for that frame (Since AE won’t be able to interpolate). Anyway go ahead with the first option.
a=transform.zRotation;
(a <0?a:a+360); -
Oh, I get it. I thought you were suggesting getting rid of the positive keyframes and just holding the keyframe for the rest of the comp. Silly me.
Well, your 360 vs. negative idea worked beautifully, so far as I can tell. Thanks a ton!
Any idea why it would have done this?
-
My code is wrong (not that you actually needed it). It should be “>” for the if check
-
A vague idea yes. Its a matter how the gimbal rotation works when the camera has a target. you can’t pass the 360º angle. You either have to “invert” the Z axis or the other 2.
-
I’m not fluent in expressions. I know enough to get by (wiggle, parenting, etc). Could you explain what’s in the parentheses?
-
sure, it’s an IF ElSE check.
“a” has the Z rotation value.
It says if “a” is higher than 0 (positive). It will keep “a” as result. Else it will add 360 to “a”.
-
So “?” = “then” and “:” = “else” is that right?
-
Yes, that logic is correct. I tend to save some expressions on a text file, cause I can never remember the notation without copying/pasting. =P
Reply to this Discussion! Login or Sign Up