Headtracking is especially useful for 3D-applications with an object- or a room-scene as in our demo programs. For the usage on object-scenes, it is useful to work with objects with a great depth. If it is more spherical, the effect of rotation might not be so good, because of the lack of depth. A good example for a suitable object would be a longish, ramified neural cell.
An impressive example for the application on room-scenes is the demo-room, in which you have a lot of scaling and intersection in combination with a vanishing point projection at each viewpoint. Moving through this room with the help of headtracking emphasizes these effects and the resulting depth-effect.
Of course there might be other fields of application, which don't just focus on the usage of headtracking for rotating and translation, but we focused on these topics.
The radius of the camera leads to a restriction of the application, because there has to be a minimum distance from the camera to the user. If you are too close to it, the sensors don't recognize your movements. It's the same, if you are too far left, right, up or down. The angles of the camera are approx. 30 degrees vertical and 40 degrees horizontal; only in this area the wiimote detects the user's position.
For a 2D-application it might be very difficult to find a propriate implementation for headtracking, for which reason we didn't concentrate on this.
If you want to implement Wiiheadtrack to a more complex program, it could become difficult. For instance, if a program is realized in Qt, you have to modifiy Wiiheadtrack to a QObject-class and successive call Wiiheadtrack::computePos() with the help of a timer, connected with this function.
Another restriction is, that because of the minimal movement of the user's head -- even if he intends not to move --, it is almost impossible to hit the border of the Wiimote-camera accurately and therefore to reach the outermost angle.
A minimal but uncomfortable restriction is, that you have to press two buttons on the wiimote before it connects to the program.
Furthermore, the movement in z-direction is a a little imprecise, because the Wiimote is placed under the monitor and the user usually moves his head towards the center of the monitor.
The last constriction is, that the viewing direction in the room-mode is statical. So you cannot see what is behind you, if you use this mode.
Until now, there doesn't exist an implementation of the wiiuse-library for Apple-computers, but the developer is looking for somebody who implements it, and probably it will be realized in later versions.
Wiiheadtrack is especially written for the usage with OpenGL under Linux, but it should also compile under Windows and with other graphic libraries supporting C++ (we've not tested that).
For the usage of the Wiiheadtrack you need a bluetooth connection working with BlueZ. Otherwise, you would get mistakes during the compilation, because the compiler couldn't find the bluetooth commands which are used in the wiiuse-header wiiuse.h.
For a good result you need at least one object near to the viewer as a point of orientation. If you only look at one or more objects in the distance without an object close to you, the depth-effect as a result of headtracking wouldn't be convinsing.
We tested differences of frames per second (fps) with the help of two programs of the Visualization and Numerical Geometry Group of the Heidelberg University. Both programs use the object-mode: ParaNeural visualizes neural cells, GigaMesh visualizes 3D-scans. In ParaNeural the average value of frames per seconds is about 600 without headtracking and about 300 with headtracking. In GigaMesh the percentage of loss is lesser, it's about 25.000 fps with and without headtracking. Generally the usage of Wiiheadtrack in these cases is visually not recognizable, but exists.
One great improvement opportunity is to connect a second Wiimote to have more possibilities. For the two modes we want to give some ideas:
Another nice feature would be to show the Wiimote's the battery level with the help of its LEDs: If all four LEDs are switched on, the batterly level is greater than 75%, if three LEDs are switched on, the battery level is greater than 50% and so on.
The third improvement could be a GUI for a more comfortable configuration and adjustment of Wiiheadtrack's sensitivity.
1.7.1
