I'm making a small game with a Asteroidslike physics engine. I have movement and whatnot implemented. I recently created a particle engine that spits out some red stuff that sorta looks like exhaust.
So the particle engine that I construct has an emitter location that I can define. I can easily place this location in the center of the ship, but I can't seem to figure out how to place it at the tail end of the ship where the logical place for a thruster to be.
My idea was to have a 2d vector that can hold offset and rotate that offset based on the center of the ship texture. The process makes sense when I think about it, and I believe it'll work. But I just can't seem to implement it.
I'm at work and this problem has been bothered me, and I just now decided to reach out for help. I can add code details later when I get home.
2 Replies  904 Views  Last Post: 02 October 2012  09:59 AM
#1
Need help understanding the math behind rotation.
Posted 02 October 2012  09:27 AM
Replies To: Need help understanding the math behind rotation.
#2
Re: Need help understanding the math behind rotation.
Posted 02 October 2012  09:44 AM
Here you go:
I love answering the rotation question. Incidently, I don't remember those formula's off the top of my head. I had to go look them up on my website.
http://xna3d101.co...s/Matrices.html
Incidently, I went through those formula's once, pulled them apart and did a proof to prove they work (really to understand why they work). All I can say is don't do it. It requires almost everything in a college trig book to prove them. The formulas are in the back of the book and you have to work all the way through almost everything in the trig text book back to the front in order to prove them. It's ugly ugly ugly.
Anyway, in 3D you have the nice rotation formulas inside the rotation matrices. You "could" use them by doing a zrotation matrix and then converting the vector to 3D and keeping the z at zero at all times. In otherwords, move it to 3D, rotate it using matrices, and then bring it back.
But under the hood the rotation matrices are using the formulas above. That's why you have 3 rotation matrices: the formula is 2D, so in order to rotate in 3D you have to apply the 2D formula on every axis seperately (or use quaternions).
So, the formula above is all you need. But there's a catch. If you pay close attention you will notice that the formula's above rotate around the origin (x=0,y=0). You can't really change that. All you can do is move the center of rotation to the origin, rotate, and then move it back. If you do that all before the draw, no one will ever know you moved it around. Even if you mathematically change the formulas, all you will be doing is including the movement to the origin in the formula. This also applies to rotations in 3D space as well.
You really have two rotation options and both use this same formula. One option is to orbit around a given point, and the other option is to rotate around the center. Everything else should basically be a combination of those.
If you want to orbit, move the object's orbit point back to the origin, rotate, and move it back so that the object's center of orbit goes back to the exact same spot.
If you want to spin around a center, move the center to the origin, rotate, and move it back so that the object's center goes back to the same place.
Just do your rotations between draw calls and no one will know you are moving to the origin and back.
Mathematically, this is the only way it can be done other than using something like quaternions which is totally inappropriate for this. You use quaternions for 3D rotation due to specific problems that occur in 3D only.
P.S. Oh. You could make a vector for the offset and rotate the vector (which always has it's tail at the origin) using these formulas. I would keep the vector normalized (length of one) so that it only represents a direction and not an amount.
If you add that offset vector to the position vector your answer will be a vector that contains the position at the offset.
(I wonder what they were thinking when they failed to include a 2D rotation method in XNA...)
Oh. And don't forget that TurnAngle above is measured in radians.
public Vector2 RotatePoint(float X, float Y, float TurnAngle) { Vector2 Result Result.x = X * (float)Math.Cos(TurnAngle)  Y * (float)Math.Sin(TurnAngle); Result.y = X * (float)Math.Sin(TurnAngle) + Y * (float)Math.Cos(TurnAngle); return Result; } public Vector2 RotatePoint(Vector2 VectorToRotate, float TurnAngle) { Vector2 Result Result.x = VectorToRotate.X * (float)Math.Cos(TurnAngle)  VectorToRotate.Y * (float)Math.Sin(TurnAngle); Result.y = VectorToRotate.X * (float)Math.Sin(TurnAngle) + VectorToRotate.Y * (float)Math.Cos(TurnAngle); result Result; }Problem solved. :)
I love answering the rotation question. Incidently, I don't remember those formula's off the top of my head. I had to go look them up on my website.
http://xna3d101.co...s/Matrices.html
Incidently, I went through those formula's once, pulled them apart and did a proof to prove they work (really to understand why they work). All I can say is don't do it. It requires almost everything in a college trig book to prove them. The formulas are in the back of the book and you have to work all the way through almost everything in the trig text book back to the front in order to prove them. It's ugly ugly ugly.
Anyway, in 3D you have the nice rotation formulas inside the rotation matrices. You "could" use them by doing a zrotation matrix and then converting the vector to 3D and keeping the z at zero at all times. In otherwords, move it to 3D, rotate it using matrices, and then bring it back.
But under the hood the rotation matrices are using the formulas above. That's why you have 3 rotation matrices: the formula is 2D, so in order to rotate in 3D you have to apply the 2D formula on every axis seperately (or use quaternions).
So, the formula above is all you need. But there's a catch. If you pay close attention you will notice that the formula's above rotate around the origin (x=0,y=0). You can't really change that. All you can do is move the center of rotation to the origin, rotate, and then move it back. If you do that all before the draw, no one will ever know you moved it around. Even if you mathematically change the formulas, all you will be doing is including the movement to the origin in the formula. This also applies to rotations in 3D space as well.
You really have two rotation options and both use this same formula. One option is to orbit around a given point, and the other option is to rotate around the center. Everything else should basically be a combination of those.
If you want to orbit, move the object's orbit point back to the origin, rotate, and move it back so that the object's center of orbit goes back to the exact same spot.
If you want to spin around a center, move the center to the origin, rotate, and move it back so that the object's center goes back to the same place.
Just do your rotations between draw calls and no one will know you are moving to the origin and back.
Mathematically, this is the only way it can be done other than using something like quaternions which is totally inappropriate for this. You use quaternions for 3D rotation due to specific problems that occur in 3D only.
P.S. Oh. You could make a vector for the offset and rotate the vector (which always has it's tail at the origin) using these formulas. I would keep the vector normalized (length of one) so that it only represents a direction and not an amount.
If you add that offset vector to the position vector your answer will be a vector that contains the position at the offset.
(I wonder what they were thinking when they failed to include a 2D rotation method in XNA...)
Oh. And don't forget that TurnAngle above is measured in radians.
This post has been edited by BBeck: 02 October 2012  09:59 AM
#3
Re: Need help understanding the math behind rotation.
Posted 02 October 2012  09:59 AM
Thanks BBeck,
I think I'm going to have to read this reply a couple times in front of the project to really understand...but I believe you've sent me on the right track. Thanks!
I think I'm going to have to read this reply a couple times in front of the project to really understand...but I believe you've sent me on the right track. Thanks!
Page 1 of 1
