
In my previous post I simply checked the orientation of the two IR points to determine if the Wiimote is upside down. After playing around a bit I noticed something strange. If I moved the Wiimote off the screen and then back on the screen sometimes the two points would reverse and the pointer image would flip upside down. Apparently the order of the IR points depends on which one the Wiimote registers first, not how they appear on screen. So you can hold the Wiimote perfectly horizontal, move it down off screen and back up and (what are the blue and red indicators in the above screenshot) will flip position.
So that method doesn’t actually work. What does work is even simpler: the roll angle is the atan of the z acceleration and the x acceleration. The pitch angle is the atan of the z acceleration and the y acceleration.
In C# that’s simply
//WiimoteLib.AccelState acc passed into the method
roll = (float)(Math.Atan2(acc.Values.Z, acc.Values.X) * 180.0 / Math.PI) - 90.0f;
pitch = (float)(Math.Atan2(acc.Values.Z, acc.Values.Y) * 180.0 / Math.PI);
I subtract 90 degrees so that horizontal is 0 degrees. I think the pitch could use a fixed adjustment as well but I haven’t made use of it yet so I haven’t looked into it. I use degrees in my code in various places but you could just leave it in radians.
Now the hard part is figuring out what the Wiimote is pointing at. I finally downloaded and tried out the head tracking demo that became very popular on YouTube. I was very disappointed to find that the IR values were being used as pointer position values directly. What that meant is that the demo only seemed to work because the sensor bar was kept horizontal. If you rotated the bar the motion was no longer correct. In other words, it was clever but the hard part was glossed over.
So let me make this clear: the IR values cannot be used directly as the location that the Wiimote is pointing at.
Hunting around on the internet I found a lot of references to triangulation and doing rotations but nobody had any equations. There’s a mouse demo out there were if you hold the Wiimote still but roll it slightly the cursor shoots across the screen. The reason is because it’s misusing the accelerometer data. Rotating the Wiimote in any direction doesn’t not necessarily imply acceleration: and the Wiimote knows this if you do the math right.
So what is the math?
position = new point_class((1.0-ir.Midpoint.X) * (double)sx, ir.Midpoint.Y * (double)sy);
If you’ve looked at the Wiimote Library test app you’ve seen something that looks like that. It’s basically unchanged except for one “minor” detail: the x-axis is flipped.
And you’re not done. That equation gives you the midpoint of the two IR sensors with the x-axis flipped. That doesn’t give you where the Wiimote is pointing just yet.
To finalize the equation you move the position point to the origin. In my code you subtract the point in the center of the screen from the position. You then rotate that point using the value of Roll. Now, add the center of the screen point back to position.
Done. That’s it. That’s the secret of using the Wiimote as a pointer.
Is it perfect? No. You can’t get all the way to the edges because this method requires that both IR sources be visible. It also may not be getting the exact spot on the screen that the Wiimote is pointing at but it’s close enough that I can’t tell. If I point the Wiimote in the upper left corner and roll the Wiimote the pointer stays in the upper left hand corner and so on with the rest of the quadrants.
So it’s a very good start. The basic thing to keep in mind is that input has to be simple. The equations for processing input have to be simple and fast otherwise you’re wasting CPU cycles that should be used for graphics and game play. So there was no reason for me to believe that you have to be doing complex 3D equations to get the pointer going.
Maybe that’s ultimately what Nintendo is doing, but you don’t have to. I’ll have the full code and download available soon so you can try it out yourself and maybe find ways to improve it.