INPUT DRIVEN SOLUTIONS

This category of 3D navigation solutions is centered on the actual input element(s) of the 3D navigation solution. The most distinct aspect of these solution types is their focus on the user generated side of HCI communication and their detachment from any system output responses. As previously stated, the input elements of general 3D interaction solutions must capture enough input from the user to complete the given task. In the case of 3D navigation, the input element must capture the user’s input that, when combined with the IT / IM and other solution elements, provides the system with an adequate amount of the 6 DOF of navigational control data.

Choosing an appropriate existing input device, or designing and implementing a brand new one, can be a very difficult task to do successfully. As previously stated, careful attention must be made to the physical shape of the input element because that dictates

the affordances and constraints that are provided. Equally as important to the outward appearance of the input devices are its inner workings - such as sensor types and transfer functions.

There is a great amount of diversity among possible tasks that require navigation for completion, luckily there is a correspondingly broad spectrum of input affordances and constraint combinations that can be arranged. For example, it has been shown that user’s tend to perform rotation and translation actions as separate subsets during the navigationally relevant task of docking [29]. For these types of navigational tasks, solutions that have input elements that separate these actions, either physically through the device itself or logically through how the device is used, should prove to be better than those that integrate those activities. Information gathering potential, which is one of the major performance metrics for 3D navigation solutions outlined by Bowman [3], could be greatly enhanced by allowing the user to move and look around separately. Consider the real life activity of walking through a hallway that has messages written on the walls. The messages can be read by a human being while constantly moving to the end of the hallway, since our heads, flexible necks, and legs allow for a separation of translation and orientation control. However, a bumble-bee whose method of flight does not allow for this separation must keep flying toward each message on the wall separately in order to read all the messages.

Considering the lower-level detail of sensor type exclusively, some may be better suited for navigation. For example, 3D navigation solutions that are meant to mimic vehicular

transportation, like a motorcycle, would benefit greatly from input elements that use elastic sensors since they provide a counterforce in the same way as a motorcycle’s grip- based acceleration control. However, elastic sensors would be less appropriate for navigation solutions that were meant to be closer to moving a game-piece around a board game. In that case, it would be best to use isotonic sensors since they measure actual displacement and orientation and provide no counter-force.

Entire 3D navigation solutions that are concentrated around the input element(s) must be carefully designed and implemented around the exact specifications of the input interface or device. In these solutions, the choice for input element(s) usually precedes all others. For example, selecting a dual thumb-stick controller (such as the controllers for Xbox360) as the input element for a FPS game dictates that a very specific IT / IM will have to be used in conjunction. Viewpoint translations and orientations are typically mapped to each thumb-stick, respectively. However, this would not be the case if the input device was changed to a generic isometric joystick. There is usually not a sufficient amount of DOF to be controlled at one time so there would be a requirement in the IT / IM to switch states between mapping the joystick to control the translation and when it would control the orientation. An example of the choice for the input element dictating the choice of output is using gaze-directed steering to capture navigational input. In this case, the most appropriate output element to use would be an HMD. The user will be changing their head’s orientation frequently to steer their virtual movement in the VE, so it would be very useful to be able to dynamically change the position and orientation of the user’s view of the VE (via the output element) to compliment their changing gazes.

Examples

One of the most popular car racing arcade games is ‘Cruis’n USA’ by Midway Games. At first glance, the most noticeable feature of this arcade is the quasi-realistic car interior format of the entire arcade system – which is mostly made up of the input interface. This is perhaps one of the best examples of an entirely input element driven navigation solution since every aspect of this solution is centered on this car-like interface. Firstly, the car interior interface is designed to very closely mimic a real car and it dictates that only an IT / IM that involves, with some degree of fidelity, the real-world act of driving a car would be appropriate. Secondly, it dictates that the accompanying output element of the interface must also conform to the existing car interior style, and this is done by placing an output display where the windshield would be located. Other output elements can be further complimented to the car interface by the addition of audio speakers for sound effects and also by enabling the actual chair of the interface to provide haptic feedback.