25.2. Event Classes

Open Inventor provides a variety of platform and window system independent event classes. Translating “raw” input into these Open Inventor event objects is useful because nodes in the scene graph can respond to these events in various ways. SoHandleEventAction SoHandleEventAction SoHandleEventAction takes an event object and traverses the scene graph. Standard Open Inventor nodes that respond to events include SoSelection SoSelection SoSelection , SoLocateHighlight SoLocateHighlight SoLocateHighlight , and all the dragger classes. Applications may also create custom nodes that respond to events. There are two event classes specifically for use with tracked input devices:

A “ tracker” is any device whose position and orientation are dynamically tracked in 3D, typically for immersive VR applications. For example: a head tracker. A “ controller” is an input device which typically has buttons and/or valuators (e.g., a joystick). Many controllers also have an associated tracker. For example, the commonly used “wand” input device typically has three buttons, a two-axis joystick (two valuators), and an associated tracker.

SoTrackerEvent SoTrackerEvent SoTrackerEvent encapsulates a 3D position value and an orientation value, typically representing a tracked input device such as a wand. The CAVELib example (Section 25.4, “Programming with CAVELib”) shows how the wand position and orientation could be converted to an SoTrackerEvent SoTrackerEvent SoTrackerEvent . Note that these are absolute position and orientation values, unlike the SoMotion3Event SoMotion3Event SoMotion3Event , which is designed to support a SpaceBall type device and contains relative translation and rotation values.

Many tracker devices generate a continuous stream of position and orientation reports, so strictly speaking there are no “events.” However Open Inventor classes that recognize the SoTrackerEvent SoTrackerEvent SoTrackerEvent interpret it as notification of a “significant” change in the tracker position and/or orientation, so testing the change in position and orientation against a tolerance value may be appropriate. Note that processing of SoTrackerEvents may be relatively expensive. For example, a pick operation will usually be done automatically. The application (or other software above Open Inventor) is responsible for deciding when to actually create an SoTrackerEvent SoTrackerEvent SoTrackerEvent .

SoControllerButtonEvent SoControllerButtonEvent SoControllerButtonEvent represents a change in a controller button (press or release). The event also includes the (absolute) position and orientation of the input device. The CAVELib example in the section called “Handle Events with CAVELib” shows one way that controller button changes can be detected and converted to an SoControllerButtonEvent SoControllerButtonEvent SoControllerButtonEvent . This class is derived from SoButtonEvent SoButtonEvent SoButtonEvent and has similar convenience methods.

The virtual method SoEvent::getTrackerInfo() can be used to determine if an event object has associated 3D tracker information. Traditional 2D events like SoMouseButtonEvent SoMouseButtonEvent SoMouseButtonEvent and SoLocation2Event SoLocation2Event SoLocation2Event return NULL. 3D events like SoTrackerEvent SoTrackerEvent SoTrackerEvent and SoControllerButtonEvent SoControllerButtonEvent SoControllerButtonEvent return a pointer to their associated tracker information (SbTrackerInfo SbTrackerInfo ).