rotating about an objects own origin
Author
Hi,
I wrote my own small matrix class and am drawing 3d polygons to screen. All my transforms are ok except when it comes to rotating 'in-place'.
I made a small airplane model, and added all its pieces to an assembly so I can translate the whole thing at once.
I can't understand how to get the propeller to rotate independently of the body though. I need some sort of RotateSelfX() function so I can just make it rotate about its own X-origin - any suggestions on how to start doing that?
Thanks
Generally to rotate an object about its own origin you first translate the object so that the object's origin is at 0,0,0, perform the rotation and then translate the object back.
You're rotating before any translating, right? If the origin of the propeller is the rotation pivot point, then there aren't any tricks to getting it to work. If the propeller model's origin is elsewhere, then you need to translate the propeller model to put the pivot point at location 0,0,0, apply rotation, then translate it back to the plane.
edit: Ninjad.
edit: Ninjad.
Author
I'm trying to get the plane to just fly in a circle around the world origin, and have the propeller spin at the same time.
What I did is:
1) Translate plane assembly (40,0,0)
2) RotateY(2) every animation frame so it looks like it's flying around the origin.
After steps 1 & 2 though, the vertices of my plane pieces are translated already - so I don't get how you can know how to translate each piece back to the origin to perform the rotation on the propeller piece only.
What I'm wondering is, do you guys keep your vertex list so that they're never actually modified? Something like:
1) Create unit box, vertex list is just something like:
(-1,-1,1),(-1,1,1),(1,1,1), etc...
2) The object has its own member matrix which stores whatever the current transform is on it.
3) When you apply a new transform on the object, you simply append it to the object's internal matrix, but don't modify the actual vertex values.
4) When you finally have to draw to screen, multiply the unmodified vertex list through the current transform matrix to spit out that final translated vertices, then draw them to screen.
Is that the right flow? Since right now my vertices internally keep getting modified with every transform, I can't figure how you could ever know what transform to apply to get it back to the origin.
Thanks
What I did is:
1) Translate plane assembly (40,0,0)
2) RotateY(2) every animation frame so it looks like it's flying around the origin.
After steps 1 & 2 though, the vertices of my plane pieces are translated already - so I don't get how you can know how to translate each piece back to the origin to perform the rotation on the propeller piece only.
What I'm wondering is, do you guys keep your vertex list so that they're never actually modified? Something like:
1) Create unit box, vertex list is just something like:
(-1,-1,1),(-1,1,1),(1,1,1), etc...
2) The object has its own member matrix which stores whatever the current transform is on it.
3) When you apply a new transform on the object, you simply append it to the object's internal matrix, but don't modify the actual vertex values.
4) When you finally have to draw to screen, multiply the unmodified vertex list through the current transform matrix to spit out that final translated vertices, then draw them to screen.
Is that the right flow? Since right now my vertices internally keep getting modified with every transform, I can't figure how you could ever know what transform to apply to get it back to the origin.
Thanks
The vertices are usually left untouched. One would usually send the render transformation matrix to the graphics API or vertex shader.
If you have a plane transformation matrix, you need to apply that to the propeller as well.
Here are the matrices..
- move_propeller_to_origin
This matrix translates the propeller's pivot point from wherever it is to 0,0,0.
- move_propeller_to_plane
This matrix moves the propeller pivot point from 0,0,0 to the plane's local-space pivot point (the front of the wing, I guess).
- propeller_rotate
This matrix is the local rotation applied to the propeller. The spin.
- plane_transform
This is the air-born transform of the plane itself.
propeller_transform = move_propeller_to_origin * propeller_rotate * move_propeller_to_plane * plane_transform;
That's it.
If you have a plane transformation matrix, you need to apply that to the propeller as well.
Here are the matrices..
- move_propeller_to_origin
This matrix translates the propeller's pivot point from wherever it is to 0,0,0.
- move_propeller_to_plane
This matrix moves the propeller pivot point from 0,0,0 to the plane's local-space pivot point (the front of the wing, I guess).
- propeller_rotate
This matrix is the local rotation applied to the propeller. The spin.
- plane_transform
This is the air-born transform of the plane itself.
propeller_transform = move_propeller_to_origin * propeller_rotate * move_propeller_to_plane * plane_transform;
That's it.
Author
"The vertices are usually left untouched"
ok so my object class is just going to have its initial vertex list (which are created at the world origin) and they never change. All I do is keep updating its internal transformation matrix, and when it's time to render to screen, I just run that initial vertex list through and use the temporary results for drawing. Makes sense to me.
"- move_propeller_to_origin
This matrix translates the propeller's pivot point from wherever it is to 0,0,0."
Since the propeller is getting created at the origin, I don't have to do this step, right?
"- plane_transform
This is the air-born transform of the plane itself."
I made a simple assembly class, so the body of the airplane is the parent, and then the wings, propellers, etc are the children. So I should just be able to take the transform of the body and apply it to the children - that's the way it's supposed to work right?
Thanks a lot!
ok so my object class is just going to have its initial vertex list (which are created at the world origin) and they never change. All I do is keep updating its internal transformation matrix, and when it's time to render to screen, I just run that initial vertex list through and use the temporary results for drawing. Makes sense to me.
"- move_propeller_to_origin
This matrix translates the propeller's pivot point from wherever it is to 0,0,0."
Since the propeller is getting created at the origin, I don't have to do this step, right?
"- plane_transform
This is the air-born transform of the plane itself."
I made a simple assembly class, so the body of the airplane is the parent, and then the wings, propellers, etc are the children. So I should just be able to take the transform of the body and apply it to the children - that's the way it's supposed to work right?
Thanks a lot!
Your description of the transformation process is pretty much spot-on. All that's missing is the concept of a transformation hierarchy.
If two meshes belong to the same model, but move independently (like your aircraft and propeller) then they should exist as two separate renderable objects, part of a single, larger entity. The components share the same transformations, up to a certain point on their transformation stack. In this case, you'd have a structure that looks something like this:
In the aircraft example, this would result in two meshes being rendered:
<Body Transformation><Aircraft Transformation> : Body Mesh
<Propeller Transformation><Aircraft Transformation> : Propeller Mesh
Obviously, in this case, not much has been done, but you can see how this can scale up to represent every object in the game.
If you're still a little confused, here are the details:
The two meshes represent the pieces of aircraft, in object-space. If if you rendered both without applying any transformations, you'd have a solid plane centred at the origin.
The 'Aircraft' transformation would be a translation to (40, 0, 0) followed by the incremental rotation.
The 'Body' transformation is an identity transform.
The 'Propeller' transformation is another incremental rotation about the x-axis.
The beauty of this design is that the transformations are applied in the correct order so that there is no need to translate back to the origin for the rotation. In a more general scenario, this would be necessary, but as things stand, the propeller rotation is applied in object-space before the aircraft transformation takes it to the correct location.
Admiral
If two meshes belong to the same model, but move independently (like your aircraft and propeller) then they should exist as two separate renderable objects, part of a single, larger entity. The components share the same transformations, up to a certain point on their transformation stack. In this case, you'd have a structure that looks something like this:
Aircraft { Aircraft Transformation Body { Body Transformation Body Mesh } Propeller { Propeller Transformation Propeller Mesh }}In the aircraft example, this would result in two meshes being rendered:
<Body Transformation><Aircraft Transformation> : Body Mesh
<Propeller Transformation><Aircraft Transformation> : Propeller Mesh
Obviously, in this case, not much has been done, but you can see how this can scale up to represent every object in the game.
If you're still a little confused, here are the details:
The two meshes represent the pieces of aircraft, in object-space. If if you rendered both without applying any transformations, you'd have a solid plane centred at the origin.
The 'Aircraft' transformation would be a translation to (40, 0, 0) followed by the incremental rotation.
The 'Body' transformation is an identity transform.
The 'Propeller' transformation is another incremental rotation about the x-axis.
The beauty of this design is that the transformations are applied in the correct order so that there is no need to translate back to the origin for the rotation. In a more general scenario, this would be necessary, but as things stand, the propeller rotation is applied in object-space before the aircraft transformation takes it to the correct location.
Admiral
from briefly skimming this thread it seems to me the key point you have failed to grasp is that the propeller is a separate model to the plane... rotate and move the plane etc, rotate and move the propeller to the nose of the plane... voila! a complete plane with independently moving prop.
Author
Ok thanks I understand now.
I'm just thinking I'm interpreting my matrix multiplication incorrectly. I made one blade of the propeller at the origin (it's just a cube). I used a scale transform on it to make it (100, 10, 10).
Then I rotate 90 degrees around the global Y axis. Then each animation frame I rotate around the X axis like 5 degrees.
This should make it appear as if that blade is standing right side up and you're looking at the side of the plane. The blade should be spinning around the world x-axis.
It work up until the final rotation around the X axis - it looks like the blade is getting rotated around ITS X axis, not the world X axis. My matrix class is so primitive I haven't built anything like world vs local coordinates in. I thought this is all we had to do:
final_matrix = scale_propeller * rotate_y(90) * rotate_x(5 * animation frame #);
??
Thanks
I'm just thinking I'm interpreting my matrix multiplication incorrectly. I made one blade of the propeller at the origin (it's just a cube). I used a scale transform on it to make it (100, 10, 10).
Then I rotate 90 degrees around the global Y axis. Then each animation frame I rotate around the X axis like 5 degrees.
This should make it appear as if that blade is standing right side up and you're looking at the side of the plane. The blade should be spinning around the world x-axis.
It work up until the final rotation around the X axis - it looks like the blade is getting rotated around ITS X axis, not the world X axis. My matrix class is so primitive I haven't built anything like world vs local coordinates in. I thought this is all we had to do:
final_matrix = scale_propeller * rotate_y(90) * rotate_x(5 * animation frame #);
??
Thanks
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
