# Changing "look at" target of a camera

This topic is 4457 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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 on other sites
Quote:
 Original post by fatihtolgaataHi,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 on other sites
Quote:
 Original post by jykforward = 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 on other sites
Quote:
Original post by fatihtolgaata
Quote:
 Original post by jykforward = 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 on other sites
The second case is called gimbal lock.

##### Share on other sites
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 on other sites
Quote:
 Original post by Rockoon1The 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.

• 10
• 17
• 9
• 13
• 41