Page 1 of 1
3D rotation
Posted: Thu Apr 16, 2020 4:51 am
by StarBootics
Hello everyone,
In order to animate a mesh I have to calculate a transformation matrix and I know how to do that. What I'm currently struggling is how to get the angles (Pitch and Yaw) of the rotation axis. So let's have a normalized 3D vector (x, y, z), to get the Pitch angle I'm using
Code: Select all
PokeF(*Pitch_Float, ASin(*This\y))
and for the Yaw
Code: Select all
PokeF(*Yaw_Float, ATan2(*This\x, *This\z))
The problem is if the rotation axis happen to be the Z axis, I got a 90 degrees of rotation around the Y axis and that the problem. I can solve this by simply doing this
Code: Select all
PokeF(*Yaw_Float, ATan2(*This\z, *This\x))
But I'm not sure about this because ATan2() always return a value between -
#PI and +
#PI.
Any suggestion ?
Best regards
StarBootics
Re: 3D rotation
Posted: Thu Apr 16, 2020 8:13 am
by Michael Vogel
In the english Wikipedia article some formulas are missing, so maybe you'd have a look at the german
entry.
Do you have an example vector where you are unsure about the results?
Re: 3D rotation
Posted: Thu Apr 16, 2020 12:14 pm
by StarBootics
Michael Vogel wrote:Do you have an example vector where you are unsure about the results?
Not yet, I'm in pure theory right now but I'm try to code a general case that work every times without worrying about reversing the animation angle of rotation. The animations in question are about folding wings and such.
Maybe I will figure out the problems after putting the code to the test.
Thanks for the link.
Best regards
StarBootics
Re: 3D rotation
Posted: Sun May 10, 2020 9:36 am
by gnasen
I wrote a c++ library some time ago relying on various representations of 3D rotations between which you can change:
- euler angles
- axis-angle
- rotation matrix
You can find it
here, just check out the file libShc\src\Shc_interface_conversions.cpp and take what you need from the 6 conversions.
Re: 3D rotation
Posted: Thu May 14, 2020 1:17 am
by Olliv
Before normalizing, you copy your vector, then you pitch with 45 degrees, then you yaw with 45 degrees.
Then you get logically two normalized vectors.
Note that the pitch/yaw shift order depends directly from the initial pitch/yaw order required to build the vector.
Consider the parity of the quantity of all the zeros between each of the 3 vector components : if yes or no, so swap or no.
And be careful about the headaches after my suggesting : you did not talk about a rolling movement...
Re: 3D rotation
Posted: Fri Jun 05, 2020 3:50 pm
by Olli
@Starbootics
Unhappily, I won't have lots of time to download, update and upload my own source code. But I insure you it is very easy.
It just is technical details of the pre-LTS versions language. Not math update.
All sprite functions had a suffixe before.
i.e. :
DisplaySprite3D() ; before
became just
DisplaySprite() ; now on LTS versions
Any #PB constants also to replace from direct value.
And the very simple 2Ddrawing texture you have to change : now it is simpler, you draw directly in the Sprite !
You have the DesktopDepth(0) to replace by 32 for Linux. Also Idle added the TransformSprite() argument update (2nd code in the subject) to update, for Linux too.
The best and easier is execute old compiler version to see it immediately before updating.
No quaternion, as you ask in this subject.
This will be allow you to check if I come to write non-senses or not in my last message above.
viewtopic.php?f=12&t=45534
Re: 3D rotation
Posted: Fri Jun 05, 2020 4:59 pm
by StarBootics
Olli wrote:@Starbootics
Unhappily, I won't have lots of time to download, update and upload my own source code. But I insure you it is very easy.
It just is technical details of the pre-LTS versions language. Not math update.
All sprite functions had a suffixe before.
i.e. :
DisplaySprite3D() ; before
became just
DisplaySprite() ; now on LTS versions
Any #PB constants also to replace from direct value.
And the very simple 2Ddrawing texture you have to change : now it is simpler, you draw directly in the Sprite !
You have the DesktopDepth(0) to replace by 32 for Linux. Also Idle added the TransformSprite() argument update (2nd code in the subject) to update, for Linux too.
The best and easier is execute old compiler version to see it immediately before updating.
No quaternion, as you ask in this subject.
This will be allow you to check if I come to write non-senses or not in my last message above.
viewtopic.php?f=12&t=45534
To be honest I don't know where you are going with your ski in the bathtub...
I'm working with 3D meshes not 2D sprites. You are completely off topic.
Sorry ...
StarBootics
Re: 3D rotation
Posted: Fri Jun 05, 2020 9:25 pm
by Olli
Reading your question, there is no link between angles calculated, no polarity, nothing, just a scale change artefact...
And to correct the scales, axis by axis, in a specific order, this code seems to be anymore.
Sorry for rust on the bathtub !
This code animates the mesh cube, by the 6 rotations (3 absolute ones + 3 relative ones).
You do not talk about the 3-axis interpolating angles neither...
This code finally answer perfectly to your question which is even very partial.
I was near to draw it on opengl gadget. Happily, I did not !
But I think you maybe found the answer now...
Re: 3D rotation
Posted: Sat Jun 06, 2020 10:54 am
by Olli
StarBootics wrote:Hello everyone,
In order to animate a mesh I have to calculate a transformation matrix and I know how to do that. What I'm currently struggling is how to get the angles (Pitch and Yaw) of the rotation axis. So let's have a normalized 3D vector (x, y, z), to get the Pitch angle I'm using
Code: Select all
PokeF(*Pitch_Float, ASin(*This\y))
and for the Yaw
Code: Select all
PokeF(*Yaw_Float, ATan2(*This\x, *This\z))
The problem is if the rotation axis happen to be the Z axis, I got a 90 degrees of rotation around the Y axis and that the problem. I can solve this by simply doing this
Code: Select all
PokeF(*Yaw_Float, ATan2(*This\z, *This\x))
But I'm not sure about this because ATan2() always return a value between -
#PI and +
#PI.
Any suggestion ?
Best regards
StarBootics
First, I copy the 1st lines in my rusted source code :
Code: Select all
Structure OIJK
Ox.D: Oy.D: Oz.D
Ix.D: Iy.D: Iz.D
Jx.D: Jy.D: Jz.D
Kx.D: Ky.D: Kz.D
EndStructure
If I reset rightly this structure, I get a 3D referency.
I can see 3 math op in your question.
So certainly, the code will have this "structure" :
Code: Select all
Define R0.OIJK = RefReset()
R1.OIJK = MathOp1(R0)
R2.OIJK = MathOp2(R1)
R3.OIJK = MathOp3(R2)
We link all, like a rusted gimbal. But I do not talk about X, Y or Z, but just about 1st, 2nd and 3rd math op.
Does it seem logic ? (because I am not perfect !)