07-02-2003, 10:01 PM

What better(faster):gluLookat or glTranslate/Rotate?

View Full Version : What better(faster):gluLookat or glTranslate/Rotate?

07-02-2003, 10:01 PM

What better(faster):gluLookat or glTranslate/Rotate?

Mazy

07-02-2003, 10:24 PM

Since i bet you only will call it a few times per frame it doesnt matter.. Put your energy on more practical optimizations.

and the correct answer : depends on the number of rotate/translate you have to do http://www.opengl.org/discussion_boards/ubb/smile.gif

/Mazy

and the correct answer : depends on the number of rotate/translate you have to do http://www.opengl.org/discussion_boards/ubb/smile.gif

/Mazy

Orzech

07-04-2003, 07:10 AM

If you are trying to make something like 'camera' take gluLookAt. It makes your code simpler and work good so many people use it (even in professional applications).

It also depends of what your are doing really. There are some uses where glTranslate/glRotate would be more suitable.

To make it fastest (IMHO) - if your camera is very simple you don't have to use gluLookAt (it would work faster). In other case use it.

Orzech

It also depends of what your are doing really. There are some uses where glTranslate/glRotate would be more suitable.

To make it fastest (IMHO) - if your camera is very simple you don't have to use gluLookAt (it would work faster). In other case use it.

Orzech

Mihail121

07-05-2003, 02:56 AM

As long as u guys use the GLU junk functions or use stuff like glTranslate/Rotate etc instead of own ma3x ops you will probably stay in the beginners forum

Orzech

07-05-2003, 10:49 AM

Originally posted by Mihail121:

As long as u guys use the GLU junk functions or use stuff like glTranslate/Rotate etc instead of own ma3x ops you will probably stay in the beginners forum

So why are you here if you are in 'advanced forum', my guru?

I think there is no need of writing your own matrix operations - of course you can do it that way but in many programs there is no need of complicating your code. OpenGL commands works ok and you can fell free to use them.

As long as u guys use the GLU junk functions or use stuff like glTranslate/Rotate etc instead of own ma3x ops you will probably stay in the beginners forum

So why are you here if you are in 'advanced forum', my guru?

I think there is no need of writing your own matrix operations - of course you can do it that way but in many programs there is no need of complicating your code. OpenGL commands works ok and you can fell free to use them.

miko

07-06-2003, 01:16 PM

Originally posted by Mihail121:

As long as u guys use the GLU junk functions or use stuff like glTranslate/Rotate etc instead of own ma3x ops you will probably stay in the beginners forum

interesting... but i actually don't see any reason why should i do transormation myself when driver does the job cool (and i think my routine as well as routine downloaded from some abandoned site will never employ some hardware acceleration - such as 3dnow!)...

As long as u guys use the GLU junk functions or use stuff like glTranslate/Rotate etc instead of own ma3x ops you will probably stay in the beginners forum

interesting... but i actually don't see any reason why should i do transormation myself when driver does the job cool (and i think my routine as well as routine downloaded from some abandoned site will never employ some hardware acceleration - such as 3dnow!)...

yaro_dup1

07-07-2003, 01:21 AM

Does gluLookAt is created with glTranslate and glRotate???

john

07-07-2003, 02:11 AM

Does gluLookAt is created with glTranslate and glRotate???

well, that's ... the first answer is "no", but that might not be true. The way it computes rotations are almost certainly never done with glRotate: it probably exploits the trick of building an orthonormal matrix by computing directional vectors and building the rotation directly. It ~could~ use glTranslate to translate the camera, but since its building a 4x4 matrix and uploading it to opengl anyway, it may as well modify the 4th column itself, too.

so, the short answer is still "no".

well, that's ... the first answer is "no", but that might not be true. The way it computes rotations are almost certainly never done with glRotate: it probably exploits the trick of building an orthonormal matrix by computing directional vectors and building the rotation directly. It ~could~ use glTranslate to translate the camera, but since its building a 4x4 matrix and uploading it to opengl anyway, it may as well modify the 4th column itself, too.

so, the short answer is still "no".

KineticBytes

07-07-2003, 02:11 AM

As long as u guys use the GLU junk functions or use stuff like glTranslate/Rotate etc instead of own ma3x ops you will probably stay in the beginners forum.

So why do you think your own matrix functions will be beter/faster? I think that you should use the gl functions because these could take advantage of a fast GPU while your functions will be done on the CPU.

I could be wrong here...

Unless you're writing Cg shaders or something I think it's a wast of time to write your own matrix functions since they will do the same thing the gl functins do and may even be slower...

If you write a Cg shader you must write your own matrix functions.

However, I don't think it is a waste of effort to implement your own lighting model if opengl's model does not cut it for you.

But, you should do this with hardware shaders if possible, because a GPU can do this alot faster than a CPU ever can.

So why do you think your own matrix functions will be beter/faster? I think that you should use the gl functions because these could take advantage of a fast GPU while your functions will be done on the CPU.

I could be wrong here...

Unless you're writing Cg shaders or something I think it's a wast of time to write your own matrix functions since they will do the same thing the gl functins do and may even be slower...

If you write a Cg shader you must write your own matrix functions.

However, I don't think it is a waste of effort to implement your own lighting model if opengl's model does not cut it for you.

But, you should do this with hardware shaders if possible, because a GPU can do this alot faster than a CPU ever can.

07-07-2003, 02:34 AM

I think that if we use gluLookat we do next steps:

1. Calculate position of camera

2. Calculate position of target

3. Calculate position of up vector

4. Let OpenGL calculate matrix using previous data.

If we use glTranlate/Rotate we only let OpenGL calculate matrix. Doesn't it faster?

1. Calculate position of camera

2. Calculate position of target

3. Calculate position of up vector

4. Let OpenGL calculate matrix using previous data.

If we use glTranlate/Rotate we only let OpenGL calculate matrix. Doesn't it faster?

Mihail121

07-07-2003, 02:39 AM

Yeah i want to say sorry.I'm now respected and will go tell all gamedev companies to stop using own ma3x ops and start using glTranslate/glRotate etc.It's just a bit intresting how they haven't thought of that yet.Perhaps they're dumm!

Mazy

07-07-2003, 03:01 AM

GluLookAt wont be accelerated by the gpu, neither by 3dnow and similar, since its a pretty old library, and since it doenst talk to the cards driver directly, only through the gl library the math involved in gluLookAt just creates a matrix with the CPU you wont benefit of the fact that some expensive cards might do glRotate and glTranslate in HW, but thats besides the point if youre just making a camera, since that probably never will affect the speed if your program ( unless you move the camera several thousands times per frame http://www.opengl.org/discussion_boards/ubb/smile.gif you can use for a easy camera implementation.

Mihail121 : just becourse own matrix routines are good for games, and servral other applications doesnt mean that glTranslate and glRotate are useless.. i bet many proffesional programs uses them , especially if you show objects, not entire worlds, and you know that your target gfxcard implement the whole matrixpipeline in HW..

Mihail121 : just becourse own matrix routines are good for games, and servral other applications doesnt mean that glTranslate and glRotate are useless.. i bet many proffesional programs uses them , especially if you show objects, not entire worlds, and you know that your target gfxcard implement the whole matrixpipeline in HW..

Deiussum

07-07-2003, 04:39 AM

Originally posted by Mihail121:

As long as u guys use the GLU junk functions or use stuff like glTranslate/Rotate etc instead of own ma3x ops you will probably stay in the beginners forum

It's attitudes like this that made me stop following the advanced forum, though I consider myself to having enough understanding of OpenGL to follow the threads there. Now I am content to just follow the beginner's forum and help people out occasionally.

As long as u guys use the GLU junk functions or use stuff like glTranslate/Rotate etc instead of own ma3x ops you will probably stay in the beginners forum

It's attitudes like this that made me stop following the advanced forum, though I consider myself to having enough understanding of OpenGL to follow the threads there. Now I am content to just follow the beginner's forum and help people out occasionally.

KineticBytes

07-07-2003, 05:49 AM

Yeah i want to say sorry.I'm now respected and will go tell all gamedev companies to stop using own ma3x ops and start using glTranslate/glRotate etc.It's just a bit intresting how they haven't thought of that yet.Perhaps they're dumm!

This is even more of a dumb answer.

OK I'm a beginner, and I'm sertainly NOT afraid of admitting it. Maybe, (instead of telling us this crap) you could tell us why not to use glRotate etc. That would be alot more usefull to us. Else I suggest you just shutup and go over to the 'advanced forum' since we're not good enough for ya'll!!

Like you never where a beginner. Pfff... get a life.

This is even more of a dumb answer.

OK I'm a beginner, and I'm sertainly NOT afraid of admitting it. Maybe, (instead of telling us this crap) you could tell us why not to use glRotate etc. That would be alot more usefull to us. Else I suggest you just shutup and go over to the 'advanced forum' since we're not good enough for ya'll!!

Like you never where a beginner. Pfff... get a life.

starman

07-07-2003, 09:10 AM

"Originally posted by Mihail121:

As long as u guys use the GLU junk functions or use stuff like glTranslate/Rotate etc instead of own ma3x ops you will probably stay in the beginners forum"

Why stop at transformation matrices? Implement your own lighting, texture mapping, blending, etc. and you won't need to rely on something as childish as OpenGL. And you're not using a baby training wheel programming language like C or C++, are you? Real men use assembler. Anyone else is a rank beginner. But you probably already know this, right?

[This message has been edited by starman (edited 07-07-2003).]

As long as u guys use the GLU junk functions or use stuff like glTranslate/Rotate etc instead of own ma3x ops you will probably stay in the beginners forum"

Why stop at transformation matrices? Implement your own lighting, texture mapping, blending, etc. and you won't need to rely on something as childish as OpenGL. And you're not using a baby training wheel programming language like C or C++, are you? Real men use assembler. Anyone else is a rank beginner. But you probably already know this, right?

[This message has been edited by starman (edited 07-07-2003).]

Jormungand

07-07-2003, 09:35 AM

Yeah starman is right! Why should we even bother learning OpenGL in the first place?

We should start reinventing the wheel and write our own graphics libraries because OpenGL's old functions suck! Never ever use them or you will be a newbie for life! You will never get to post anything in the 'advanced' forum and yuo will never be respected. So, go to whatever online book store and look fore those hardcore computer graphics books, you'll need them.

Of yeah, and while you're doing that, don't forget to contact nVidia and ATI to get documentation about how to writeyou own driver for these cards. You would want your library to be hardware accelerated right?

But I'm afraid nVidia or ATI won't give you that information so you're stuck here.

Wait maybe there is some hope left. Maybe you could convince some very very rich guy into investing into a new hardware company and design your own graphics processors!!!

Why didn't I think of this earlier!

Sarcasm once in a while never hurts right :-)

We should start reinventing the wheel and write our own graphics libraries because OpenGL's old functions suck! Never ever use them or you will be a newbie for life! You will never get to post anything in the 'advanced' forum and yuo will never be respected. So, go to whatever online book store and look fore those hardcore computer graphics books, you'll need them.

Of yeah, and while you're doing that, don't forget to contact nVidia and ATI to get documentation about how to writeyou own driver for these cards. You would want your library to be hardware accelerated right?

But I'm afraid nVidia or ATI won't give you that information so you're stuck here.

Wait maybe there is some hope left. Maybe you could convince some very very rich guy into investing into a new hardware company and design your own graphics processors!!!

Why didn't I think of this earlier!

Sarcasm once in a while never hurts right :-)

starman

07-07-2003, 10:13 AM

Design your own graphics processor? You wimp! I suppose you're going to re-use ready made silicon molecules instead of sythesizing your own. In my day...

Orzech

07-07-2003, 11:16 AM

Why shall we build our own graphics processor if we can build a whole computer! Good idea, isn't it? And then, meaby, after writing our own system and graphics library we can call ourselfs 'newbies in advanced forum'...

gumby

07-07-2003, 12:13 PM

Using glRotate/Translate is fine until the point that you find yourself needing the matrix, and using glGet... For instance, camera look vector can be useful. Having the full transformation matrix may be useful if you do any collision detection (on the CPU). At this point you might as well keep your matrices and glLoad/Mult them.

starman

07-07-2003, 12:22 PM

"Using glRotate/Translate is fine until the point that you find yourself needing the matrix, and using glGet... For instance, camera look vector can be useful. Having the full transformation matrix may be useful if you do any collision detection (on the CPU). At this point you might as well keep your matrices and glLoad/Mult them."

Agreed. We're just reacting (over?) to Mihail's condescending attitude.

Agreed. We're just reacting (over?) to Mihail's condescending attitude.

starman

07-07-2003, 12:24 PM

Plus, keeping your own matrices will also make your code more portable if you ever move away from OpenGL (perish the thought). Of course, you may have to transpose your matrices if you use something else.

07-07-2003, 01:49 PM

Wow, a troll in the OpenGL forum; now I have seen everything.

Don't get me wrong, I think the world needs alot more high school age script kiddies who have nothing better to do with their time.

Especially such a masterful OpenGL god as the author of these posts: http://www.opengl.org/discussion_boards/ubb/Forum2/HTML/010467.html (No comment) http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/009016.html (Advanced OGL...? This isn't even advanced programming!)

I've also noticed you use GLUT. Haha, if you're going to bash GLU, why use the library that completely abstracts the main program away from you?

He's right though. Along those same lines, why should we even bother going to the gas station to get gasoline when we can be leet and go to an oil rig and pump the crude out ourselves, take it to the refinery and crack our own fuel. /me rolls eyes

Now to answer the original question: Use what works. gluLookat certainly makes things easy. But if you find it's draining your performance when it comes time to optimize, then look into a better solution.

Don't get me wrong, I think the world needs alot more high school age script kiddies who have nothing better to do with their time.

Especially such a masterful OpenGL god as the author of these posts: http://www.opengl.org/discussion_boards/ubb/Forum2/HTML/010467.html (No comment) http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/009016.html (Advanced OGL...? This isn't even advanced programming!)

I've also noticed you use GLUT. Haha, if you're going to bash GLU, why use the library that completely abstracts the main program away from you?

He's right though. Along those same lines, why should we even bother going to the gas station to get gasoline when we can be leet and go to an oil rig and pump the crude out ourselves, take it to the refinery and crack our own fuel. /me rolls eyes

Now to answer the original question: Use what works. gluLookat certainly makes things easy. But if you find it's draining your performance when it comes time to optimize, then look into a better solution.

Jormungand

07-07-2003, 11:23 PM

Well Gumby, at least you give a usefull answer. Now it makes alot more sence to me.

If the other guy (I don't remember his name) told us this instead of that 'advanced' forum crap we would not have reacted that way. Thanx again for your answer.

I don't know but, if talking about a nVidia driver cheat in 3D mark 2003 is an advanced topic then what the hell am I even doing in the beginners forum. I should head over there and be 'advanced' http://www.opengl.org/discussion_boards/ubb/wink.gif

If the other guy (I don't remember his name) told us this instead of that 'advanced' forum crap we would not have reacted that way. Thanx again for your answer.

I don't know but, if talking about a nVidia driver cheat in 3D mark 2003 is an advanced topic then what the hell am I even doing in the beginners forum. I should head over there and be 'advanced' http://www.opengl.org/discussion_boards/ubb/wink.gif

Jormungand

07-07-2003, 11:34 PM

Especially such a masterful OpenGL god as the author of these posts: http://www.opengl.org/discussion_boards/ubb/Forum2/HTML/010467.html (No comment) http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/009016.html (Advanced OGL...? This isn't even advanced programming!)

Oh My God, I almost died from laughing!

Goddamned never post something like this anymore, you want me to die or something? http://www.opengl.org/discussion_boards/ubb/wink.gif

Oh My God, I almost died from laughing!

Goddamned never post something like this anymore, you want me to die or something? http://www.opengl.org/discussion_boards/ubb/wink.gif

07-08-2003, 12:22 AM

Thank's for all replies. It was interesting. But returning the basic question i thing that i need information about low level calculations mechanism that use opengl to undarstand what faster in different cases.

starman

07-08-2003, 02:00 AM

"But returning the basic question i thing that i need information about low level calculations mechanism that use opengl to undarstand what faster in different cases."

Why? Use gluLookAt() and run your program. If it performs OK, stop. If not, *profile* it to see where the bottlenecks are. More than likely they're not in OpenGL code anyway. Once you've found the bottleneck, tweak your code to fix it.

Try to resist the urge to prematurely optimize.

Why? Use gluLookAt() and run your program. If it performs OK, stop. If not, *profile* it to see where the bottlenecks are. More than likely they're not in OpenGL code anyway. Once you've found the bottleneck, tweak your code to fix it.

Try to resist the urge to prematurely optimize.

DJSnow

07-08-2003, 02:12 AM

to make something clear:

the most people are switching from gluLookAt() for leaving the linkage with glu.lib,

because this needs one dll more, on which your program depends on...

the most people are switching from gluLookAt() for leaving the linkage with glu.lib,

because this needs one dll more, on which your program depends on...

john

07-08-2003, 02:12 AM

returning swiftly to topic:

I think that if we use gluLookat we do next steps:

1. Calculate position of camera

2. Calculate position of target

3. Calculate position of up vector

4. Let OpenGL calculate matrix using previous data.

If we use glTranlate/Rotate we only let OpenGL calculate matrix. Doesn't it faster?

well, it all comes down to HOW you compute the matrix. I'll explain how gluLookAt works to try and illustrate why its easy enough just to build the matrix.

but, hold the thoughts on gluLookAt for a moment and consider this intereting trick with rotation matricies.

OpenGL uses 4x4 matricies to represent transformations in homogeneous coordinates. Certain parts of this 4x4 matrix effectively do different things because of the way they modify incoming verticies. Keep in mind that the matricies map one space to another space (but the identity matrix maps the space to itself: ie. there is no change).

The upper 3x3 sub-matrix represents the orientation and scale of the axis and the fourth column represents the remapped position. I want to focus on the upper 3x3 matrix for most of my discussion. Its interesting property is that you can directectly get back the three vectors that span the space. What spanning a space means is that you can get any vector in three-space by linear combinations of the basis, or spanning vectors.

An example of this is the identity matrix, which has an upper 3x3 of

1 0 0

0 1 0

0 0 1

if we take the three column vectors we have [1 0 0] (the first column), [0 1 0] (the second) and [0 0 1]. Now, think of any three-dimensional point... say, <1 2 3>. this can be represented as a linear combination of these three vectors, namely

<1 2 3> := 1 * <1 0 0> + 2 * <0 1 0> + 3 * <0 0 1>

we can do this for ANY three-dimensional point, and so we can say that these three vectors span the space. (Side note: its possible to come up with three vectors that don't span the entire space. For example, we could set the third vector to be <0 0 0>, not <0 0 1>... this means the z-dimensional becomes the *null space* of the matrix because its impossible to represent a 3D point with a non-zero z value).

What does this have to do with gluLookAt? Well, the handy trick is that we can directly construct a rotation by figuring out where we want the identity transform to be mapped to.

An example of this is the following. Suppose we want to come up with some rotation/scale matrix that maps the X, Y and Z axises to the vectors A, B and C respectively. that is, we want to move a point such as <1 0 0> (along the x axis) to be some point thats a linear combination of A. So, if A was <1 2 3>, then we want <1 0 0> to 'turn into' <1 2 3>. If you're not clear about that then think about what a transformation is doing. A translation to <1 2 3> says that the point <0, 0, 0> "turns into" <1 2 3>, and all other points are SIMILARLY mapped. Here we're saying we want points along a particular vector to "turn into" points along ANOTHER particular vector. We can directly build this transformation with the matrix

A1 B1 C1

A2 B2 C2

A3 B3 C3

which is a pretty interesting result. How does this affect gluLookAt?

Think about the interface to gluLookAt. You need a camera position, a point the camera is looking at, and a vector to describe the 'up' position.

What we're saying is that we want all points along the Y axis to be mapped to the 'up' vector, and points along the X and Z axis to be mapped to some vectors "sensible" with the position, lookat and sky vectors.

Since the default opengl system treats -z as depth, we can compute the map vector for z as the vector from the position of the camera to the look-at point. That's easy: Z' is just the vector lookat-position. The X' vector is some vector thats orthogonal, or perpendicular to both the Z' and Y' vectors. We can compute that easily by the cross product of Y' and Z'. The cross product of two vectors will give a third vector at right angles to them. The cross product is essentially computing the determinant of a parameterised 3x3 matrix.

So, with one cross product and one vector subtraction we've computed three vectors to represent the rotation we need to build. All we need to do is plug these into the 4x4 matrix like so:

X1' Y1' Z1' p1

X2' Y2' Z2' p2

X3' Y3' Z3' p3

0 0 0 1

where Y' is the sky vector, Z' is lookat-pos, and X' is the cross product of Y' and Z'. the p in the fourth column is the position vector again; it maps the origin to the new position.

SO... why can't this be done directly in opengl? Firstly, because its not necessary as we can build the matrix directly, and secondly because opengl doesn't have an interface for the cross=product. At the end of the day, gluLookAt *isn't* a lot of code and is certainly far from computationally expensive.

I hope this helps.

cheers

John

I think that if we use gluLookat we do next steps:

1. Calculate position of camera

2. Calculate position of target

3. Calculate position of up vector

4. Let OpenGL calculate matrix using previous data.

If we use glTranlate/Rotate we only let OpenGL calculate matrix. Doesn't it faster?

well, it all comes down to HOW you compute the matrix. I'll explain how gluLookAt works to try and illustrate why its easy enough just to build the matrix.

but, hold the thoughts on gluLookAt for a moment and consider this intereting trick with rotation matricies.

OpenGL uses 4x4 matricies to represent transformations in homogeneous coordinates. Certain parts of this 4x4 matrix effectively do different things because of the way they modify incoming verticies. Keep in mind that the matricies map one space to another space (but the identity matrix maps the space to itself: ie. there is no change).

The upper 3x3 sub-matrix represents the orientation and scale of the axis and the fourth column represents the remapped position. I want to focus on the upper 3x3 matrix for most of my discussion. Its interesting property is that you can directectly get back the three vectors that span the space. What spanning a space means is that you can get any vector in three-space by linear combinations of the basis, or spanning vectors.

An example of this is the identity matrix, which has an upper 3x3 of

1 0 0

0 1 0

0 0 1

if we take the three column vectors we have [1 0 0] (the first column), [0 1 0] (the second) and [0 0 1]. Now, think of any three-dimensional point... say, <1 2 3>. this can be represented as a linear combination of these three vectors, namely

<1 2 3> := 1 * <1 0 0> + 2 * <0 1 0> + 3 * <0 0 1>

we can do this for ANY three-dimensional point, and so we can say that these three vectors span the space. (Side note: its possible to come up with three vectors that don't span the entire space. For example, we could set the third vector to be <0 0 0>, not <0 0 1>... this means the z-dimensional becomes the *null space* of the matrix because its impossible to represent a 3D point with a non-zero z value).

What does this have to do with gluLookAt? Well, the handy trick is that we can directly construct a rotation by figuring out where we want the identity transform to be mapped to.

An example of this is the following. Suppose we want to come up with some rotation/scale matrix that maps the X, Y and Z axises to the vectors A, B and C respectively. that is, we want to move a point such as <1 0 0> (along the x axis) to be some point thats a linear combination of A. So, if A was <1 2 3>, then we want <1 0 0> to 'turn into' <1 2 3>. If you're not clear about that then think about what a transformation is doing. A translation to <1 2 3> says that the point <0, 0, 0> "turns into" <1 2 3>, and all other points are SIMILARLY mapped. Here we're saying we want points along a particular vector to "turn into" points along ANOTHER particular vector. We can directly build this transformation with the matrix

A1 B1 C1

A2 B2 C2

A3 B3 C3

which is a pretty interesting result. How does this affect gluLookAt?

Think about the interface to gluLookAt. You need a camera position, a point the camera is looking at, and a vector to describe the 'up' position.

What we're saying is that we want all points along the Y axis to be mapped to the 'up' vector, and points along the X and Z axis to be mapped to some vectors "sensible" with the position, lookat and sky vectors.

Since the default opengl system treats -z as depth, we can compute the map vector for z as the vector from the position of the camera to the look-at point. That's easy: Z' is just the vector lookat-position. The X' vector is some vector thats orthogonal, or perpendicular to both the Z' and Y' vectors. We can compute that easily by the cross product of Y' and Z'. The cross product of two vectors will give a third vector at right angles to them. The cross product is essentially computing the determinant of a parameterised 3x3 matrix.

So, with one cross product and one vector subtraction we've computed three vectors to represent the rotation we need to build. All we need to do is plug these into the 4x4 matrix like so:

X1' Y1' Z1' p1

X2' Y2' Z2' p2

X3' Y3' Z3' p3

0 0 0 1

where Y' is the sky vector, Z' is lookat-pos, and X' is the cross product of Y' and Z'. the p in the fourth column is the position vector again; it maps the origin to the new position.

SO... why can't this be done directly in opengl? Firstly, because its not necessary as we can build the matrix directly, and secondly because opengl doesn't have an interface for the cross=product. At the end of the day, gluLookAt *isn't* a lot of code and is certainly far from computationally expensive.

I hope this helps.

cheers

John

Mazy

07-08-2003, 02:31 AM

DJSnow : that might be true, but isnt glu required to exist in order for the envrinment to be opengl compliant? in that case it really doenst matter if its one or 2 dlls, since if one exist the other must exist too, and in the other case we can say that atleast in windows, its up to date allways shipped toghether with opengl32.dll http://www.opengl.org/discussion_boards/ubb/smile.gif

Jormungand

07-08-2003, 02:38 AM

Well thanx for the math lessons but this stuff I knew from my math books.

Anyhow it's post like this that help the community!

I think we can conclude that it's OK to use gluLookAt() because it's not doing anything heavy. Use it untill you come at a point where it doesn't fit your needs anymore and you have a solid reason of why to write your own routines. When the time comes you will know what to do, and if not then ask here http://www.opengl.org/discussion_boards/ubb/smile.gif

BUT ALWAYS REMEMBER THIS:

Donald Knuth once said:

"We should forget about small efficiencies, about 97% of the time. Premature optimization is the root of all evil."

The critical word is PREMATURE. I'm not against optimization. I'm just against unnecessarily poor software designs that are justified in the name of optimization.

Remember this your whole life!

Anyhow it's post like this that help the community!

I think we can conclude that it's OK to use gluLookAt() because it's not doing anything heavy. Use it untill you come at a point where it doesn't fit your needs anymore and you have a solid reason of why to write your own routines. When the time comes you will know what to do, and if not then ask here http://www.opengl.org/discussion_boards/ubb/smile.gif

BUT ALWAYS REMEMBER THIS:

Donald Knuth once said:

"We should forget about small efficiencies, about 97% of the time. Premature optimization is the root of all evil."

The critical word is PREMATURE. I'm not against optimization. I'm just against unnecessarily poor software designs that are justified in the name of optimization.

Remember this your whole life!

Orzech

07-08-2003, 04:52 AM

Originally posted by NVade:

Especially such a masterful OpenGL god as the author of these posts: http://www.opengl.org/discussion_boards/ubb/Forum2/HTML/010467.html (No comment) http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/009016.html (Advanced OGL...?

Sorry for going off-topic guys but I had to do it : Bravo NVade! http://www.opengl.org/discussion_boards/ubb/smile.gif

Especially such a masterful OpenGL god as the author of these posts: http://www.opengl.org/discussion_boards/ubb/Forum2/HTML/010467.html (No comment) http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/009016.html (Advanced OGL...?

Sorry for going off-topic guys but I had to do it : Bravo NVade! http://www.opengl.org/discussion_boards/ubb/smile.gif

starman

07-08-2003, 09:27 AM

John - Thanks! That's good stuff. I archived a copy of your latest post for future reference. It kind of reminds me of Steve Baker's "Matrices can be your friends" article:

http://www.sjbaker.org/steve/omniv/matrices_can_be_your_friends.html

http://www.sjbaker.org/steve/omniv/matrices_can_be_your_friends.html

Miguel_dup1

07-08-2003, 07:55 PM

I have not been in the OGL world for a long time due to work. But GODDAMN some things do not change. Right Mihail?? Some people just suck for a life time and never snap out of it...

Well, to help out on the camera system with glRotate, glTranslate, glLoadMatrix... I might have gluLookAt somewhere in there too. Anyways, I have several demos demonstrating how to build your own matrices from quaternions and use glRotate, glTranslate, and glLoadMatrix... If you are interested...

http://141.217.130.254/miguel/

To add on the glRotate and glTranslate compared to gluLookAt.

I would use gluLookAt if it is a quick demo. But for a bigger demo I would glRotate and glTranslate because as someone already said, they are done in HW.

I must also say that it all depends on what you like best. I like rotate and translate better because I feel I have more control over what I do. gluLookAt hides the work from you; it creates a view matrix.

All in all, they both give the same result, so your real concern should be which one you feel more confortable using, since the overhead is not even noticible.

Well, to help out on the camera system with glRotate, glTranslate, glLoadMatrix... I might have gluLookAt somewhere in there too. Anyways, I have several demos demonstrating how to build your own matrices from quaternions and use glRotate, glTranslate, and glLoadMatrix... If you are interested...

http://141.217.130.254/miguel/

To add on the glRotate and glTranslate compared to gluLookAt.

I would use gluLookAt if it is a quick demo. But for a bigger demo I would glRotate and glTranslate because as someone already said, they are done in HW.

I must also say that it all depends on what you like best. I like rotate and translate better because I feel I have more control over what I do. gluLookAt hides the work from you; it creates a view matrix.

All in all, they both give the same result, so your real concern should be which one you feel more confortable using, since the overhead is not even noticible.

07-08-2003, 09:22 PM

Thank's for tutorial & links. I will keep it in mind.

john

07-08-2003, 11:00 PM

Hello,

I think the argument for rotate/translate over gluLookAt is obfuscated, somewhat, by speed issues. It is true that both generate a transform matrix, but where they differ isn't necessarily just that one is directly supported in hardware, but that they have different interfaces. I think this argument is more important.

For instance, how would you set up the rotation/translation so that the user is at A, looking at B with the up-vector C? The answer is simple with gluLookAt, but the only way that i can think of from the top of my head to do this using purely rotate/translate is to to project A and C onto the XZ and YZ axis and compute the angle to find the X and Y rotations and project the up axis onto the XY plane to find the Z rotation. That's a lot of work JUST so you can turn around and provide three rotation + one translation call to GL.

Is my point clear? Certainly it'd be easier to shift a camera once its orientated and y ou want to make modifications to it in a picewise fashion, but if you start with the identity matrix and want to jump to a particular postion/lookat/up configuration then I think you'd be hard pressed to come up with a better solution than gluLookAt. My argument is that its not so much a matter of trivial amount of speed difference but that both offer different interfaces and ease of expressing different transformations.

cheers

John

I think the argument for rotate/translate over gluLookAt is obfuscated, somewhat, by speed issues. It is true that both generate a transform matrix, but where they differ isn't necessarily just that one is directly supported in hardware, but that they have different interfaces. I think this argument is more important.

For instance, how would you set up the rotation/translation so that the user is at A, looking at B with the up-vector C? The answer is simple with gluLookAt, but the only way that i can think of from the top of my head to do this using purely rotate/translate is to to project A and C onto the XZ and YZ axis and compute the angle to find the X and Y rotations and project the up axis onto the XY plane to find the Z rotation. That's a lot of work JUST so you can turn around and provide three rotation + one translation call to GL.

Is my point clear? Certainly it'd be easier to shift a camera once its orientated and y ou want to make modifications to it in a picewise fashion, but if you start with the identity matrix and want to jump to a particular postion/lookat/up configuration then I think you'd be hard pressed to come up with a better solution than gluLookAt. My argument is that its not so much a matter of trivial amount of speed difference but that both offer different interfaces and ease of expressing different transformations.

cheers

John

Miguel_dup1

07-09-2003, 06:50 PM

Originally posted by john:

Hello,

I think the argument for rotate/translate over gluLookAt is obfuscated, somewhat, by speed issues. It is true that both generate a transform matrix, but where they differ isn't necessarily just that one is directly supported in hardware, but that they have different interfaces. I think this argument is more important.

True, I already mentioned it and it is an desicion that is made depending on what is easier for each individual.

For instance, how would you set up the rotation/translation so that the user is at A, looking at B with the up-vector C? The answer is simple with gluLookAt, but the only way that i can think of from the top of my head to do this using purely rotate/translate is to to project A and C onto the XZ and YZ axis and compute the angle to find the X and Y rotations and project the up axis onto the XY plane to find the Z rotation. That's a lot of work JUST so you can turn around and provide three rotation + one translation call to GL.

What is the use of projecting a vector in order to translate or rotate?

Fortunately, projections are not needed for what you are suggesting; rotating an object or whatever you want... You always have three axis that are orthogonal, and operations are cumulative. This allows for independet rotation along any axis. So, yes you are right you need three glRotate and one glTranslate to rotate, but this is only if you are using euler angles, which by nature is buggy (it suffers from gimbal lock). If you were using quaternions, you would only need one glRotate, and one glTranslate, and this does not suffer from gimbal lock.

Is my point clear? Certainly it'd be easier to shift a camera once its orientated and y ou want to make modifications to it in a picewise fashion, but if you start with the identity matrix and want to jump to a particular postion/lookat/up configuration then I think you'd be hard pressed to come up with a better solution than gluLookAt. My argument is that its not so much a matter of trivial amount of speed difference but that both offer different interfaces and ease of expressing different transformations.

Well, I really dont see why a piecewise rotation is any different from rotating a identity matrix whatever amount you want. What I mean is that you do not need to rotate one degree each time. You can rotate 45 degrees one time and 30 the other!!!! Simply do a sin(45) cos(45) and sin(30) cos(30)!!! To jump from 0 degrees to 85 degrees? do a sin(85) and a cos(85)!

The rotation matrix is created by OGL when you call glRotate. You can create your own matrix and load it or multiply it by the existing one.

I suggest you look at the code I have for camera systems... It is fairly clear and quite helpful if you want to learn how some basic camera systems work.

Miguel

Hello,

I think the argument for rotate/translate over gluLookAt is obfuscated, somewhat, by speed issues. It is true that both generate a transform matrix, but where they differ isn't necessarily just that one is directly supported in hardware, but that they have different interfaces. I think this argument is more important.

True, I already mentioned it and it is an desicion that is made depending on what is easier for each individual.

For instance, how would you set up the rotation/translation so that the user is at A, looking at B with the up-vector C? The answer is simple with gluLookAt, but the only way that i can think of from the top of my head to do this using purely rotate/translate is to to project A and C onto the XZ and YZ axis and compute the angle to find the X and Y rotations and project the up axis onto the XY plane to find the Z rotation. That's a lot of work JUST so you can turn around and provide three rotation + one translation call to GL.

What is the use of projecting a vector in order to translate or rotate?

Fortunately, projections are not needed for what you are suggesting; rotating an object or whatever you want... You always have three axis that are orthogonal, and operations are cumulative. This allows for independet rotation along any axis. So, yes you are right you need three glRotate and one glTranslate to rotate, but this is only if you are using euler angles, which by nature is buggy (it suffers from gimbal lock). If you were using quaternions, you would only need one glRotate, and one glTranslate, and this does not suffer from gimbal lock.

Is my point clear? Certainly it'd be easier to shift a camera once its orientated and y ou want to make modifications to it in a picewise fashion, but if you start with the identity matrix and want to jump to a particular postion/lookat/up configuration then I think you'd be hard pressed to come up with a better solution than gluLookAt. My argument is that its not so much a matter of trivial amount of speed difference but that both offer different interfaces and ease of expressing different transformations.

Well, I really dont see why a piecewise rotation is any different from rotating a identity matrix whatever amount you want. What I mean is that you do not need to rotate one degree each time. You can rotate 45 degrees one time and 30 the other!!!! Simply do a sin(45) cos(45) and sin(30) cos(30)!!! To jump from 0 degrees to 85 degrees? do a sin(85) and a cos(85)!

The rotation matrix is created by OGL when you call glRotate. You can create your own matrix and load it or multiply it by the existing one.

I suggest you look at the code I have for camera systems... It is fairly clear and quite helpful if you want to learn how some basic camera systems work.

Miguel

john

07-09-2003, 10:05 PM

What is the use of projecting a vector in order to translate or rotate?

to find out the angles about each three axis. Actually, for a given point in three dimensions you only need to find two angles of rotation because a single point doesn't define the 'up' vector. Given a point <A B C> you need to project htat point to the XZ plane and hence compute the rotation of the point <A C> with

y_rotation=atan2(C, A);

and then compute the X rotation by projecting the point to the YZ plane with

x_rotation=atan2(B, C);

Fortunately, projections are not needed for what you are suggesting; rotating an object or whatever you want...

then what would you suggest?

but this is only if you are using euler angles, which by nature is buggy (it suffers from gimbal lock). If you were using quaternions, you would only need one glRotate, and one glTranslate, and this does not suffer from gimbal lock.

well, euler angles aren't buggy. They only have degenerative issues in some cases, but that isn't a bug and it is only a hinderance if you're parameterisation is bad. Gimbal lock occurs becuase you're rotating your rotation device, also; it isn't a problem if you don't do that. There isn't a degeneracy in this case because its being statically computed, not modified.

quote:

Is my point clear? Certainly it'd be easier to shift a camera once its orientated and y ou want to make modifications to it in a picewise fashion, but if you start with the identity matrix and want to jump to a particular postion/lookat/up configuration then I think you'd be hard pressed to come up with a better solution than gluLookAt. My argument is that its not so much a matter of trivial amount of speed difference but that both offer different interfaces and ease of expressing different transformations.

The rotation matrix is created by OGL when you call glRotate. You can create your own matrix and load it or multiply it by the existing one.[/QUOTE]

what I meant by picewise transformation was building the transformation matrix as a culmination of transformation operations, not rotating/translating by a unit at a time. gluLookAt isn't piecewise; it computes a single matrix. successive calls to glRotate about each axis and a glTranslate is (from my intended meaning) a piecewise approach insofar as you're making successive modifications.

I suggest you look at the code I have for camera systems... It is fairly clear and quite helpful if you want to learn how some basic camera systems work.

<cough> ah, thanks. I'm doing a PhD in computer vision modelling real cameras to reconstruct geometry from photograms. :-) Oh, and we use Euler angles all the time; quaterions are really only applicable for animating rotations, not for computing static rotations.

Want to see my camera class? :-) It even models skew and optical centre parameters. Actually, that isn't all that exciting; the vast majority of the work is getting the interface for camera in real world measurements (focal length and CCD dimensions in millimetres) into a format I can interchange arbitarily with opengl.

cheers

John

to find out the angles about each three axis. Actually, for a given point in three dimensions you only need to find two angles of rotation because a single point doesn't define the 'up' vector. Given a point <A B C> you need to project htat point to the XZ plane and hence compute the rotation of the point <A C> with

y_rotation=atan2(C, A);

and then compute the X rotation by projecting the point to the YZ plane with

x_rotation=atan2(B, C);

Fortunately, projections are not needed for what you are suggesting; rotating an object or whatever you want...

then what would you suggest?

but this is only if you are using euler angles, which by nature is buggy (it suffers from gimbal lock). If you were using quaternions, you would only need one glRotate, and one glTranslate, and this does not suffer from gimbal lock.

well, euler angles aren't buggy. They only have degenerative issues in some cases, but that isn't a bug and it is only a hinderance if you're parameterisation is bad. Gimbal lock occurs becuase you're rotating your rotation device, also; it isn't a problem if you don't do that. There isn't a degeneracy in this case because its being statically computed, not modified.

quote:

Is my point clear? Certainly it'd be easier to shift a camera once its orientated and y ou want to make modifications to it in a picewise fashion, but if you start with the identity matrix and want to jump to a particular postion/lookat/up configuration then I think you'd be hard pressed to come up with a better solution than gluLookAt. My argument is that its not so much a matter of trivial amount of speed difference but that both offer different interfaces and ease of expressing different transformations.

The rotation matrix is created by OGL when you call glRotate. You can create your own matrix and load it or multiply it by the existing one.[/QUOTE]

what I meant by picewise transformation was building the transformation matrix as a culmination of transformation operations, not rotating/translating by a unit at a time. gluLookAt isn't piecewise; it computes a single matrix. successive calls to glRotate about each axis and a glTranslate is (from my intended meaning) a piecewise approach insofar as you're making successive modifications.

I suggest you look at the code I have for camera systems... It is fairly clear and quite helpful if you want to learn how some basic camera systems work.

<cough> ah, thanks. I'm doing a PhD in computer vision modelling real cameras to reconstruct geometry from photograms. :-) Oh, and we use Euler angles all the time; quaterions are really only applicable for animating rotations, not for computing static rotations.

Want to see my camera class? :-) It even models skew and optical centre parameters. Actually, that isn't all that exciting; the vast majority of the work is getting the interface for camera in real world measurements (focal length and CCD dimensions in millimetres) into a format I can interchange arbitarily with opengl.

cheers

John

Powered by vBulletin® Version 4.2.5 Copyright © 2018 vBulletin Solutions Inc. All rights reserved.