I think what's wrong here is that he is drawing the small ship on a larger object and rotating this same larger object, what causes the ship to not rotate correctly. The fact that I don't know a line of OpenGL halts me, but certainly our communication is the main issue...
rotating space ship
Dejaime, OpenGL is simple. The deprecated functions to modify the matrix stack simply operate on the local coordinate system/object space/whatever you like to call it. So it should be obvious why it's wrong to rotate first if your position is given in world space.
Not that it matters, because 3 posts from now, he will announce researching this and looking into that, disappear for a while and after a few months post the exact same code with the exact same question, showing zero progress or improvement and have half the people on the forum wonder if he's trolling us (and yet again he will ask what that means) or if he's really so completely beyond help that you'd have better luck explaining colors to a blind man.
To quote BSG: "All of this has happened before, and all of it will happen again." (ie. "just check his history")
what part of linear algebra should I focus on?
Definitely the Cayley-Hamilton Theorem.
Ok, a really brief overview:
1) Be sure that the origin (0,0,0) defines where you want your model to rotate about, this could be a problem with the model file. For instance, if you are describing a box, the vertex coordinates should go from negative x, y, z to positive x, y, z, e.g., the six vertices (1, 0, 0) , (-1, 0, 0), (0, 1, 0), (0, -1, 0), (0, 0, -1), (0, 0, 1) The "center" of the box would be at the origin. If this is not true, none of the following will work.
3) Two ways to do rotations, quaternions and matrices. Matrices are a little easier to grasp for the beginner, but quaternions involve less computation. The "standard" way is matrices.
3) The Matrix way: You have independent rotationa bout the x, y, z, axes. These are normally termined pitch, yaw, and roll. You then generate three matirces which descbibed these independent rotations, and multiply these matrices together, along with the translation matrix which locates your object in the world. In math terms, this a transformation is from "model" space to "world" space. You will often hear this matrix described as the "world" matrix. This matrix is then multiplied by the "view" (camera position and rotation) and "projection" (perspective, orthogonal ) matrices to produce the 2D x,y coordinates on your display.
The Quaternion way: You have an "axis of rotation", which is defined by a 3D vector, and additional number which indicates the amount and direction (positive or negative)of rotation. So a quaternion is really 4D vector. For example, if the axis of rotation represents the direction that the object is travelling in, then a rotation about this axis would be a "roll" which respect to the direction of travel of the object. Then add your translation vector. You then multiply the vertex coordinates (a 3D vector) by the quaternion, which proces another 3D vector.
To sum it up, take the position and translate by minus of it, that will send the object back to origin, then perform the rotation, and finally add the new translation to the previous position and you should be ok.
Rotation is done around the origin so if you don't translate back to it you are rotating around which a 45 degrees will get you 1/4 of the screen up.
It is like if every object would rotate at the end of a stick that is joint at the origin, if there is no stick, you are at origin you rotate on yourself.
Rotation is done around the origin so if you don't translate back to it you are rotating around which a 45 degrees will get you 1/4 of the screen up.
It is like if every object would rotate at the end of a stick that is joint at the origin, if there is no stick, you are at origin you rotate on yourself.
Let's not bring Quaternions into this. Even less any kind of manual vertex transformation. In almost half a year, despite several posts saying to do so, he apparently never switched the order of rotation and translation.
Unless the matrix stack is already screwed up, there is also absolutely no point in moving anything back and forth before/after rotating. Nothing but the view transformation should have been done yet. The model transformation is apparently NOT in addition to any previous model transformations. Why trying to "undo" a translation that isn't even part of the transformation matrix yet? Translating by the negative position, rotating and translating by the positive position would result in exactly the effect one wants to prevent:
glTranslate(-position) // Now we are in the opposite position we want to be
glRotate() // Now our orientation is correct, but we're still in the wrong place AND all our axes have just been rotated, affecting all future translations
glTranslate(position) // Now we are... somewhere, because this was NOT the opposite of the first translation (axes are different)
Just embrace OpenGL's "localness", stop thinking in "map origins", "north" and "west" and only worry about your objects current position, "forward" and "right". Suddenly OpenGL will be absolutely and completely straight forward. Translate, rotate, done.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement