Maybe this question was asked in some other post, and if so feel free to direct me to it. But, help please :( .

For TLDR, skip to the 2nd to the last paragraph.

I have an animation project consisting of an object which is orbited (in a curvaceous way) by a first camera on a track. the track goes all around the object, as seen below (though it looks like a closed loop, it's actually a bezier curve that has a tiny opening). The first camera has a damped track constraint to an empty in the object. It also has a locked track constraint to an empty on another, nearly identical track above this track. The empty on the above track has almost the exact same movement and speed as the first camera. It is meant to keep the first camera pointing...I guess, up. (If the two tracks are identically aligned, it can be problematic at a couple points in the animation, triggering the camera to "snap rotate", but I'll treat this as another matter.)

Another camera copies the transforms of the first camera on the first track, and this "copy camera" is used by a Python script to insert VisualLocRot keyframes for the duration of the animation.

The script that uses the copy camera, before it finishes inserting each keyframe, does a "camera to view selected" on the subject being orbited, which fits the entire object to the vertical or horizontal edges of the camera view.

Problem is, I'm getting what I call "rotation artifacts", pictured below, in the F-curves. Just by looking at the selected keyframes, I can kind of tell what's happening, but I don't understand why Blender is doing it that way. (Why can't the curves keep going up or down, without breaking like that?) I don't know how to fix.

I hope to soon grasp all the algebra and trig I need to understand this problem better. Are quaternions my magical unicorn solution? Please let me know if I've done a bad job of explaining this, or if you need more info.

camera on a track, orbiting subject


  • $\begingroup$ Sorry about the title. I forgot to fix that. $\endgroup$ Jan 25 '16 at 5:34
  • $\begingroup$ you can edit your question any time (or any post for that matter), just use the "edit" link below the question. $\endgroup$
    – David
    Jan 25 '16 at 5:59
  • $\begingroup$ You might have tripped on "Gimbal Lock" problem with Euler. And yes Quaternions method let you avoid the "Gimbal Lock" issue. There is a very clear video about gimbal lock issue here ... youtube.com/… $\endgroup$
    – hawkenfox
    Jan 25 '16 at 8:41

The Gimbal Lock ... maybe?



Understanding the topic may help you avoid gimbal lock if you want to continue using Euler solutions. To summarise what I have learn is that if your object is a camera, you can avoid Euler's gimbal lock with some good knowledge and learn how to avoid them. However if you are working of an object like a fighter jet that has radical rotation in your scene, it's best to apply Quaternions.


I suspect you are having the same problem I had in How do I ensure a sequence of quaternions from matrix.decompose() is continuous? .

It boils down to "q and -q both represent the same orientation". Since you mention a "script", maybe you can modify your script to use the same logic as my QuaternionStabilizer class to figure out whether to keyframe q or -q.

  • $\begingroup$ After visiting your link, this looks like exactly the answer I need! I will look into this, though, it will take me some time to understand all of it. Thanks. $\endgroup$ Jan 25 '16 at 16:03

Your Answer

