Gamestudio Links
Zorro Links
Newest Posts
Help with plotting multiple ZigZag
by degenerate_762. 04/30/24 23:23
M1 Oversampling
by 11honza11. 04/30/24 08:16
Trading Journey
by howardR. 04/28/24 09:55
Zorro Trader GPT
by TipmyPip. 04/27/24 13:50
Data from CSV not parsed correctly
by jcl. 04/26/24 11:18
AUM Magazine
Latest Screens
The Bible Game
A psychological thriller game
SHADOW (2014)
DEAD TASTE
Who's Online Now
3 registered members (AndrewAMD, Quad, M_D), 1,217 guests, and 1 spider.
Key: Admin, Global Mod, Mod
Newest Members
firatv, wandaluciaia, Mega_Rod, EternallyCurious, howardR
19050 Registered Users
Previous Thread
Next Thread
Print Thread
Rate Thread
Page 2 of 2 1 2
Re: Rotation speed [Re: theDust] #257789
03/25/09 14:44
03/25/09 14:44
Joined: Feb 2008
Posts: 3,232
Australia
EvilSOB Offline
Expert
EvilSOB  Offline
Expert

Joined: Feb 2008
Posts: 3,232
Australia
As far as I know, NOT if you get this info by using the VEC_DIFF function.
By my understanding it effectivly "ignores" the odd switching between +180 and -180,
because both the vectors get treated the same way.

IF I am wrong, use this formula to get the vec_diff instead.
It will remove the problem of the source angles going negative, but it wont
interfere in the difference between them.
Code:
VECTOR Old_Rot, Now_Rot, Rot_Speed;
vec_set(Old_Rot, my.pan);
vec_add(Old_Rot, vector(360,360,360));  //eliminate negative angles
wait(1);
vec_set(Now_Rot, my.pan);
vec_add(Now_Rot, vector(360,360,360));    //eliminate negative angles
vec_diff(Rot_Speed, Old_Rot, Now_Rot);
Can you see what I mean?
Remember that while these values are being stored in a manually created VECTOR,
they wont be treated as angles, and therefore wont suffer the +180, -180 clipping.



"There is no fate but what WE make." - CEO Cyberdyne Systems Corp.
A8.30.5 Commercial
Re: Rotation speed [Re: EvilSOB] #257918
03/26/09 14:34
03/26/09 14:34
Joined: Mar 2008
Posts: 104
theDust Offline OP
Member
theDust  Offline OP
Member

Joined: Mar 2008
Posts: 104
Hmmm...when I look at the Now_Rot.x, its working sometimes, but often it switches to 300 and something (way to high) and has the wrong sign. But what are the other 2 values in the Now_Rot vector meaning ? Have they any sense ?

Ok always important to know:
-roll and pan are going from 0 to 180 then -180 to 0.
-Tilt is going from 0 to 90 to 0 to -90 to 0. (and it seems impossible to me to calculate the correct direction here)

Re: Rotation speed [Re: theDust] #257974
03/26/09 22:40
03/26/09 22:40
Joined: Feb 2008
Posts: 3,232
Australia
EvilSOB Offline
Expert
EvilSOB  Offline
Expert

Joined: Feb 2008
Posts: 3,232
Australia
Quote:
Hmmm...when I look at the Now_Rot.x, its working sometimes, but often it switches to 300 and something (way to high) and has the wrong sign.
Dont worry about Now_Rot or Old_Rot jumping to the higher values, its not important. VEC_DIFF "corrects" those
odd values before doing its difference'ing. So Rot_Speed will be correct, even if Now_Rot or Old_Rot look
wrong(or very different), thats why the VEC_ADD lines in my code are OPTIONAL.
To see see Now_Rot and Old_Rot as real angles(-180 to +180), use this code instead.
Code:
VECTOR Old_Rot, Now_Rot, Rot_Speed;
vec_set(Old_Rot, my.pan);   //Start Euler ANGLE in degrees (not speed)
vec_set(Old_Rot, vector(ang(Old_Rot.x),ang(Old_Rot.y),ang(Old_Rot.z)));  //(optional) CORRECT odd looking angles to -180 to +180 range
wait(1);
vec_set(Now_Rot, my.pan);   //Current Euler ANGLE in degrees (not speed)
vec_set(Now_Rot, vector(ang(Now_Rot.x),ang(Now_Rot.y),ang(Now_Rot.z)));  // (optional) CORRECT odd looking angles to -180 to +180 range
vec_diff(Rot_Speed, Old_Rot, Now_Rot);
vec_set(Rot_Speed, vector(ang(Rot_Speed.x),ang(Rot_Speed.y),ang(Rot_Speed.z)));  // (optional) CORRECT odd looking angles to -180 to +180 range


BTW those odd values are just "the correct value" with 180 spuriously(?) added or subtracted,
because they are being treated as generic vectors, rather than angles.

Just remember, in BOTH of my code samples, the VEC_ADD lines are optional just to improve the LOOK
of Old_Rot and Now_Rot, they are just eating horsepower if you dont need to VISUALLY use these values later.
Even though the numbers may LOOK weird without the VEC_ADD or ANG() changes, the engine handles them perfectly correctly.


Quote:
But what are the other 2 values in the Now_Rot vector meaning ? Have they any sense ?
AND
-Tilt is going from 0 to 90 to 0 to -90 to 0. (and it seems impossible to me to calculate the correct direction here)
The other two values are the tilt and roll values. They apply right through the calculations.
So Rot_Speed.X is how fast the PAN is rotating, + is rotating clockwise, - is rotating anti-clockwise.
So Rot_Speed.Y is how fast the TILT is changing, + is going up(higher), - is going down(flatter).
So Rot_Speed.Z is how fast the ROLL is changing, + is rolling clockwise around its own X axis), - is anti-clockwise.

Footnote: Tilt CAN go beyond +/-90. Think of it like this, between 0 and +/-90, the pan is leaning forwards,
but beyond 90 its leaning backwards, and when that happens, pan and roll will appear reversed.
Imagine .... Tilt=0 is looking straight ahead, +90 is straight up(you see sky), -90 is straight down(you see feet),
(tricky part) -120 is looking between your knees(seeing the ground behind you),
(trickier part) +120 is looking behind you by leaning backward(seeing the sky behind you).



Quote:
Ok always important to know:
-roll and pan are going from 0 to 180 then -180 to 0.
Correct, but thats only half of the truth.
And a tricky one but once you understand, your problems of the odd numbers will all make sense.

## IMPORTANT ## - Understanding this will make everything else make sense and easier to follow.
Rotation degrees go from -180 to +180, right?
So that means 0 is straight ahead, 90 is true right, -90 is true left, and +180 and -180 are BOTH straight behind.
CORRECT......But... in other types of mathematic situations
Rotation degrees go from 0 to 360.
So that means 0 is straight ahead, 90 is true right, 180 is straight behind, 270 is true left, and 360 is straight ahead too.
BOTH correct. Here is an attempt to make a visual representation of the two views side-by-side.
Code:
ANGLE   -180    -90     0     +90     +180
          |------|------+------|--------|   
VECTOR   180    270   0/360    90      180  

can also be viewed as

ANGLE       0         +90      +/-180       -90           0
            |----------|----------+----------|------------|   
VECTOR    0/360        90        180        270         0/360
Now do you see where the odd numbers were coming from?
The odd numbers you are seeing is when the two types of mathematic representations overlap.
But VEC_DIFF converts both vectors to the same type before it calculates.


I hope this is of some help...




"There is no fate but what WE make." - CEO Cyberdyne Systems Corp.
A8.30.5 Commercial
Re: Rotation speed [Re: EvilSOB] #258271
03/29/09 12:12
03/29/09 12:12
Joined: Mar 2008
Posts: 104
theDust Offline OP
Member
theDust  Offline OP
Member

Joined: Mar 2008
Posts: 104
Thank you for the extensive explanation smile
The calculation is working ! But when my object is using physics (a must-have in my project ^^) the Rot_Speed has nearly random values and random sign. And now I have really no clue why the physics let the calculation go wrong. Im afraid that I don't find a solution here frown

Re: Rotation speed [Re: theDust] #258290
03/29/09 14:22
03/29/09 14:22
Joined: Feb 2008
Posts: 3,232
Australia
EvilSOB Offline
Expert
EvilSOB  Offline
Expert

Joined: Feb 2008
Posts: 3,232
Australia
I cant help there Im afraid. I have no experience with the physics.
MAYBE, physics causes different 'frames' to have severely different durations,
so try this addendum to the end of my code and see if it smooths things out.
Code:
...
vec_set(Rot_Speed, vector(ang(Rot_Speed.x),ang(Rot_Speed.y),ang(Rot_Speed.z)));  // (optional) CORRECT odd looking angles to -180 to +180 range
vec_scale(Rot_Speed, time_step); //or vec_scale(Rot_Speed, (1/time_step));



Any Physics gurus listening in on this issue?


"There is no fate but what WE make." - CEO Cyberdyne Systems Corp.
A8.30.5 Commercial
Re: Rotation speed [Re: EvilSOB] #258329
03/29/09 18:49
03/29/09 18:49
Joined: Mar 2008
Posts: 104
theDust Offline OP
Member
theDust  Offline OP
Member

Joined: Mar 2008
Posts: 104
Originally Posted By: EvilSOB
MAYBE, physics causes different 'frames' to have severely different durations,

Thats a good idea ! So, unfortunately the additional code does not very much, but maybe we found the problem, a time displacement in the calculation, caused of the physics. Its the only logical reason that comes in my mind.

Yes, a physic guru would be great smile (Maybe should I post in physics-section ?)

Re: Rotation speed [Re: theDust] #258373
03/30/09 03:41
03/30/09 03:41
Joined: Feb 2008
Posts: 3,232
Australia
EvilSOB Offline
Expert
EvilSOB  Offline
Expert

Joined: Feb 2008
Posts: 3,232
Australia
Post a link back to this thread, asking something like
"can using physics cause difficulties measuring entity rotational speeds?"
And include a bit more of your problem, and link back to the top of this thread.


"There is no fate but what WE make." - CEO Cyberdyne Systems Corp.
A8.30.5 Commercial
Page 2 of 2 1 2

Gamestudio download | chip programmers | Zorro platform | shop | Data Protection Policy

oP group Germany GmbH | Birkenstr. 25-27 | 63549 Ronneburg / Germany | info (at) opgroup.de

Powered by UBB.threads™ PHP Forum Software 7.7.1