Camera animation not smooth when switching camera move styles

23 October 2015 18:29

This does work but instantly rotates the camera to the old pivot.

////////some statements inbetween////////////
var old_pivot = _cam_anim.current_target;
m_cam.set_pivot(camobj, old_pivot);

If I understand you correctly, you call set_pivot with old pivot variable.
m_cam.set_pivot(camobj, old_pivot);

And the camera rotates to the old pivot. Does _cam_anim.current_target contain old pivot?

The next code doesn't work:

////////some statements inbetween////////////
var old_pivot = m_cam.get_pivot(camobj, _cam_anim.current_target); //No error but code execution will stop
m_cam.set_pivot(camobj, old_pivot);

Only the target camera has got the "pivot" property.
24 October 2015 01:07
_cam_anim.current_target contains the last known pivot. Once it switches to EYE it will still contain the old pivot thats why it works.

But if EYE camera is used to look, _cam_anim.current_target is an old position/rotation, so it jumps to the old one. I need the new one from the EYE.

I know that only the target camera has got pivot property, but I'm trying to find a way to keep the TARGET camera in the exact same position/rotation as the previous EYE camera

If you look at my demo and use EYE to look around, and then go to Next, you see it jumps to the old pivot.

26 October 2015 12:39
This topic is more about mathematics now as for me
Anyway, in order to solve this task we need to know what kind of behavior is acceptable for us.

I think, one of solutions is to recalculate a new pivot depending on the current camera direction like it is done in the camera.js module inside the set_move_style method:

var cam_eye = m_cam.get_eye(camobj, _vec3_tmp);
var view_vector = m_util.quat_to_dir(cam_quat, m_util.AXIS_MY,_vec3_tmp);
var pivot = m_vec3.scaleAndAdd(cam_eye, view_vector, PIVOT_DEFAULT_DIST, view_vector);
m_cam.set_pivot(camobj, pivot);

Where PIVOT_DEFAUL_DIST is set to 10 by default. You can play with this value in order to get the best result. I would start from something like 100 meters. This way, we'll really get something like pivot from the EYE camera.

[EDIT] Removed internal properties usage from the code.
26 October 2015 16:57
Dear Evgeny,

Thanks for the help. I have inserted your block of code and I didn't know what to put instead of cam_quat, so I looked in the cam_anim js file and it used m_transform.get_rotation(camobj). So now my code looks like this:

function target_camera_action(){

var camobj = m_scenes.get_active_camera();
var old_pivot = _cam_anim.current_target;;

console.log("was eye cam");
var cam_eye = m_cam.get_eye(camobj, _vec3_tmp);
var view_vector = m_util.quat_to_dir(m_transform.get_rotation(camobj), m_util.AXIS_MY,_vec3_tmp);
old_pivot = m_vec3.scaleAndAdd(cam_eye, view_vector, 900, view_vector);
} else {
console.log("was target cam");
old_pivot = _cam_anim.current_target;


m_cam.set_pivot(camobj, old_pivot);

I started with 100 as you recommended, but that didn't seem enough. I tried 100.000 and that was close to the real thing, but still not as smooth. Once you take over the camera, the pivot will be as far as 100.000 away. This is kindof a problem for me.

So I tried 900. It is still way better as before your code, but still not perfect. The target is still sort of too far away, but it is reasonable.

I understand that it is the recalculated pivot distance that causes this to happen. Would there be any solution to the pivot being too far away once you take over the camera?

Thanks again
27 October 2015 11:07
Well. This sort of things is kinda a matter of taste. I can't say for sure which camera movement is good in your case and which is not. It is needed to have a real scene and make some experiments with it.

Anyway, whenever you switch to the other control style, this would require some setup.

Maybe, it would be okay to determine some pivot distance that would be good for when you switch to the TARGET type. You can store the last distance to the pivot as we have done with pivot location previously and assign it instead of predefined value.

Maybe, this kind of animation is better to be divided into two parts. For example: 1) rotational one if camera is facing the opposite to the final destination direction 2) moving+rotation which is what you have right now. But I don't really like this method because it gives even more complexity.

So, there is no universal recipe for this but I hope my suggestions will help you somehow.
29 October 2015 18:57
I'm working on another project atm, but will continue later with this project.

So once I work on it again I will try your suggestions and let you know.

Thanks for everything!
29 October 2015 21:53
Yep, the camera subsystem is one of the hardest to understand and sophisticated parts of our engine. We are constantly improving the situation though.
Please register or log in to leave a reply.