Fix orientation in camera
by Orion Elenzil · 07/03/2006 (11:34 am) · 12 comments
The Problem:
Camera::setOrbitMode() takes a AngAxisF rot parameter, which is a 4-component rotation such as axis, angle.
It then creates a quaternion from rot, and then creates a rotation matrix from the quaternion.
So far so good.
The routine now extracts the second column of the matrix, which, as we all know, is the Y-basis vector of the rotation. Which is a good and useful thing, but read on..
We now come to Camera::setPosition() and see that it's expecting, in addition to position, a parameter called "rot", which is an EULER rotation. That is, a 3-component rotation specifying angles about each of the x, y, and z axes. More specifically, it is *not* the Y-basis vector.
What should have been done is that the euler angles should have been extracted from the matrix and passed into setPosition().
The Fix, part one
First we have to lay a little groundwork refactoring.
I'm going to do this at a high-level because it's pretty straight forward.
For some reason, the widely useful routine "extractEuler" is only defined in worldEditor.cc. That guy really belongs in mMatrix.cc.
move extractEuler from worldEditor.cc to mMatrix.cc
I had a little trouble with the 'const' in the declarations, so i'll repeat them here:
mMatrix.h
mMatrix.cc
- while you're at it, you might as well move "snapFloat()" out of worldEditor.cc and into mMath.h as "mFSnap".
- you'll of course need to patch up worldEditor.cc so it compiles.
The Fix, part two
camera.cc
in Camera::setOrbitMode(),
change this:
all done.
Now you can get sensible things done when entering orbit mode.
Camera::setOrbitMode() takes a AngAxisF rot parameter, which is a 4-component rotation such as axis, angle.
It then creates a quaternion from rot, and then creates a rotation matrix from the quaternion.
So far so good.
The routine now extracts the second column of the matrix, which, as we all know, is the Y-basis vector of the rotation. Which is a good and useful thing, but read on..
We now come to Camera::setPosition() and see that it's expecting, in addition to position, a parameter called "rot", which is an EULER rotation. That is, a 3-component rotation specifying angles about each of the x, y, and z axes. More specifically, it is *not* the Y-basis vector.
What should have been done is that the euler angles should have been extracted from the matrix and passed into setPosition().
The Fix, part one
First we have to lay a little groundwork refactoring.
I'm going to do this at a high-level because it's pretty straight forward.
For some reason, the widely useful routine "extractEuler" is only defined in worldEditor.cc. That guy really belongs in mMatrix.cc.
move extractEuler from worldEditor.cc to mMatrix.cc
I had a little trouble with the 'const' in the declarations, so i'll repeat them here:
mMatrix.h
/// extract the rotation aspect of this matrix as eulers. EulerF extractEuler() const;
mMatrix.cc
EulerF MatrixF::extractEuler() const
- while you're at it, you might as well move "snapFloat()" out of worldEditor.cc and into mMath.h as "mFSnap".
- you'll of course need to patch up worldEditor.cc so it compiles.
The Fix, part two
camera.cc
in Camera::setOrbitMode(),
change this:
Point3F dir; tempMat.getColumn(1, &dir);to this:
EulerF dir = tempMat.extractEuler();
all done.
Now you can get sensible things done when entering orbit mode.
About the author
#2
wow, it's been so long i'd forgotten i even submitted this thing.
basically the setOrbitMode() call could theoretically allow you to set the initial orientation of the orbit cam.
however it has a bug, and you basically get a totally random initial orientation.
this resource fixes that.
i doubt it will have any effect on camera jittering. (i haven't tested it beause there's no way to die in The Lounge! :)
07/03/2006 (3:56 pm)
hi!wow, it's been so long i'd forgotten i even submitted this thing.
Quote:
Synposis:
setOrbitMode takes a typical torquescript transform: "Px Py Pz Rvx Rvy Rvz Ra". However the rotation aspect of this transform was being totally munged by the code equating a basis vector with a set of euler rotations. This resource fixes this problem, and also improves the matrix class.
basically the setOrbitMode() call could theoretically allow you to set the initial orientation of the orbit cam.
however it has a bug, and you basically get a totally random initial orientation.
this resource fixes that.
i doubt it will have any effect on camera jittering. (i haven't tested it beause there's no way to die in The Lounge! :)
#3
07/04/2006 (4:11 am)
Thanks Orion and good luck with your game :) 
#4
07/26/2006 (3:42 pm)
What does this do differently than the already existant toEuler function in mMatrix.cc?
#5
this is a fix to a bug in camera's setOrbitMode() function.
it's not anything mathematically new, it's not new functionality,
there was simply a bug in setOrbitMode where it was mangling parameters.
IMO the bug was significant.
edit: added "this is a fix.." etc to the synopsis.
07/26/2006 (3:53 pm)
wow, i'm apparently way worse at communicating than i thought!this is a fix to a bug in camera's setOrbitMode() function.
it's not anything mathematically new, it's not new functionality,
there was simply a bug in setOrbitMode where it was mangling parameters.
IMO the bug was significant.
edit: added "this is a fix.." etc to the synopsis.
#6
engine/game/camera.cc
Go to line 281 where it says
Problem Solved.
08/02/2006 (11:26 am)
Quote from StefanQuote:
Does it solve the jittering issues when a player is killed and enters orbital mode?
engine/game/camera.cc
Go to line 281 where it says
validateEyePoint(1.0f, &mRenderObjToWorld);Change this line to read
validateEyePoint(1.0f, &mObjToWorld);
Problem Solved.
#7
Also, in the Matrix files about what line number did you place these at?
08/08/2006 (1:24 pm)
Nice but what had to be done in worldeditor.cc? Also, in the Matrix files about what line number did you place these at?
#8
02/15/2007 (10:40 am)
What version of Torque is this fix for is it still valid in version 1.5 or did they get around to fixing their code?
#9
02/15/2007 (3:04 pm)
dunno - i don't have TGE 1.5
#10
08/04/2007 (9:06 pm)
Uhhh it appears TGE 1.5 now includes EulerF dir = tempMat.extractEuler(); but they improperly credited my resource which gave credit to Orion. It's a shame that they didn't include my fix for the console method setOrbitMode which didn't allow the user to orbit a point when the engine clearly had a mode setting for this. They also didn't include my fix for including mCurOrbitDistance in the calculation to figure out the distance to orbit from the object. In my opinion these are just as important as the issue of the initial orbit angle.
#11
08/05/2007 (2:07 am)
hey Geoffrey - thanks for the calllout. what's the link to your resource ?
#12
They probably mentioned my resource because it only changed
Point3F dir;
tempMat.getColumn(1, &dir);
to
EulerF dir = tempMat.extractEuler();
but, if you look at the end of the setOrbitMode function, the setPosition function actually accepts a Point3F. I suppose that it works and compiles because EulerF is typedefined as a Point3F... I don't know the intrecate workings of C++ magic so I'm just speculating.
That whole section really is doing a lot of interesting math with the matricies.
One last note... None of this is going to do anybody any good in TGE 1.5
Orbit Mode appears to be broken. The camera source files are exactly the same but the position of the camera is stuck at, i believe, the eye node of the player/object when you enter Orbit Mode. I can't even change it with updating the calculation to include mCurOrbitDist!? I'm guessing it has something to do with the Lighting Kit.
08/12/2007 (9:08 am)
http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=11035They probably mentioned my resource because it only changed
Point3F dir;
tempMat.getColumn(1, &dir);
to
EulerF dir = tempMat.extractEuler();
but, if you look at the end of the setOrbitMode function, the setPosition function actually accepts a Point3F. I suppose that it works and compiles because EulerF is typedefined as a Point3F... I don't know the intrecate workings of C++ magic so I'm just speculating.
That whole section really is doing a lot of interesting math with the matricies.
One last note... None of this is going to do anybody any good in TGE 1.5
Orbit Mode appears to be broken. The camera source files are exactly the same but the position of the camera is stuck at, i believe, the eye node of the player/object when you enter Orbit Mode. I can't even change it with updating the calculation to include mCurOrbitDist!? I'm guessing it has something to do with the Lighting Kit.
Torque Owner Stefan Lundmark
I failed to understand what, pratically, this resource attemps to "fix".
Does it solve the jittering issues when a player is killed and enters orbital mode?