Rotation and transform
by Howard Dortch · in Torque 3D Professional · 05/13/2010 (7:00 am) · 8 replies
I am sure this has been asked before but I can't find it.
I have an object I place in the world. The object has a rotation value like "0 0 1 180". The object will rotate at some angle during the game (it's a door). For editing purposes I sometimes save the mission with the door open and consequently it's wrong when I run the game again. When I add the door to the game I copy the rotation value and set a field called baseRotation so during the onAdd method I can be sure the door is at the proper orientation.
Now when the game loads I get the baseRotation and use that to setTransform() so here is the issue.
The objects have a rotation using degrees and the setTransform wants radians. Seems to be a big disconnect there. Either make all things degrees or make them all radians.
I find I have to get the baseRotation (in degrees) then getword(%rot,3) convert that to raidians to setTransform.
Can someone explain why we have to do this or is there a easier way?
I have an object I place in the world. The object has a rotation value like "0 0 1 180". The object will rotate at some angle during the game (it's a door). For editing purposes I sometimes save the mission with the door open and consequently it's wrong when I run the game again. When I add the door to the game I copy the rotation value and set a field called baseRotation so during the onAdd method I can be sure the door is at the proper orientation.
Now when the game loads I get the baseRotation and use that to setTransform() so here is the issue.
The objects have a rotation using degrees and the setTransform wants radians. Seems to be a big disconnect there. Either make all things degrees or make them all radians.
I find I have to get the baseRotation (in degrees) then getword(%rot,3) convert that to raidians to setTransform.
Can someone explain why we have to do this or is there a easier way?
#2
So am I unfortunately, so I wont try to explain it other then the 50 thousand feet over view.
How it's generally done is to create an animation of the door opening and play it when you want the door to open.
If you're not comfortable with creating an animation you could always just create your own rotation function which takes the item and degree's converts them to radians and then applies them to the item.
pesudo-code
Something similar to that, I'd check it but I'm not near a computer with torque atm...
05/17/2010 (7:34 pm)
I can tell you're more of a programmer then a graphic artist. So am I unfortunately, so I wont try to explain it other then the 50 thousand feet over view.
How it's generally done is to create an animation of the door opening and play it when you want the door to open.
If you're not comfortable with creating an animation you could always just create your own rotation function which takes the item and degree's converts them to radians and then applies them to the item.
pesudo-code
function convert(%obj, %degrees){
%rawTransform = %obj.getTransform();
%transform = rawTransform.getWord(0, 5);
%radians = %degrees / 57.2957795;
%obj.setTransform(%transform, %radians);
}Something similar to that, I'd check it but I'm not near a computer with torque atm...
#3
05/17/2010 (7:58 pm)
Well I was just using the door as an example, the point was when you add things in the editor they are in degrees but the get and set transform is in radians. Wondered if there was a reason for that, did the devs miss something or was it intentional making us convert on the fly as needed.
#4
But that's just a guess.
05/18/2010 (4:15 am)
My guess would be they were added at diffrent times by diffrent people.But that's just a guess.
#5
Instead of manually copying the value of the "rotation" box to a scripted variable in the editor, I'd suggest that the object in question do this work in script when created by the editor. Alternatively, you could modify the editor scripts to not do the translation to degrees in the first place.
05/18/2010 (9:07 am)
My guess is that the editor is translating these values itself, since it has to be using the getTransform function itself to obtain the values it's displaying. It would be doing this simply because radians written in decimal form are unreadable to most users in any practical sense. So, its rotation value when created is still in radians, it's just the "rotation" box that's showing degrees.Instead of manually copying the value of the "rotation" box to a scripted variable in the editor, I'd suggest that the object in question do this work in script when created by the editor. Alternatively, you could modify the editor scripts to not do the translation to degrees in the first place.
#6
Thanks to all...
05/18/2010 (9:26 am)
I will just write the code to get real radian values. I use markers at different locations in the zone and I can set different objects at different markers on creation so I get the marker rotation to set the transform of the object when I create it so I guess the simple way would be to get the transform of the marker and use that.Thanks to all...
#7
With:
Here's a link to some TorqueScript math functions.
05/18/2010 (10:48 am)
In Jacob's example you could replace:%radians = %degrees / 57.2957795;
With:
%radians = mDegToRad(%degrees);
Here's a link to some TorqueScript math functions.
#8
Spitting out values, however, they become unreadable. So when it comes to giving the user info, it looks better in Degrees. When it takes in info, radians are simpler. It becomes tricky when trying to fetch and store angle measurements rapidly, but the trade-off is readability and sanity on the engine side.
There was always that kid in Trig class who would refuse to embrace radians and cling to degrees like a zealot. They usually got really frustrated having to add strange constants and dividing numbers by Pi BEFORE even perfoming any cos/sin operations.
05/20/2010 (2:37 pm)
Any time you're doing trigonometry, radians end up being smaller and easier to deal with (sin, cos). The editor and engine uses immense amounts of trig, so leaving it in radians makes sense.Spitting out values, however, they become unreadable. So when it comes to giving the user info, it looks better in Degrees. When it takes in info, radians are simpler. It becomes tricky when trying to fetch and store angle measurements rapidly, but the trade-off is readability and sanity on the engine side.
There was always that kid in Trig class who would refuse to embrace radians and cling to degrees like a zealot. They usually got really frustrated having to add strange constants and dividing numbers by Pi BEFORE even perfoming any cos/sin operations.
Torque 3D Owner Howard Dortch
Default Studio Name