Path: chuka.playstation.co.uk!news
From: Majik <majik@127.0.0.1>
Newsgroups: scee.yaroze.freetalk.english,scee.yaroze.programming.3d_graphics
Subject: libps - RotMatrix()
Followup-To: scee.yaroze.programming.3d_graphics
Date: Fri, 26 Oct 2001 09:50:33 +0100
Organization: PlayStation Net Yaroze (SCEE)
Lines: 59
Message-ID: <3BD923D9.872FC1A0@127.0.0.1>
NNTP-Posting-Host: tide136.microsoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I)
X-Accept-Language: en
Xref: chuka.playstation.co.uk scee.yaroze.freetalk.english:7498 scee.yaroze.programming.3d_graphics:1508

Hi guys, I just wanted to have a quick discussion about the function
above, and to some extent the 3 related XYZ variants.

Whilst putting together a quick 1st pass demo fo the biplanes game of
Combat3D I noticed that RotMatrix() doesn't do as I had hoped, here's
the situation;

I maintain 2 vectors for the planes, a position in space, and a rotation
vector, the rotation vectors are assigned as follows

	x = banking angle
	y = pitch
	z = direction

so the planes have +ve z as up, and fly in the direction of the +ve y

now, to get the model to 'point' in the direction that it is going to
fly, I naturally did somethiing on the lines of

	SVECTOR rot
	MATRIX *mtrx;	/* initialised to point to matrix in GsCOORDINATE2 */

	SetVector(&rot, x, y, z);
	RotMatrix(&rot, mtrx);

but this doesn't actually work. it's fine as long as z is a multiple of
90 degrees anything else and turning and going up/down causes it to go
into a stall spin!

Reading the manual (that well thumbed green volume) it describes the
order that RotMatrix actaully works, it (internally) does RotMatrixZ()
then RotMatrixY() then RotMatrixX() so I set about thinking about what I
ACTUALLY want to happen, ie head scratching and pencil scribbling,
finally I come to the conclusion that what is required is a reversed
order of rotation, ie start with X, then Y then Z so changing the code
above to read

	SVECTOR rot
	MATRIX *mtrx;	/* initialised to point to matrix in GsCOORDINATE2 */

	RotMatrixX(x, mtrx);
	RotMatrixY(y, mtrx);
	RotMatrixZ(z, mtrx);

does just the trick! and the planes fly happily along, looping the loop,
and banking round corners.

so, questions;

1) Why does RotMatrix() go the way it does?

2) Why wasn't a second RotMatrix() provided that did it the other way?

3) What bug still exists in the second code frag?
	(it actually produced some 'interesting results at first')

4) Anyone else had a similar 'experience' with RotMatrix()

M.