Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


math behind gluLookAt


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 stuh505   Members   -  Reputation: 122

Like
0Likes
Like

Posted 26 January 2007 - 06:15 AM

In order to make sure I understand gluLookAt I am trying to recreate the function, as described in the documentation here (http://pyopengl.sourceforge.net/documentation/manual/gluLookAt.3G.html). However, following the exact internal representation described, I am getting a very different outcome. To make things simple I have used the same var names as used in the documentation. UP = {upX, upY, upZ} UP' = normalized UP F = centerXYZ - eyeXYZ = look direction f = look direction (normalized) s = f x UP' = right direction u = s x f = view up direction Then I fill out the matrix exactly as specified in the doc. I could put the translations in here too but I'm just doing it the way they say first eg, "and gluLookAt is equivalent to glMultMatrixf(M); glTranslated (-eyex, -eyey, -eyez);"
void my_gluLookAt(float eyeX, float eyeY, float eyeZ, float centerX, float centerY, float centerZ, float upX, float upY, float upZ)
{
	float f[3] = {centerX-eyeX, 
				  centerY-eyeY, 
				  centerZ-eyeZ};
	vecNormalize(f);
	
	float up[3] = {upX, upY, upZ};
	vecNormalize(up);

	float s[3], u[3];
	crossProduct(f, up, s);
	crossProduct(s,f,u);

	float M[16]={s[0], s[1], s[2], 0,
				u[0], u[1], u[2], 0,
				-f[0], -f[1], -f[2], 0,
				0, 0, 0, 1 };
	glMultMatrixf(M);
	glTranslatef(-eyeX, -eyeY, -eyeZ);
}
Same params to call:
//gluLookAt(	0,0,0,	0, 1, 0,	0, 0, 1 );
my_gluLookAt(	0,0,0,	0, 1, 0,	0, 0, 1 );
There are no bugs within crossProduct or vecNormalize funcs. I have verified that s,u,f all have the correct values when going into the matrix M, and that M also has the correct values...

Sponsor:

#2 songho   Members   -  Reputation: 268

Like
0Likes
Like

Posted 26 January 2007 - 06:41 AM

I notice 2 things; OpenGL uses column major matrix notation, so the matrix elements looks like this;
M[0] = s[0];
M[4] = s[1];
M[8] = s[2];

Second, normalize side and up vector after cross-product;
crossProduct(f, up, s);
vecNormalize(s);
crossProduct(s,f,u);
vecNormalize(u);


#3 stuh505   Members   -  Reputation: 122

Like
0Likes
Like

Posted 26 January 2007 - 07:00 AM

Quote:
I notice 2 things; OpenGL uses column major matrix notation, so the matrix elements looks like this;


Yes, that is how the matrix is defined in the documentation I linked to.

Quote:
Second, normalize side and up vector after cross-product;


I think in general you're right cross product does not preserve length, although it doesn't affect these specific vectors.

#4 Sneftel   Senior Moderators   -  Reputation: 1781

Like
0Likes
Like

Posted 26 January 2007 - 07:05 AM

Quote:
Original post by stuh505
Yes, that is how the matrix is defined in the documentation I linked to.

Right. Yet that's not how you're doing it. You're putting the elements of s in M[0], M[1], and M[2], not M[0], M[4], and M[8].

#5 stuh505   Members   -  Reputation: 122

Like
0Likes
Like

Posted 26 January 2007 - 07:19 AM

Thank you, I see now.

[Edited by - stuh505 on January 26, 2007 3:19:39 PM]

#6 Excors   Members   -  Reputation: 715

Like
0Likes
Like

Posted 27 January 2007 - 01:13 PM

Quote:
Original post by stuh505
Quote:
Second, normalize side and up vector after cross-product;


I think in general you're right cross product does not preserve length, although it doesn't affect these specific vectors.

It does affect these vectors - f×UP' won't be unit length unless f and UP' are perpendicular (which they usually aren't), and s×f won't be either, so you won't get an orthogonal matrix, and the results are visually wrong (or at least they were when I tried it a while ago). Mesa normalises the s and u vectors after the crosses, and the OpenGL man pages appear to just be wrong.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS