I have a head tracker. It outputs these values for yaw, pitch and roll: http://pastebin.com/D31PRgud

This data being plotted(notice the yaw discrete behaviour between 7 and 8):

What would a basic working code for xna look like to make a camera rotate the same way the headtracker does?

I tried a lot, mind you. But as I couldn't succeed, I prefer a basic working structure I can work with over tinkering with my code.

## 2 Replies - 1306 Views - Last Post: 24 November 2013 - 05:39 AM

### #1

# Transferring headtracker movement to camera movement

Posted 24 November 2013 - 03:59 AM

##
**Replies To:** Transferring headtracker movement to camera movement

### #2

## Re: Transferring headtracker movement to camera movement

Posted 24 November 2013 - 05:10 AM

I can't code it off the top of my head; I would have to play with the code a bit. However, I can tell you what I would do.

First, the camera is done with CreateLookAt. That takes 3 parameters. The first is the camera position. The second is a place that the camera looks at. One trick on that is to use a vector (arrow) that is attached to the camera position. So, the vector points in the direction that the camera looks at and by adding it to the position you can control which direction the camera looks rather than what spot it looks at. And then the 3rd parameter is "Up". That's a vector that points "Up". "Up" can be down or to the left or any direction imaginable. A better term for it might be "Above the camera". It's just a vector that points in the direction that is above the camera. The "Up" parameter can be exceptionally forgiving except when you're doing something like what you're doing there.

So, I think the data you are getting is pitch, yaw, roll angles.

For a couple of reasons, I would probably use a Quaternion. One of the reasons is that it has a CreateFromYawPitchRoll method.

A quaternion here will be used almost exactly like a rotation matrix. Normally you would use a rotation matrix to hold the camera or object's attitude. You just use a quaternion instead. Position and scale are still stored in the object's world matrix, or in the case of a camera you would not have scale and it is the view matrix instead of a world matrix.

So, you create a Vector3.Forward and then you load up a quaternion with the yaw, pitch, and roll values (I always say pitch, yaw, roll; so don't get the order confused when loading it up.) Then you rotate that Vector3 you just created using the quaternion. You can create a rotation matrix from a quaternion.

Now that I look at this, I see you can create a rotation matrix directly from yaw, pitch, roll. So: 6 of 1 and half a dozen of the other.

The advantage that I see on the quaternion is that you can simply pitch it up 90 degrees to get your up vector. I would expect that to work a bit more reliably than with the rotation matrix. But again, I would have to play with this stuff a bit.

Anyway, there are a couple of "tricks" that you should be aware of. The first is that the "camera", or view matrix, is an inverted matrix. So, you have to invert and un-invert when you are working directly with it.

The second is that the order of multiplication with these matrices makes a

I have some code you can look at that might help. Here is a quaternion example; look at the "Tiles and Quaternions" example. And then the "Matrices in Motion" example code will show you some examples of working with matrices. I don't think what you're doing is that much different except that you seem to be feeding it yaw, pitch, roll values directly.

I generally don't like working with yaw, pitch, roll. But once you create your rotation matrix using yaw, pitch, roll, it shouldn't be any different than a rotation matrix that you created with another method. Understanding how to control the camera by itself is the key here, I think.

First, the camera is done with CreateLookAt. That takes 3 parameters. The first is the camera position. The second is a place that the camera looks at. One trick on that is to use a vector (arrow) that is attached to the camera position. So, the vector points in the direction that the camera looks at and by adding it to the position you can control which direction the camera looks rather than what spot it looks at. And then the 3rd parameter is "Up". That's a vector that points "Up". "Up" can be down or to the left or any direction imaginable. A better term for it might be "Above the camera". It's just a vector that points in the direction that is above the camera. The "Up" parameter can be exceptionally forgiving except when you're doing something like what you're doing there.

So, I think the data you are getting is pitch, yaw, roll angles.

For a couple of reasons, I would probably use a Quaternion. One of the reasons is that it has a CreateFromYawPitchRoll method.

**Don't try and figure out what a quaternion is.**That's a good way to fry your brain. And maybe I'm throwing too much at you too quickly, if you're not familiar with this stuff. I think most game programmers haven't the foggiest clue how to use a quaternion. But this is actually real simple, which is the reason I would be inclined to do it this way.A quaternion here will be used almost exactly like a rotation matrix. Normally you would use a rotation matrix to hold the camera or object's attitude. You just use a quaternion instead. Position and scale are still stored in the object's world matrix, or in the case of a camera you would not have scale and it is the view matrix instead of a world matrix.

So, you create a Vector3.Forward and then you load up a quaternion with the yaw, pitch, and roll values (I always say pitch, yaw, roll; so don't get the order confused when loading it up.) Then you rotate that Vector3 you just created using the quaternion. You can create a rotation matrix from a quaternion.

Now that I look at this, I see you can create a rotation matrix directly from yaw, pitch, roll. So: 6 of 1 and half a dozen of the other.

The advantage that I see on the quaternion is that you can simply pitch it up 90 degrees to get your up vector. I would expect that to work a bit more reliably than with the rotation matrix. But again, I would have to play with this stuff a bit.

Anyway, there are a couple of "tricks" that you should be aware of. The first is that the "camera", or view matrix, is an inverted matrix. So, you have to invert and un-invert when you are working directly with it.

The second is that the order of multiplication with these matrices makes a

**huge**difference.I have some code you can look at that might help. Here is a quaternion example; look at the "Tiles and Quaternions" example. And then the "Matrices in Motion" example code will show you some examples of working with matrices. I don't think what you're doing is that much different except that you seem to be feeding it yaw, pitch, roll values directly.

I generally don't like working with yaw, pitch, roll. But once you create your rotation matrix using yaw, pitch, roll, it shouldn't be any different than a rotation matrix that you created with another method. Understanding how to control the camera by itself is the key here, I think.

### #3

## Re: Transferring headtracker movement to camera movement

Posted 24 November 2013 - 05:39 AM

The problem with CreateFromYawPitchRoll is that rotation is way too fast. Rotating the headtracker around 10 degrees makes the camera spin almost 720 degrees. These are not mathematical values, mind you.

Also your computation does not seem to take the sudden change in value into account that I mentioned.

Also your computation does not seem to take the sudden change in value into account that I mentioned.

Page 1 of 1