Well what axis do you think is rightVector representing?
A Vector with Zero Lenght cant point in a direction, so its not a vector. :-
1 0 0
btw: rightVector was in my old post…
The answer is there (use Google Translate as it is in French):
http://www.univie.ac.at/cga/faq/angles.html
[quote]The current rotations must respect the previous rotations to avoid gimbal lock to prevent any alignment of rotation axis which causes this problem. This problem doesn’t depend on the mathematical way you choose to express rotations, it depends on the way to combine rotations. The problem comes from Euler’s classical transform: R=Rx.Ry.Rz
Implicitely or explicitly you use it with matrices, quaternions, Euler or Cardan angles, …
You should correct this transform and it works whatever you used to express your rotations:
R=R[R[R[Ox,a]Oy,b]R[Ox,a]Oz,c] . R[R[Ox,a]Oy,b] .R[Ox,a]
[/quote]
As far as I know, you want to use yaw, pitch and roll therefore you need to use this.
now it works
gl.glMatrixMode(GL.GL_PROJECTION);
gl.glLoadIdentity();
glu.gluPerspective(FOV, aspectratio, 0.5, 9000);
gl.glMatrixMode(GL.GL_MODELVIEW);
gl.glLoadIdentity();
gl.glRotatef(-roll, 0, 0, 1);
glu.gluLookAt(atx, aty, atz, lookx, looky, lookz, 0, 1, 0);
Nice try. Maybe you could remove the call to glRotatef and turn the up vector passed to gluLookAt (by using sine and cosine). You don’t use the roll to compute lookx, looky and lookz, you won’t have any gimbal lock with this piece of source code.
However, your up vector is wrong. When I look at something above me, my up vector isn’t (0,1,0). The up vector depends on yaw, pitch and roll. Then, as you combine 3 rotations, there is a risk of gimbal lock and you should use the formula that I suggested in order to compute this vector correctly.
all i know (or care) is that this works.
but it would work better if you do like gouessej said :persecutioncomplex:
No, it works only when yaw = 0 and pitch = 0, otherwise the up vector is wrong. It’s obvious, you don’t use yaw and pitch to compute your up vector (or you have forgotten to copy/paste a piece of source code doing it). You already use yaw and pitch to compute the eye point and the reference point; if you don’t want to use my formula but you want a correct result, use at least the yaw or the pitch to compute the up vector (so that you take into account the 3 rotations but not altogether in order to avoid the gimbal lock).
I have forgotten something. The following conventions are used in several 3D engines including Ardor3D:
- the Euler yaw of rotation is called Bank, (rotation around x)
- the Euler roll of rotation is called Heading (rotation around y)
- the Euler pitch of rotation is called Attitude (rotation around z)
With these definitions, the pitch (you called this the roll) is useless to compute the reference point and the roll is useless to compute the up vector.
Maybe do this but with the convention used above:
gl.glMatrixMode(GL.GL_PROJECTION);
gl.glLoadIdentity();
glu.gluPerspective(FOV, aspectratio, 0.5, 9000);
gl.glMatrixMode(GL.GL_MODELVIEW);
gl.glLoadIdentity();
//maybe invert the both lines below
gl.glRotatef(yaw, 1, 0, 0);
gl.glRotatef(-pitch, 0, 0, 1);
glu.gluLookAt(atx, aty, atz, lookx, looky, lookz, 0, 1, 0);
what code should i use to compute this vector in java?
I think the problem here is that beginners don’t understand nor experience the problem. My advise would simply be to ignore the problem. Quaternions are a ‘big thing’ which require some motivation to dig into. As long as it works, it will seem like a lot of unnecessary complex math with exactly the same end result as one has now.
Sooner or later, with nested rotations, the problem will become obvious, and the developer will actually want to invest the time to fix it.
A nice start would be to try to see how lookAt works, and how the rotations are calculated. Once you understand what happens underneath, you can see how to integrate that ‘-roll rotation over the Z axis’ into the equation.
That’s why I suggested him a simpler solution using almost the same source code.
It requires the use of quaternions. As you seem to be a beginner, I suggested you another solution that simply uses the source code you provided with only a small difference:
//maybe invert the both lines below (they use the NASA convention, not yours)
gl.glRotatef(yaw, 1, 0, 0);
gl.glRotatef(-pitch, 0, 0, 1);
glu.gluLookAt(atx, aty, atz, lookx, looky, lookz, 0, 1, 0);
why should i use glrotate with the yaw? glulookat does that for me
No, gluLookAt keeps your up vector as is:
http://www.manpagez.com/man/3/gluLookAt/
It is up to you to provide a correct up vector directly or to use several calls to glRotate in order to obtain the same result.
His code is fine. There is only a problem if he looks in the exact UP or down direction. If that is likely to happen you should add a special case for that, otherwise pat yourself on the back and move on.
According to you, the up vector is correct, isn’t it? But he always provides (0,1,0). I don’t understand why you think it is fine.
Ok you’re speaking about the both singularities at the south and the north poles (gimbal lock). I agree with you.
Your right, I didn’t read the whole tread and I thought he actually wanted an always up camera.
But if I understand the problem correctly now (probably not) then the easiest solution would be to use the matrices that are built into OpenGL. No need to mess around with Quaternions.
gl.glLoadIdentity();
gl.glTranslate(atx, aty, atz);
gl.glRotate(yaw, 1, 0, 0);
gl.glRotate(pitch, 0, 1, 0);
gl.glRotate(roll, 0, 0, 1);
The code above uses Euler transforms to combine 3 rotations so there is a risk of gimbal lock as I explained earlier