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?