Jump to content
  • Advertisement
Sign in to follow this  
acid2

Options for handling rotation, and whats best for me?

This topic is 4858 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I'm currently trying to get rotations into my game. I am using DirectX as my API of choice, and would prefer to use the classes provided by D3DX to handle the mathematics behind all this for now. Now, what I am currently doing is storing the pitch, yaw and roll of all my entites and recalcuating a rotation matrix on move.
public void Rotate(float pitch, float yaw, float roll)
{
	rotationVals = new Vector3(pitch, yaw, roll);

	rotation = Matrix.RotationYawPitchRoll(Geometry.DegreeToRadian(yaw),
		Geometry.DegreeToRadian(pitch), Geometry.DegreeToRadian(roll));
}
public void Turn(float pitch, float yaw, float roll)
{
	rotationVals += new Vector3(pitch, yaw, roll);

	rotation = Matrix.RotationYawPitchRoll(Geometry.DegreeToRadian(rotationVals.Y),
		Geometry.DegreeToRadian(rotationVals.X), Geometry.DegreeToRadian(rotationVals.Z));
}


Now, I dont know if this works or not (I don't really know what to expect). What am I trying to do is recreate the blitz game engine, in most aspects for now. This way, I have still have the structure of an engine I'm used to using, but with code so I can extend it whenever I want. Blitz handled rotations by simply doing 'TurnEntity ent, Pitch#, Yaw#, Roll#' (# meaning a floating point number). This meant that a first person camera was setup by simply doing:
TurnEntity camera, MouseYSpeed(), MouseXSpeed(), 0
RotateEntity camera, EntityX(camera), EntityY(camera), 0  <-- stop roll.
Any ideas how I could replicate that behaviour? What are your suggestions on possibly a better way to handle rotations?

Share this post


Link to post
Share on other sites
Advertisement
There are a lot of ways to handle rotation; which to choose depends on what sort of behavior you want. I'm not familiar with blitz, so I'll just ask which (if any) of the following 'standard' camera types you're interested in.

1. FPS. There is no roll, and motion is generally constrained to a plane. Yaw is always about the world up axis, and pitch is always about the local side axis.

2. FPS 'spectator' cam. As above, except you move in the direction you're looking rather than always in the plane.

3. Free/6dof, like in Descent or other space shooters. Rotations always take place about the local axes. You can yaw, pitch, or roll, and can reach any orientation.

Given a complete description of what sort of camera behavior you want, it should be pretty easy to make some specific recommendations.

Share this post


Link to post
Share on other sites
just adding to jyk's first point - there are some cases when you want to roll the camera in a FPS, for example AVP 1/2 when your an alien you can walk on walls (or a skulk in NS)

Share this post


Link to post
Share on other sites
This isn't just for the camera though. This is all rotation in the game - the camera, the meshs, lights etc. I was hoping that it would be possible to have one solution to control all of these rotations (they all inherit from a scene graph position node).

Share this post


Link to post
Share on other sites
Quote:
Original post by acid2
This isn't just for the camera though. This is all rotation in the game - the camera, the meshs, lights etc. I was hoping that it would be possible to have one solution to control all of these rotations (they all inherit from a scene graph position node).

It might be possible to some degree. If you multiply the current orientation matrix by rotation matrix, the rotation takes place either in local space or in world space, depending on the multiplication order (current_orientation * rotation vs rotation * current_orientation)

So, you probably could have function for the node which lets you switch between local and world space separately for yaw, pitch and roll... then, when the node receives function call along the lines of "change heading by 5 degrees, change pitch by -10 degrees, leave roll as it is" it would create separate matrix for each rotation axis that's changing, and then either multiply or post-multiply current orientation matrix by these rotation matrices depending on how the node is configured to interpret changes in yaw, pitch and roll.

(if dX offers some quaternion solution out-of-the-box then could probably use these in similar manner as well)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!