1
$\begingroup$

Right now I'm doing this as follows:

  • There is a path the camera position is constrained to. The camera is being moved along that path.
  • The camera has got a TrackTo constraint and is always targeted to a camera target (an empty object).
  • There is another path where the camera target is constrained to and is being moved along that path.
  • The TrackTo constraint for the camera does also have the TargetZ option activated. This means that the camera can be rolled by rotating the camera target.

Now the camera movement can be implemented by setting keyframes for camera and camera target on their respective paths as well as rotation of the camera target.

Although it is somewhat tricky to implement more or less realistic camera flights that way, it is working fairly well for most cases.

However, there are some issues with rolling the camera. At some occasions the rolling angle does "overshoot" somewhat. In theory, this can be compensated by adding more keyframes. However, the more keyframes are set, the less fluid the result. So this is not really an option. I did not pin down that fully yet, but my suspicion is that the issue is bound to the fact that the camera target is being rotated on all angles. When the camera target is making turns on its path, this is likely also manipulating the resulting orientation of the target, hence destroying the intended orientation. I did also try to change only one angle of the target while the other two are constantly 0. This seems to improve the situation, but there appear other problems in some occasions. So this is not a solution.

So is there some way how to roll the camera independently from the target?

I know that this would be possible by dropping the target at all and move the camera free resp. only along its path. However, with that technique it seems virtually impossible to keep the other camera angles on stable paths and the result is awful.

Thanks, Mario

Update: For illustration purposes here are two screenshots with a more or less "straight" and a "banked" camera orientation: enter image description here

enter image description here Rotation of the camera is achieved by rotating the camera target, which is being located here at the center of the viewport right at the horizon. Intuitively one would assume that the banking of the camera is being smoothly interpolated between two banking angles. Mostly this is also working nicely. But not always....

$\endgroup$
4
  • $\begingroup$ Mario, sorry but I've not read your text... too long, with no images and that leads to interpretations of the text, nothing really concrete. We are in an image world... So please illustrate what you want. $\endgroup$
    – lemon
    Apr 26, 2023 at 19:16
  • $\begingroup$ @lemon Essentially you're right, but this matter is difficult to explain in images. Actually I'd have to make a complete video explaining the matter. In essence, I want the camera to be flying like an airplane or merely a spaceship around the planet on well-defined trajectories. I believe that this is still needing the technique of using a TrackTo-constraint for the camera, but at the same time an independent rotation of the camera. So how can I rotate the camera while a TrackTo-constraint is active? (Rotating the target is not an option!) $\endgroup$
    – Mario
    Apr 26, 2023 at 22:25
  • $\begingroup$ First though, you can target something else that is linked/parented to the planet. $\endgroup$
    – lemon
    Apr 27, 2023 at 5:55
  • $\begingroup$ @lemon How this could work out? When flying across some surface, the target needs to be moving as well. I added two pictures of an exemplary scenery (specially for you ;-) where the target is always be forced to the horizon. This is done frame by frame with keyframes for the target position. This is a bit of a nasty work. But this technique is giving a very good result with respect to moving the camera and its tilt or pitch angle (up/down). Problems arise with the banking angle interpolation. $\endgroup$
    – Mario
    Apr 27, 2023 at 18:27

1 Answer 1

1
$\begingroup$

The primary problem is that different rotations of the camera target yield to identical rotations of the camera. Here is an exemplary part of a bad keyframe sequence from the graph editor: enter image description here

The highlighted graphs represent the X, Y and Z euler angles (red, green, and blue). In the highlighted time frame there are three keyframes. I'm omitting the corresponding 3D views of the scene here, but the appearance at the keyframes is not that much different from each other. However, when looking at the graph editor, especially the Z-angle of the last keyframe is far off from the first two ones - around 180 degrees, which is massive. But the X- and Y-angles differ also by some larger amount.

Now, these large changes in the angles are causing the issues during animation/interpolation between two keyframes. In this particular case the camera is making some forward-and-back roll/banking movement, which is awful to watch.

Here is corrected setting of the very same scene: enter image description here

The last keyframe has been set based on the first one (but results more or less in the same camera rotation as in the initial "bad" case). The middle keyframe has been deleted. In the initial case this middle keyframe had been added in order to compensate for unwanted camera rotation, which has not really been successful. The change in the rotation (meaning rolling or banking) of the camera in case of this corrected setup is absolutely smooth.

Finally, here some rules of thumb that should be considered when implementing more complex camera movements resp. rotations with this method:

  1. Make use of as less as possible keyframes for positioning the camera and camera target on their paths as well as for rotating the camera target and hence the camera itself. The more keyframes there are, the less fluid the result will be.
  2. The camera target can be rotated as done normally (i.e. by pressing "R" in the camera view and then moving the mouse around). But the graph editor should always be checked. In case there are larger changes in the angles to the previous/next keyframe although the supposed change should be rather small, either rotate the target further until a better constellation has been found. Alternatively move the individual angles manually closer to the ones of the neighboring keyframe.
  3. In most cases there shouldn't be any sharp edges resp. corners on the graphs. If there are some, use the keyframe handles to smooth them out or slightly reposition the keyframes.
$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .