Think I should have tried something different?

Here is some additional explanation as to why I approached these challenges the way I did. Sometimes the most obvious way to have done this is something that I tried already, or wanted to do, but didn't have the resources.

In no particular order:

Why move around in the first place? Couldn't you just use an actual joystick?

This is best explained in the choice of the concept of walking accross a chasm. It boils down to suspention of disbelief. It would be easy to run accross a narrow beam while sitting comfortably in an office chair wiggling a joystick/mouse around, even with an HMD. If the user's walking motion is directly impacting the position in the game, and a few steps the wrong way can result in the user's avatar plummeting down the chasm, the fearfactor becomes a little more real.
Also see the Why Bother section.

Why didn't you use the Half-Life 2 / Havoc engine?

I would have loved to use HL2 for this project, but the very first thing I was looking for was if I could roll the camera view. Though the engine has a SDK available for free, it isn't open source. I wouldn't even know who to ask as to where to start for how or where to code the changes necessary for roll. With Nexuiz, it was simpler.

Why can't you use the wiimote?

This has already been answered, but for more clarification, it is here too.
The wiimote does not have a gyro, therefore it cannot track yaw at 360 degrees. It does have IR tracking however. It can track up to 4 dots at a time. This allows for some Yaw control, but the most you might get is 45 degrees. I have experimented with being surrounded with more than 4 dots; this doesn't work because the wiimote's firmware will constantly and suddenly switch between the dots, creating erratic readings.

Why not use an actual mouse or optics for motion tracking?

This is another one that would have solved so many problems if it worked. The problem with using an actual mouse comes in a few ways. Windows DirectX can only read 1 mouse at a time. The yaw motion data is being mapped onto the left/right axis of the mouse driver, so it cannot be used for something else. Mapping the yaw onto a joystick would not work because joysticks cannot have continuous looping data the way Direct Input does. It is theoretically possible to re-write the windows mouse driver so it interacts in a different way, but this is a little beyond the scope of this project in more ways than one. (Note that GlovePIE can read and apply multiple mice, but it is limited to windows cursors, DirectX, which is required for the game, can only read 1 data source at a time.)

Secondly, there was the explored case of using a re-wired ball mouse. Since the mousewheel operates on the same concept as the axils of a ball mouse, it is possible to replace the currently in-use sideways axis of the mouse, with the mousewheel. Experimentation was done on this concept. A wireless mouse was used, but it seemed that there was an inherent limitation on using the mousewheel simultaneously with either of the ball axils. This became evident with sever cursor lag that was experienced when the mousewheel was moving along with moving the mouse. Even if this wasn't an issue, there are mechanical limitations in the physical speed that a ball mouse can move. When the speed threshold is approached, ball tracking ceases to work at all. Since fixing this would require a complete rebuild of the mouse, this idea was scrapped in favor of a driverless solution. (see final results)

Lastly, since only the left/right axis of the mouse direct input is in use, the forward/backward axis is still available. An optical mouse would have been ideal for floor tracking, but there was no way to block out any slight left/right motion that the optics pick up. This resulted in conflicting information on the left/right mouse axis which was shown as as sever jitter.

Why didn't you use accelerometers for motion tracking?

In my research paper, I concluded that it is theoretically possible to use a combination of the accelerometers and gyro that are present in the sixaxis controller to provide motion tracking. This has been done before in other devices, however, resources for developing a custom algorithm in human walking patterns for the sixaxis are not currently available.

Mount the floor tracker on a chair?

As much fun as wheeling around in office chairs is, this too was experimented with and deemed to be appropriate for a different project. The bottom half of most, (if not all) office chairs is on its own swivel. This means that it rotates in random directions even though the user is moving straight. This allows for easy, lowered friction gliding. Mounting a floor tracker on here would require the bottom half of the office chair to remain rigid with the seat. This makes the chair difficult to turn and keep in a straight line due to the nature of the wheels used in office chairs.

Why not use mercury switches or even an old pre-built system like the VFX1. It should be old enough to be cheap right? There is also such thing as a gyro mouse that some people have used for head tracking.

Firstly, though cheaper than most commercial head tracking units, a gyro mouse is still significantly more expensive than a console controller.
The VFX1 used in this project was gutted and replaced with a non-head tracking HMD. The reason for this is that not only were the low quality optics obsolete, these days, ISA slots in desktop computers are not readily available. The VFX1 used mercury switches to detect the direction of gravity, though this achieves the same goal as the accelerometers, the circuitry and drivers are already set up for a console controller.

IR tracking?

This is what commercial motion tracking systems currently use. It requires a pre-setup room and the user must wear either IR emitters, or reflectors for the computer to track. These systems are extremely expensive and limited to the set room. The whole point to Virtual Wiiality Redux is to free the user from these confines.

Question not here!

Contact me!

- back to the top -