ttencate

11-18-2008, 11:00 AM

Today, I tried to replicate the behaviour of gluLookAt in my own code. I simply used the equations that are specified in the documentation page:

http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/glu/lookat.html

or here for a more readable version with the same problem:

http://pyopengl.sourceforge.net/documentation/manual/gluLookAt.3G.html

The algorithm works as follows. First, a front vector (f) is computed, which is a unit length vector from the eye to the scene centre. Then a side vector (s) is computed as the cross product between the normalized up vector (UP') and the unit-length front vector (f).

The side vector (s) does not necessarily have unit length, because the up vector passed to gluLookAt (UP) is not necessarily perpendicular to the front vector (f). In the MesaLib code, therefore, the side vector is normalized:

/* Side = forward x up */

cross(forward, up, side);

normalize(side);

However, the documentation does not mention this, and pretends that an unnormalized side vector is put into the resulting matrix (M)!

It is not just a difference in Mesa's implementation, because the implementation on my Windows system (nVidia's? Microsoft's?) also normalizes the side vector.

I'm posting here for two reasons:

1. Can you help me verify that my analysis is correct?

2. Does anyone know how I get this documentation bug reported?

http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/glu/lookat.html

or here for a more readable version with the same problem:

http://pyopengl.sourceforge.net/documentation/manual/gluLookAt.3G.html

The algorithm works as follows. First, a front vector (f) is computed, which is a unit length vector from the eye to the scene centre. Then a side vector (s) is computed as the cross product between the normalized up vector (UP') and the unit-length front vector (f).

The side vector (s) does not necessarily have unit length, because the up vector passed to gluLookAt (UP) is not necessarily perpendicular to the front vector (f). In the MesaLib code, therefore, the side vector is normalized:

/* Side = forward x up */

cross(forward, up, side);

normalize(side);

However, the documentation does not mention this, and pretends that an unnormalized side vector is put into the resulting matrix (M)!

It is not just a difference in Mesa's implementation, because the implementation on my Windows system (nVidia's? Microsoft's?) also normalizes the side vector.

I'm posting here for two reasons:

1. Can you help me verify that my analysis is correct?

2. Does anyone know how I get this documentation bug reported?