Path: chuka.playstation.co.uk!scea!peter_alau@playstation.sony.com From: jamin1@psu.edu (Jamin Frederick) Newsgroups: scee.yaroze.programming.3d_graphics Subject: Re: RotMatrixBUG???? Date: Tue, 07 Jul 1998 02:31:43 GMT Organization: SCEA News Server Lines: 66 Message-ID: <35a1842a.902603362@news.scea.sony.com> References: <01bda686$31300120$4fa1f7c2@manolo> <359D8B5E.54DE@mdx.ac.uk> NNTP-Posting-Host: 204.240.38.127 X-Newsreader: Forte Free Agent 1.11/32.235 On Sat, 04 Jul 1998 02:54:38 +0100, Peter Passmore wrote: >There was some discussion of this problem but it disappeared off the >news… The problem with matrix concatenation is that precision errors >accumulate and build up to produce scaling and shearing of your object. >This happens very quickly for integer based matrices but also occurs for >eventually for floating point matrices. > >Any row or column in the rotation matrix should always be a unit vector >to avoid shearing or scaling. >ie: > >Sqrt(x*x+y*y+z*z) =1 > >… and row or column vectors should be orthogonal (at 90 degrees) to each >other - which you should see is clearly true for the identity matrix: >1 0 0 >0 1 0 >0 0 1 >… and in fact rotation matrices. > Does normalizing the row and column vectors afterwords automatically ensure that the error is corrected? >A solution: 'condition' the matrix from time to time Does this have to be done every single time you multiply the matrices? >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); 2) Adjust the coord matrix: // NOTE: this corrects the model's error AdjustCoordinate2(Coord.coord); 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?