Sign in to follow this  
fatihtolgaata

Changing "look at" target of a camera

Recommended Posts

fatihtolgaata    122
Hi, I implemented a camera that have 3 vectors. These vectors are Look, Right and Up vectors. I can calculate the ViewMatrix from these vectors. I want to set camera's view to a position. I have only a position that is a 3d vector. I must set camera's target to this specific position. But how? regards

Share this post


Link to post
Share on other sites
jyk    2094
Quote:
Original post by fatihtolgaata
Hi,
I implemented a camera that have 3 vectors. These vectors are Look, Right and Up vectors. I can calculate the ViewMatrix from these vectors. I want to set camera's view to a position. I have only a position that is a 3d vector. I must set camera's target to this specific position. But how?
It sounds like you basically want to do manually what functions like gluLookAt() do. Typically this is done using a reference vector, otherwise there isn't a unique orientation that will aim one object at another. Another option is to apply a rotation to the object such that it aims at a target; this is most applicable if you're doing incremental rotations in a 6DOF environment, like a space sim.

You're probably after the 'look at' solution though. Here's how it's typically done:
forward = normalize(target - position);
side = normalize(cross(referenceUp,forward));
up = cross(forward,side);
Note that this has a couple of failure cases, and also that some implementations negate the forward axis to account for -z forward in view space (i.e. OpenGL). Additionally, the gluLookAt() function takes the inverse of the matrix so that it can function as a view matrix, but it sounds like you have that covered elsewhere.

Share this post


Link to post
Share on other sites
fatihtolgaata    122
Quote:
Original post by jyk
forward = normalize(target - position);
side = normalize(cross(referenceUp,forward));
up = cross(forward,side);


thanks a lot, it has worked very well for now. if any unexpected result will occur in the future, I'll be in here :) thanks again.

Share this post


Link to post
Share on other sites
jyk    2094
Quote:
Original post by fatihtolgaata
Quote:
Original post by jyk
forward = normalize(target - position);
side = normalize(cross(referenceUp,forward));
up = cross(forward,side);


thanks a lot, it has worked very well for now. if any unexpected result will occur in the future, I'll be in here :)
It should always work unless target and position are the same or nearly the same, or target - position is aligned or nearly aligned with referenceUp. The first case can usually be ignored, assuming you have some collision detection and response in place. Whether the second case is a potential problem depends on the nature of your simulation. In any case, it will not be something that happens often.

Share this post


Link to post
Share on other sites
someusername    427
Quote:

The second case is called gimbal lock.


The problem arising in the 2nd case mentioned by jyk, comes from the fact that two vectors tend to become colinear. (direction and "global up")
Since three points are needed to define a plane (the common head and the two tails of those vectors), when they begin to coincide, it becomes impossible to define a unique direction perpendicular to them, since -now- there's a whole plane normal to them.

Gimbal lock arises in orientations, where the final rotation constitutes of three seperate ones (X/Y/Z) performed "on top" of each other. This makes it possible for the axis of one of them, to coincide with a previous one.
If you rotate all axes with constant speed, it's almost certain that one of them will behave erratically and the model's rotation will generally seem unnatural and unpredictable.
Generally one has to make sure that they're rotating the model around three mutually perpendicular vectors. Else you'll get gimbal lock; it's a matter of time...

Share this post


Link to post
Share on other sites
jyk    2094
Quote:
Original post by Rockoon1
The second case is called gimbal lock.
Nope, it's not gimbal lock (as someusername already pointed out). It's simply a degenerate case in which the 'aim at' algorithm can't construct a unique orientation.

Share this post


Link to post
Share on other sites

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

Sign in to follow this