SetTransform: only z rotation?!
by Mr. Kristen Overmyer · in Torque Game Engine · 01/22/2005 (4:51 pm) · 30 replies
Been working through the Finney book example on "Programmed Rotation". On page 113 he suggests playing with the parameters for %shape.setTransform(...). This I have been doing. First a reality check on my understanding of the transform arguments. They appear to be:
lx the x position
ly the y position
lz the z position
rx the x unit vector for the rotation axis
ry the y unit vector for the rotation axis
rz the z unit vector for the rotation axis
rd the rotation (in radians) about the axis
I am only able to get the item to rotate for rx, ry, rz values of 0, 0, 1. When I try 1, 0, 0, or 0, 1, 0, nothing happens as evidenced by neither the object moving or the subsequent getTransform showing a change in value.
Is my understanding of the arguments correct?
Is there a bug here?
I have literally spent hours trying to track down any usefull information on either setTransform or the Transform argument itself. I can find stuff for the engine equivalent SceneObject::setTransform and matrices, but nothing to document the argument meanings and behaviors as used in Torque Script.
On a side note, the Finney book talks about Torque using a right-handed system. This appears to be the case when I translate objects in the x, y, and z directions using script commands. However, the one z rotation I have managed appears to be a left-handed rotation about the positive z axis. Seems to be a mixed bag. Is the true?
Any and all help gratefully appreciated.
Kristen.
lx the x position
ly the y position
lz the z position
rx the x unit vector for the rotation axis
ry the y unit vector for the rotation axis
rz the z unit vector for the rotation axis
rd the rotation (in radians) about the axis
I am only able to get the item to rotate for rx, ry, rz values of 0, 0, 1. When I try 1, 0, 0, or 0, 1, 0, nothing happens as evidenced by neither the object moving or the subsequent getTransform showing a change in value.
Is my understanding of the arguments correct?
Is there a bug here?
I have literally spent hours trying to track down any usefull information on either setTransform or the Transform argument itself. I can find stuff for the engine equivalent SceneObject::setTransform and matrices, but nothing to document the argument meanings and behaviors as used in Torque Script.
On a side note, the Finney book talks about Torque using a right-handed system. This appears to be the case when I translate objects in the x, y, and z directions using script commands. However, the one z rotation I have managed appears to be a left-handed rotation about the positive z axis. Seems to be a mixed bag. Is the true?
Any and all help gratefully appreciated.
Kristen.
#22
06/30/2008 (3:54 pm)
Looking at the player class, Player::setTransform also has this arbitrary limitation. Would it be possible to apply this fix to the player class so that you can have a player rotate and do cool stuff like say a game where you can do loop-de-loops on skates or something? 
#23
The player only being able to rotate in its Z direction is not a bug, so it can't be fixed.
It's designed this way for several reasons:
* 1. A FPS-style player doesn't need Y/X rotation.
* 2. You're saving bandwidth by only backing Z rotation.
* 3. You're simplifying collision calculations by assuming the collision box never rotates.
To remove this intended limitation, you'll have to do some poking for points 1 and 2 above, and some serious work to get point 3 working without flaws. You'll probably have to swap out ExtrudedPolyList for a ClippedPolyList, and so forth. If you got the TankPack, they got a fairly robust collision implementation involving rotation.
06/30/2008 (4:15 pm)
Quote:
Looking at the player class, Player::setTransform also has this arbitrary limitation. Would it be possible to apply this fix to the player class so that you can have a player rotate and do cool stuff like say a game where you can do loop-de-loops on skates or something?
The player only being able to rotate in its Z direction is not a bug, so it can't be fixed.
It's designed this way for several reasons:
* 1. A FPS-style player doesn't need Y/X rotation.
* 2. You're saving bandwidth by only backing Z rotation.
* 3. You're simplifying collision calculations by assuming the collision box never rotates.
To remove this intended limitation, you'll have to do some poking for points 1 and 2 above, and some serious work to get point 3 working without flaws. You'll probably have to swap out ExtrudedPolyList for a ClippedPolyList, and so forth. If you got the TankPack, they got a fairly robust collision implementation involving rotation.
#24
EDIT:
Well, I'd like to forge ahead anyway and see what happens if I allow x/y rotation as well. I've already updated pack/unpack to now send/recieve mRot.x and mRot.y, so I guess the next thing is to modify player::setTransform to pass x/y through to the setPosition call. Although I'm guessing I'll also have to modify setPosition and setRenderPosition as well, right?
Has anyone done this before?
06/30/2008 (4:33 pm)
Yea, I figured the player class might be a little more complicated to change. Oh well, time to start digging around. Thanks for the quick response.EDIT:
Well, I'd like to forge ahead anyway and see what happens if I allow x/y rotation as well. I've already updated pack/unpack to now send/recieve mRot.x and mRot.y, so I guess the next thing is to modify player::setTransform to pass x/y through to the setPosition call. Although I'm guessing I'll also have to modify setPosition and setRenderPosition as well, right?
Has anyone done this before?
#25
07/01/2008 (5:26 am)
There was some discussion about how to set pitch rotation for things like 4 legged animals that should pitch up when they climb hills. Not sure what to suggest to search for, but the threads are out there. If you don't find anything, ask. I can look through my threads. (No time this morning though.)
#26
Note that, if you allow rotation in more than 2 dimensions, you'll get into trouble. That's because the Player class is using Euler to store the rotation, and you need either QuatF or a regular MatrixF to avoid gimbal-locks.
Even after you nail that down, you still got the issues with the collision box and rotational collision which doesn't even happen in player.
07/01/2008 (5:33 am)
I've done it before, but it won't help you as these changes are less trivial than describing them in a post on a forum. You'll basically have to wade trough the whole class.Note that, if you allow rotation in more than 2 dimensions, you'll get into trouble. That's because the Player class is using Euler to store the rotation, and you need either QuatF or a regular MatrixF to avoid gimbal-locks.
Even after you nail that down, you still got the issues with the collision box and rotational collision which doesn't even happen in player.
#27
07/01/2008 (11:15 am)
The thing I don't understand is how the collision of the player can only assume rotation of Z. I figured that collision was a global code thing that can be used by any type of object, I didn't think that there was a specialized player-specific collision code. If the problem was able to be fixed with Item, why did the collision still work with Item? Are there really multiple sets of collision code depending on who needs what?
#28
If you need full rotation, you got the vehicle and all its subclasses. If you need something more simple (well, in terms of collisions..) you got the player. Combining both these classes into one huge class that can do it all wouldn't be as optimized since you can't assume what it would be used for.
07/01/2008 (11:21 am)
To optimize something, you often have to make it just a little less general and actually focus on what's important.If you need full rotation, you got the vehicle and all its subclasses. If you need something more simple (well, in terms of collisions..) you got the player. Combining both these classes into one huge class that can do it all wouldn't be as optimized since you can't assume what it would be used for.
#29
The thing I'm trying to experiment with here is something along the lines of one of those 3D sonic games where you can grind on these tracks, and I've gotten most of it to work, but currently I can't do stuff like loops unless I can make the player rotate.
07/01/2008 (11:45 am)
You bring up an interesting point with vehicles, I noticed that vehicles don't have the limitation. So then, theoretically, could I mount the player to an invisible vehicle and have the mounted animation be his normal standing animation and that would allow me to move the player however I felt like by just moving the vehicle?The thing I'm trying to experiment with here is something along the lines of one of those 3D sonic games where you can grind on these tracks, and I've gotten most of it to work, but currently I can't do stuff like loops unless I can make the player rotate.
#30
I can't recommend the TankPack enough in this case, but if you're not sure you can use the code then perhaps you should try out your idea first.
07/01/2008 (11:49 am)
You could do that, though it would be a bit ugly. I would start from there and if the gameplay turns out to be fun, start ripping vehicle apart or learn from the QuatF code in it (which isn't that much) and adapt it to Player. That's what I ended up with, back then.I can't recommend the TankPack enough in this case, but if you're not sure you can use the code then perhaps you should try out your idea first.
Torque Owner Brandon Smith