I’ve got a bit of a problem/question regarding directional vectors…

After messing around with Quake’s AngleVectors() function (which creates a directional vector from YAW,PITCH & ROLL)…well here it is (Quake’s) to begin with:

    float       angle;
    float       sr, sp, sy, cr, cp, cy;

    angle = angles[YAW] * (M_PI*2 / 360);
    sy = sin(angle);
    cy = cos(angle);
    angle = angles[PITCH] * (M_PI*2 / 360);
    sp = sin(angle);
    cp = cos(angle);
    angle = angles[ROLL] * (M_PI*2 / 360);
    sr = sin(angle);
    cr = cos(angle);

    forward[0] = cp*cy;
    forward[1] = cp*sy;
    forward[2] = -sp;

As I was saying, after modifying the code so that it can work with OpenGL’s world coordination (i.e. Y-axis being up, instead of Quake’s Z-up axis)…I ended up with:

   float sr,sp,sy,cr,cp,cy;
   float radians;

   radians = (angle[YAW]+180)*(PI/180);
   sy = sin(radians);
   cy = cos(radians);

   radians = -angle[PITCH]*(PI/180);
   sp = sin(radians);
   cp = cos(radians);

   radians = angle[ROLL]*(PI/180);
   sr = sin(radians);
   cr = cos(radians);

   vec[0] = cp*sy;
   vec[2] = cp*cy;
   vec[1] = -sp;


My question is....HOW DOES IT WORK?????
I know how to do ray projection, clipping, plane work....but I can't understand this relatively simple code....

I would have thought that you would have done Matrix rotation...but when i did would mess up my forward direction when aiming up a bit (it would go right a bit)....and im sure that my matrix code is correct.....

Sorry to post all the code and this message, but I really need to figure this little thing out.....

If anyone can explain why you do the cos(angle)*sin(angle), etc calculations, or any explanations, I would GREATLY appreciate it,

Thanks  [img][/img]

Okay…it seems as though I fixed the problem by mistake

You are supposed to do a PITCH before a YAW (not the other way around)…

But STILL, how does Quake do it like this??

I was messing around with putting three rotations (around the x y and z axis respectivly) in one matrix. So I had an angle for y-rotation (what you call YAW right?) and one for X rotation (PITCH?) and one for Z rotation (ROLL?). Then I just put these values in the matrix I ended up with (the one compining all three rotations in one). Then I multiplied a vector pointing down the negative Z-axis (0,0,-1) by this matrix to get the new direction vector.
And well, it worked. And I seem to remember it looked something like the code you have up there. Basically a lot of stuff is multiplied by zero so there’s no need putting that in there. So what you see above is probably what’s left of the XYZ-rotation-matrix after you multiply (0,0,-1) with it.

I don’t have my code in front of me so I’m not sure, but I believe it looked something like that.

Hmm… Now that I think about it, I didn’t get it to work fully! =)
The only rotation that worked satisfactory was that around the Y-axis. So I assume you should multiply the rotation-matrixes in ZYX (Y is in the same order, but the other two axises are switched) order and not XYZ order. You would end up with a completly different rotation matrix. I’m sure THAT’s how they do it! =)

Yeah, I did exactly the same thing…the wrong order thing…here is my WORKING

SetIdentityAngle(vec);  // (0,0,-1)

MatrixRotate(matz,-angle[ROLL],ROLL); // Negative because Z is going into screen


This works fine now…

It confuses the hell out of you when you do do the rotations the wrong way around…like they actual WORK, but just not quite so…

I think the quake thing, is yes…putting eular’s angles STRAIGHT into the matrix-multiplicator…without the unnecessary bits…I think…

Thanks anyway