Path: chuka.playstation.co.uk!news From: Peter Passmore Newsgroups: scee.yaroze.programming.3d_graphics Subject: Re: RotMatrixBUG???? Date: Tue, 07 Jul 1998 21:54:57 +0100 Organization: PlayStation Net Yaroze (SCEE) Lines: 113 Message-ID: <35A28B21.2242@mdx.ac.uk> References: <01bda686$31300120$4fa1f7c2@manolo> <359D8B5E.54DE@mdx.ac.uk> <35a1842a.902603362@news.scea.sony.com> NNTP-Posting-Host: staff-dialup4.mdx.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.04 (Win95; I) Hi, I don't know whether James and I answered Emmanuele's question above - maybe he should post his rotate function so we can see what the problem is. Firstly note that scaling factors are specified along the diagonal of the matrix sx 0 0 0 sy 0 0 0 sz and all of x, y or z rotations have some term which falls along this diagonal so it's not surprising that scaling side effects occur when the matrix gets out of shape. >Does normalizing the row and column vectors afterwords automatically >ensure that the error is corrected? Corrected is too strong a word, 'avoids scaling problems' appears to be the case. This approach must result in some error somewhere, probably the new direction of the model is not exactly correct as specified by your amount of rotation. However this is usually unnoticable in play because your object can still move correctly in the direction it's pointing and I haven't seen a problem with it yet. A likely problem is lack of exact reverseability, ie: if you did a long series of rotations and then tried to reverse them you may not get back to the exact original orientation. Also it's rather curious the method works as it doesn't address the orthogonality condition and doesn't deal with the matrix as a whole entity which is what you would like it to do. There are bound to be conditions where the scheme causes problems but as the typical error is low (eg: length of a vector is 1 or 2 units out from 4096) it doesn't seem to cause trouble until the error accumulates. Anyway note that the Japanese solution works on submatrices of the matrix. >>A solution: 'condition' the matrix from time to time >Does this have to be done every single time you multiply the matrices? In practice you can usually get away with normalising one row or column per rotation on the Yaroze, floating point systems can get away with doing it less often. >>by normalising the >>matrix rows and columns, you can generally get away with normalising one >>row or column vector at a time. >> >>To normalise a vector you divide it's components by it's magnitude or >>length ie: >> >>Length= sqrt(x*x+y*y+z*z) >> >>And then >>x'=x/length,y'=y/length,z'=z/length >> >Ok, is this what you're saying?: >1) Concatenate (multiply) rotation matrix (taken from a rotation >vector, called TempMatrix) by the coord matrix, overwriting the result >into the coord matrix: >// NOTE: the object is rotated (original position is lost), but >results in distortion >MulMatrix0(&Coord.coord, &TempMatrix, &Coord.coord); Yes. This is the body of a rotate function that uses it. MATRIX matTmp; SVECTOR svRotate; // This is the vector describing the rotation svRotate.vx = nRX; svRotate.vy = nRY; svRotate.vz = nRZ; // RotMatrix sets up the matrix coefficients for rotation RotMatrix(&svRotate, &matTmp); // Concatenate the existing object's matrix with the rotation matrix MulMatrix0(&gsObjectCoord->coord, &matTmp, &gsObjectCoord->coord); //Condition matrx AdjustCoordinate2(gsObjectCoord); // set flag to redraw object gsObjectCoord->flg = 0; >// NOTE: this corrects the model's error >AdjustCoordinate2(Coord.coord); It worth noting it's not the model that becomes distorted but it's transformation matrix. (ie: you could have special solutions in particular games, if the model has to go through a particular point at a particular orientation you could detect when it reaches that point and start it off again with a fresh matrix with the right angles for that point). It's also worth noting that the effect of applying the rotation matrix doesn't happen in the rotate function but when the models vertices are recalculated, by which time the matrix is conditioned. (Also this problem should not be confused with apparent 'wobbling' of the model which occurs on rotation with the error increasing as a function of distance from the origin, when the camera has it's super coordinate system as the model.) >Even if this is the case, why is it true that "normalizing" the row >and column vectors reduce error? Does this somehow fix most of the >error due to the multiplication? See comments above. Peter.