Going the OSVR way - part 2 - Interfaces

In previous article we identified interfaces that needs to be defined prior to start the implementation. This article will detail those interface and define them the OSVR way.

 

OSVR interfaces

OSVR defines interface as "An interface is a pipe of data. A device exposes one or more interfaces, which fit into predefined interface classes".
So, interfaces are build on top of so called interface classes, but what are those ? For developers this can be seen as the relationship between XSD and XML (who said old enough ?) or between a .h and a .cpp.
Some interface classes like Analog, Button, Device, Imaging and Tracker are defined out-of-the-box (see here for details). But can we reuse them for our purpose ? Do we need more than that those to implement our requirement ? Let see.

What do we need ?

Game plugin interface

To be able to drive a motion platform, our hypothetical car racing game has to provide enough information to derive a realistic motion platform orientation and movement. This can be achieved by providing vehicle acceleration in all three directions and three angles representing current ground orientation to the OSVR stack. More information could be shared later on but for our current requirements, those are sufficient.


For increased efficiency, a plugin implementing this interface should provide asynchronous callback method to avoid polling loops on client plugins.

Motion platform plugin interface

Each motion platform has specific hardware / mechanical limitation inherent to their structure and design. To ensure a modular solution, this device interface should stay independent of those limitations and only require values that can be provided independently of the actual motion platform driver implementation.
The motion platform driver has to receive target angle and movements but also provide a way to feed our stabilization analysis plugin by providing real-time platform orientation. This can be achieved by providing an interface such as


Values used to set platform movements and angles are bounded between -1 and 1. This ensures the required modularity by only providing a percentage of the maximum value. It will be up to the platform driver to decide how much movement needs to be done. Orientation on the other hand should be returned as an absolute angle.
Again, for increased efficiency, a plugin implementing this interface should provide asynchronous callback method for current real-time orientation avoiding polling loops on client plugins.

Head orientation

Head orientation is provided out-of-the-box by OSVR for the Oculus Rift or the Razer Hydra VR headsets. For more details please have a look on here.

Motion stabilization

Motion stabilization analysis plugin must be used by games as a direct replacement of  head tracking devices like Oculus Rift and Razer Hydra VR headsets. This plugin will therefore implement an interface such as:

Conclusion

Even though, at first glance, the interface classes seemed light, guys at OSVR did a really good job to allow such a general purpose class as the Analog one. This class lets you define more or less any interface.

Next step, let's create a plugin ... TO BE CONTINUED