Going the OSVR way - part 1

After building and releasing our Motion cancelation update of the Oculus Rift library, we started to investigate on what would be the best way to expand that technology to other VR headsets and games. Multiple alternatives are available but until now, OSVR seems the most accomplished one. Let's analyse how to do that.

Motion platform integration, a short story

To summarize the chain of control from a game to motion simulation platform,here are the components used in current X-Sim, VectionVR based architecture.

From game to motion platform the flow is as follow

• The game is launched by an extractor component  (1)
• Vehicle acceleration, ground orientation and other data are sent to Converter component (2)
• Converter component converts data from game to motion platform representation  (3)
• Angle and displacement are capped using motion platform driver and sent to the motion platform  (4)
• Motion platform move to the right position and orientation (5)

From motion platform to VR headset (Oculus rift in the picture above) the flow is

• Motion platform sends the orientation to VectionVR stabilizer  (6)
• VectionVR stabilizer analyse the orientation and forward the relevant information to Oculus library (7)
• The orientation is sent as reference orientation (8)
• Oculus library applies the Reference orientation to the current head orientation (9)
• Updated orientation is sent to the game for further usage (10)

What are the downside if that approach ?

• It implies a lot of software components to install and setup
• no homogeneous or centralized configuration
• tied to specific hardware
• VectionVR's stabilization patch needs to be added to every game and for every VR headset

Motion platform manufacturer usually put a lot of effort and investment to provide hardware which are safe and user friendly. At VectionVR we think that software and software architecture should also apply the same principle.

Applying OSVR principles to the stack

Looking at OSVR documentation, the necessary steps to join together the process described here above and OSVR architecture can be summarized in the following drawing.

•  A conversion analysis plugin uses both interfaces to compute platform angle and displacement and provide it to a motion platform plugin (2)
• This motion platform plugin: (3)
• Send information to the platform to move it to the right position and orientation
• Reads at fixed rate the platform orientation to provide it to his clients
• The orientation is read by the motion stabilization plugin to use it as a ground reference (4)
• Head tracker information is read by another plugin implementing head tracking interface (5)
• This information is merged with the Head orientation provided by the Head orientation provider in a Stabilization analysis plugin (6)
• The stabilized head orientation is provided to the game for further use (7)

This solution can look less straightforward and more complex but what does it bring ?

• One software stack to configure
• centralized configuration
• using nicely defined interface remove any coupling with a specific hardware
• using other interfaces remove any coupling to specific game 

This would obviously bring the required user friendliness and should also bring more operation safety.

Next steps

Obviously, besides this short draft theoretical approach there is a lot more to do to achieve a working solution.:

• Define all the identified plugin interface and create the OSVR representation for it
• Create a motion platform plugin
• Create a game plugin
• Create the conversion analysis plugin 
• Create the stabilization plugin

In the next posts we will try to achieve those tasks basing our thoughts on an hypothetical racing game and see where it brings us ... TO BE CONTINUED