Rotation Question / Error?
by Timothy May · in Torque Game Engine · 02/28/2005 (2:34 pm) · 5 replies
Rotation Question
I am experiencing some strange behavor rotating objects in Torque. I have
created my own class called Aircraft that inherits ShapeBase. I have written my
own processTick member function to allow me complete control over the path
of my object instances. Of course, the packUpdat and unpackUpdate member
functions are specific to the class as well.
I now need to be able to rotate the aircraft in X, Y and Z. I have removed the
Z only restrictions normally seen on rotation seen in other classes derived
from ShapeBase.
I can now rotate my Aircraft objects easily but have noticed that the
rotations around the X and Y axis do not behave as one would expect.
Rotations around the Z axis work fine. Specifically, the rotation occurs
around the center of the object.
Rotations around the X or Y axis do not occur around the objects
center. Instead, the rotation occurs around a point a significant distance
from the object center.
Here is a very simplified Aircraft::processTick() function:
void Aircraft::processTick(const Move* move)
{
mCurrentStep++;
//Misc. setup
setMaskBits(PositionMask);
F32 dt = TickSec; // Amount of time between ticks
// Get current position
Point3F pos;
mObjToWorld.getColumn(3,&pos);
// Calculate desired Velocity
VectorF vel;
vel.x = -15.0f; // move across the sky along the X axis
vel.y = 0.0f; // maintain constant Y axis orientation
vel.z = 0.0f; // maintain constant altitude
mVelocity = vel;
// Calcuate new position
pos = pos + mVelocity * dt; // maintain constant velocity
mRotX = (mRotX > 6.28) ? 0 : mRotX + 0.5; // rotate around X axis
mRotY = (mRotY > 6.28) ? 0 : mRotY + 0.0;
mRotZ = (mRotZ > 6.28) ? 0 : mRotZ + 0.0;
// Update transform
MatrixF mat = mObjToWorld;
mat.set(EulerF(mRotX,mRotY,mRotZ));
mat.setColumn(3,pos);
Parent::setTransform(mat);
}
When I modify the mRotZ value it works it should. When I modify the
mRotX or mRotY values the error in rotation occurs.
So, anybody have enough core engine experience to point me in the right
direction on this one?
I am experiencing some strange behavor rotating objects in Torque. I have
created my own class called Aircraft that inherits ShapeBase. I have written my
own processTick member function to allow me complete control over the path
of my object instances. Of course, the packUpdat and unpackUpdate member
functions are specific to the class as well.
I now need to be able to rotate the aircraft in X, Y and Z. I have removed the
Z only restrictions normally seen on rotation seen in other classes derived
from ShapeBase.
I can now rotate my Aircraft objects easily but have noticed that the
rotations around the X and Y axis do not behave as one would expect.
Rotations around the Z axis work fine. Specifically, the rotation occurs
around the center of the object.
Rotations around the X or Y axis do not occur around the objects
center. Instead, the rotation occurs around a point a significant distance
from the object center.
Here is a very simplified Aircraft::processTick() function:
void Aircraft::processTick(const Move* move)
{
mCurrentStep++;
//Misc. setup
setMaskBits(PositionMask);
F32 dt = TickSec; // Amount of time between ticks
// Get current position
Point3F pos;
mObjToWorld.getColumn(3,&pos);
// Calculate desired Velocity
VectorF vel;
vel.x = -15.0f; // move across the sky along the X axis
vel.y = 0.0f; // maintain constant Y axis orientation
vel.z = 0.0f; // maintain constant altitude
mVelocity = vel;
// Calcuate new position
pos = pos + mVelocity * dt; // maintain constant velocity
mRotX = (mRotX > 6.28) ? 0 : mRotX + 0.5; // rotate around X axis
mRotY = (mRotY > 6.28) ? 0 : mRotY + 0.0;
mRotZ = (mRotZ > 6.28) ? 0 : mRotZ + 0.0;
// Update transform
MatrixF mat = mObjToWorld;
mat.set(EulerF(mRotX,mRotY,mRotZ));
mat.setColumn(3,pos);
Parent::setTransform(mat);
}
When I modify the mRotZ value it works it should. When I modify the
mRotX or mRotY values the error in rotation occurs.
So, anybody have enough core engine experience to point me in the right
direction on this one?
About the author
#2
02/28/2005 (3:14 pm)
Who made the model? If the model build is whacked, so will be your rotations.
#3
02/28/2005 (3:16 pm)
DOH!, That's what happens when it takes 10 minutes to get a post in, lol.
#4
I have tried the test with a couple of different .dts files. My own aircraft.dts, the buggy.dts and wheel.dts. All act the same. I have also loaded these dts files into Torque Show Tool Plus and they rotate as expected. I went to some trouble to make sure my origin was correct when I built my .dts in anticipation of this kind of issue.
Any other ideas?
BTW,
m_matF_set_euler_C() in mMath_C.cc seems to have some sloppy coding in it. I haven't spent the time yet to figure out if the correct operations are being performed yet but the switch condition handling a Z only rotation has extra unused variable assignments r1, r2, r3 and r4.
Still confused at this end. Unfortunately my math skills, in this area, are pretty rusty so I'll have to brush up on this to get where I need to go. Actually, I purchased Torque to avoid having to get my hands this deep into the gears - oh well ;)
Tim
02/28/2005 (3:19 pm)
Stephen,I have tried the test with a couple of different .dts files. My own aircraft.dts, the buggy.dts and wheel.dts. All act the same. I have also loaded these dts files into Torque Show Tool Plus and they rotate as expected. I went to some trouble to make sure my origin was correct when I built my .dts in anticipation of this kind of issue.
Any other ideas?
BTW,
m_matF_set_euler_C() in mMath_C.cc seems to have some sloppy coding in it. I haven't spent the time yet to figure out if the correct operations are being performed yet but the switch condition handling a Z only rotation has extra unused variable assignments r1, r2, r3 and r4.
Still confused at this end. Unfortunately my math skills, in this area, are pretty rusty so I'll have to brush up on this to get where I need to go. Actually, I purchased Torque to avoid having to get my hands this deep into the gears - oh well ;)
Tim
#5
It is a problem with the AdvancedCamera object. Not the model or Torques math. There is a default value of 0,0,2 for lookAtOffset hardcoded into the Advanced Camera object. As my object rotated the camera was merrily following the point 2 units in the positive Z direction from the origin of the object. Very ugly to say the least.
Trust in the Source Luke - trust in the Source!
Anyway, all I had to do was call the setLookAtOffset() method during camera setup to solve the problem.
Thanks.
03/01/2005 (12:56 pm)
Found the problem!It is a problem with the AdvancedCamera object. Not the model or Torques math. There is a default value of 0,0,2 for lookAtOffset hardcoded into the Advanced Camera object. As my object rotated the camera was merrily following the point 2 units in the positive Z direction from the origin of the object. Very ugly to say the least.
Trust in the Source Luke - trust in the Source!
Anyway, all I had to do was call the setLookAtOffset() method during camera setup to solve the problem.
Thanks.
Torque 3D Owner Stephen Zepp
The orientation and translation of the object when it is modelled from the original modelling app does affect how TGE uses the resulting .dts. I'm not an expert on this (yet), but I've run into it quite a few times, since there doesn't seem to be any standard for how and where to put an object in relation to the origin while modelling it. I'm guessing it's mostly artist technique, but for a particular project you may want to set some standards.