Rotation speed

Hi, I need the rotation speed (x,y,z-vector) of an object. I know how to calculate speed in general:

The problem is that the pan, roll and tilt takes values that are going up and down and up and down (0=>360=>0 or 0=>90=>0=>-90 or 0=>180=>-180=>0). It's not possible to calculate the right speed then. Any idea ?

You only need the difference of both values.

abs() gives you always the positive value, independently of the sign of your value.

"speedX = abs(my.pan - copy); "

Additionally you can also use ang() to shift the angles into an -180 to 180 range.
See: http://www.conitec.net/beta/avar-ang.htm

Ok, but I need the exact vector. For example:
x: 0,5 y: -0,3 z: 0,1
A negative rotation is needed to know if the object is turning the other way.

"tilt" is a bit weird, it goes:
0 up to 179.999 and then it switchs to -179.999 and then up to 0 again. So the difference is wrong when one variable is in the positive area and one in the negative. For example:
copy = 179
my.pan = -160
speedX = abs(my.pan - copy);
SpeedX is 339 then.

It's all a bit more complex as it seems

abs() gives you the amount of the speed.
sign() gives you the sign.

Maybe, you can explain what you want to achieve in the end.
As long as you speak of speed, I understand that you want to know an amount, because minus or plus is about the 'direction' of a speed.

To get the differences of whole vector:

vec_set(vector_of_copied_speed, my.pan);
wait(1);
vec_diff(vector_of_speed, vector_of_copied_speed, my.pan);

Oh sorry, I see...I want the speed and the direction in one ^^
x: 0,5 y: -0,3 z: 0,1
0,5 rotation speed in x-direction, -0.3 rotation speed in y-direction and 0.1 rotation speed in y-direction.
Hmmm...is that possible ?

Its already there using Pappenheimer's vec_diff. Lets say the result of the formula is like so.
vector_of_speed.x = -5
vector_of_speed.y = 10
vector_of_speed.z = 15
That means the object has a
X-SPEED = rotating at 5 degrees per frame.(because abs(X) = 5)
X-DIRECTION = rotating anti-clockwise (because X is a negative number)
Y-SPEED = tilting at 10 degrees per frame.(because abs(Y) = 10)
Y-DIRECTION = tilting clockwise(upwards?) (because Y is a positive number)
Z-SPEED = tilting at 15 degrees per frame.(because abs(Z) = 15)
Z-DIRECTION = rolling clockwise (because Z is a positive number)

vec_set(vector_of_copied_speed, my.pan) creates really weird values, not very usefull ^^

With "speed = abs(my.pan - copy)" I can't get the direction, but its the (only ?) way to calculate the speed. And tilt and roll are again different things, with values that are not only going down and up but that are jumping around.

It's possible to calculate the speed and direction without pan, tilt and roll ? Cause these properties are behaving very unhandy.

Not really, because pan, tilt, and roll ARE the rotation you are trying to measure.
So how can we measure anything if we ignore them?

Try taking a step back, and try to get the problem sorted out for JUST pan.
And extend the coding to tilt and roll only after PAN is working.

Also, try re-phrasing your question again. I think all us "experts" may have mis-understood
what it is that you actually want.
Do you want to find out how fast it is turning?
OR
Do you want to know its speed IN-SPACE, as in a sum of SpeedX & SpeedY & SpeedZ = TrueSpeed?
(that is its speed as a true distance, as-the-crow-flies)

Ok, taking a step back is a good idea At the end I want a vector that does exactly this what you wrote:

X-SPEED = rotating at 5 degrees per frame.(because abs(X) = 5)
X-DIRECTION = rotating anti-clockwise (because X is a negative number)
Y-SPEED = tilting at 10 degrees per frame.(because abs(Y) = 10)
Y-DIRECTION = tilting clockwise(upwards?) (because Y is a positive number)
Z-SPEED = tilting at 15 degrees per frame.(because abs(Z) = 15)
Z-DIRECTION = rolling clockwise (because Z is a positive number)

(The speed in-space is already done ^^)

Ok, we can get the speed of the rotation (of pan) and we need abs() for that. But the direction of the speed cannot be calculated with this method, because the differents between the pan's can be negative or positive, independently from the direction.

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.
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.

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)

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.
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.


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).


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.
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...

Thank you for the extensive explanation
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

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.

Any Physics gurus listening in on this issue?

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 (Maybe should I post in physics-section ?)

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.