Jump to content

Depth of field, camera movement and FOV unwanted movements between keypoints

Recommended Posts


As the title says, I'm having multiple issues with jamme but I have a feeling the origin of the issues is the same. Let me start with DOF. 

Let's say I want the dof focus point to be on something for a few seconds, then quickly (about 0.5 secs) switch focus to something else. I place a dof keypoint with the focus point on the first object, then I place a second dof keypoint 2 seconds later with the same focus point, and then a third dof keypoint 0.5 secs after the second keypoint with focus on the second object. You'd think the focus would stay on the first object for 2 seconds then make a quick transition to the second object in those last 0.5 seconds. But instead it makes a weird movement in between the first 2 keypoints, it starts to move in the opposite direction, before reaching the second keypoint and then changing focus to the last keypoint. 

This is test footage to showcase my problem. In this example I have the first keypoint at 1:10.00 with focus on the cup, second keypoint at 1:12.000 with focus on the cup (so it shouldn't have moved at all) and the third keypoint at 1:12.500 with dof focus on the player in the back. Watch what happens:


I can sort of fix this by placing a ton of keypoints in between the first 2 keypoints, all with the same focus point. For example another one at 1:11.000, then 1:11.500, then 1:11.750 and then 1:11.875. This is the result:


With this fix, the issue can't be noticed in the final render. But this solution isn't perfect. Is there a way to truly fix this?

Now onto the camera movements. It's a similar issue.

In the next footage, I'd like the camera to pan down to the planet in 8 seconds. At first I simply placed a keypoint at 8 seconds with a view on space, then another at 16 seconds with view on the planet. This makes a pretty smooth pan down on the planet. But I thought it would look better if it started the movement slower, then accelerated a bit, then slowed down a bit for the end. So I placed keypoints at 0:08.000, 0:10.000, 0:14.000 and 0:16.000, making sure I get a slower pan between 8 and 10 seconds, and 14 and 16 seconds. The result is a weird movement, it starts too slow then quickly pans down and the camera also breaks a little during its run:

This problem can be much more accentuated for more complex camera movements. In this last example, the camera doesn't actually move, it simply pans, but it will also occur with camera movements.

The next example is exactly the same issue as the dof one. Let's say I place a keypoint at 8 and 16 seconds, but I want to place a third keypoint at 30 seconds with the exact same position as the 16 seconds keypoint. The result is that the camera strangely moves between the last 2 keypoints to end up in the third keypoint. Of course I can delete this problem by deleting the third keypoint, the camera will simply stay put. But I might want a third keypoint because I want the camera to stay in place for 14 seconds before moving again for example (the result is the same if I place a keypoint at 0:00.000 with the same position as the 8 seconds keypoint). Anyway, watch this example:

It's as if, with dof and camera, if 2 keypoints seperated in time are the same, jamme just wants to keep moving between those two. I get similar results with fov too. 

Any way to fix this?

Thank you so much.


Rostyslav likes this
Link to comment


About the DOF issue. The problem in the interpolation type that is used in DOF. I thought about that issue as well some time ago. It better be using linear interpolation instead of spline.


In example above 1 is a current way with green highlights of the issues where the current interpolation system before speeding up has to slow down but it usually happens with time diff between key points is small.

2 is a manual fix where you add extra neighbor key points with the same value and negate jumps of acceleration/decceleration.

3 is a proper way with linear interpolation. It's not smooth but it won't be noticed much in DOF I think. I need to add that option.

About the camera issue.

Your guess in using those times in key frames are correct. The problem is in the interpolation again. ?

Camera rotation itself is smooth using quaternion interpolation but the issue is it uses linear interpolation for time so when rotating from key point 1 to key point 2 it goes by one precalculated speed, then another precalculated speed for key points 2 and 3 and so on.

The solution is using mov_smoothQuat, set 1 (or higher for higher precision, over 100 it eats much CPU for me) then it will also add some interpolation for time and you should see some accelerations and decelerations.

For the last issue either add the neighbor points as described above or use linear interpolation for camera rotation - it exists fortunately. Enabled by using command camera smoothAngles 0.

Good luck.

Rostyslav likes this
Link to comment

So if I understand that dof image correctly, x is time and y is the focus point? Also, that means the manual fix is the only way to do it right now, so my own manual fix in the second video is how you would do it yourself?

As for the camera, I tried quaternion interpolation with smoothquat and I can see that the rotation itself gets smoother, but I get very noticeable screen tearing with mov_smoothquat enabled (any value). I've noticed that the tearing is lessened the more keypoints I have. For example if I have clip with a constant movement for 8 seconds with keypoints at 8 and 10 seconds, then 14 and 16 seconds, there is suddenly much more tearing between 10 and 14 seconds. With only two keypoints at 8 and 16 seconds, the tearing is so important that it's unwatchable. Why does that happen? It makes me not want to use it at all because I know there's always gonna be some tearing artifacts in the image even if I put a lot of keypoints. 

Thanks a lot, I'm getting a much better grasp of how the different interpolations work and which to use when. 

Link to comment

About DOF:


Black - time line, gray - desired time, imaginary vertical axis is DOF values, red - key points and interpolated path.

If you want to have certain DOF value at gray time then you have to add 2 key points a bit before and 2 key points a bit after the desired time.

Key points 2 key points before and after will normalize value between 2 and 3 key points (as you see it is linear and the value doesn't change).

Make time between those helper key points short.

For now that's the only way to have the exact DOF value at exact time.

About the tearing: is your camera position static and only angles change or your camera moved a bit? If it's moved then yes there is a problem with the tearing. Either don't move camera (just rotate) or make movements on higher distances.

Btw, there is also a tricky way to set angles key points, position key points and fov key points separately of each other. If you are interested in that I can explain how to do that.

I added a fix for that in q3mme but not in jaMME - need to move that code to jaMME as well. If your camera doesn't move then I have no idea what's wrong.

Link to comment
  • 2 weeks later...

Thanks for further explaining DOF, I got it right now and that manual fix is working good.

About the issue of smoothquat, I used the wrong word before when I typed "screen tearing". Actually, the movement is stuttering, heavily. Let me clarify that as well, the camera is not actually moving, it's the angles that change. The effect is less noticeable between 2 keypoints if they're close to each other. Watch this first example (key points at 8:00, 10:00, 14:00, 16:00, the movement gets less smooth between 10 and 14):

If you can't really see the issue there, it gets a lot worse if keypoints are far apart, watch this (here, only 2 kepoints, at 8:00 and 16:00):

In these 2 examples, I have smoothangles at 1 (quaternion I think it is)

And I would absolutely love to learn about the tricky way you are talking about for keypoints, anything that can help me make a better video.

Link to comment
On 11/20/2019 at 1:46 AM, Cor said:

About the issue of smoothquat, I used the wrong word before when I typed "screen tearing". Actually, the movement is stuttering, heavily.

I gotcha. And what I said is all you need - set value for mov_smoothQuat to 1 or more. Try value of 100 or 1000.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...