Thinking about integrating your HMD into the OSVR software platform? Consider this:
For your customers
- Immediate access to a wide spectrum of content including SteamVR and native OSVR content.
- Ability to use your HMD with hundreds of peripherals including third-party motion/eye/hand/eye trackers, controllers and motion platforms.
- Access to Windows, Linux, Android and Mac platforms.
For developers using your HMD
- Optimized engine plugins including Unity, Unreal, WebVR, Amazon Lumberyard, SteamVR and many more. These plugins are frequently updated to support the latest engine versions and include new contributions from the Sensics team and the global OSVR community.
- Ability to use high-performance rendering such as direct mode, asynchronous time warp, predictive tracking and distortion correction.
For your organization
- Focus on your core competencies instead of on complex VR “software plumbing”
- Get to market faster and with a more complete product offering
- Become part of the world’s largest open-source VR ecosystem and enjoy its technical and marketing benefits.
How it’s done
Adding an HMD to OSVR can be done by practically anyone. Alternatively, you can contract Sensics engineers – the primary architects of the OSVR software platform – to perform this integration service quickly and cost-effectively for you.
Whether you do it yourself or have Sensics do it, here’s what needs to be done:
The only fields you must modify are:
- The metadata fields – primarily for human consumption, though Render Manager also uses `vendor`:
- The basic optical parameters:
- hmd.field_of_view.overlap if the screens are not aligned
- The basic display control/input data:
- In the resolution entry, the `width` and `height`, and, if yours isn’t a single input horizontal side-by-side, `display_mode` and potentially `video_inputs`.
- To use a display descriptor with an OSVR server config file, you add or edit the `”display”: “???.json”` line. See, for example, a server config that specifies the display descriptor for the Sensics dSight HMD. If no display line is specified, then a default is used. A useful minimal sample to test your display descriptor (does not test distortion) would be the OpenGLSample in the OSVR-Core distribution which places you in a cube.
In many cases, displays have some degree of distortion that should be compensated for ahead of time through pre-distortion. OSVR has a number of distortion parameters, suited to different types of distortion, and different tools for measuring them. All of these modes can be specified in the server configuration files and read using the OSVR-Core libraries and several of them are implemented in the OSVR-RenderManager interface.
The Core modes (implemented on a non-RenderManager path of OSVR-Unity) includes:
- K1-parameter-based distortion – Based on quadratic distortion from a center for red, green, and blue.
The RenderManager also includes:
- Chromatic General-polynomial-based distortion – Based on radial distortion around a defined center of projection for reg, green, and blue. See the description in Rendermanager.h for details on how this is specified.
- Monochromatic point samples – Based on an arbitrary mapping from angles to screen-space locations, often from a lens simulation performed on the optics.
- Chromatic point samples – Based on an arbitrary mapping from angles to screen-space locations for red, green, and blue, often from a lens simulation performed on the optics.
See this link for additional details
Direct-to-HMD rendering bypasses the operating system and window management overhead, removing the display from being a part of the extended desktop, and drawing directly to it using the graphics driver. OSVR’s RenderManager handles both non-direct advanced rendering (time-warp, advanced pre-distortion, etc.) available with just a regular display descriptor as above, as well as direct mode support.
Using direct rendering on a new HMD requires three things:
1. Construct a RenderManager configuration file with a screen resolution and rotatation that matches one of the modes supported by the HMD.
2. Add your EDID vendor ID to RenderManager and create a pull request to have it included in RenderManager.
3. Contact the graphics card manufacturers to have your EDID vendor ID added to their direct mode whitelists. The display must be recognized as a direct-mode display by the vendor’s driver. This is handled differently by each vendor, and you should contact them directly to be added to their whitelists.
Your HMD probably has tracking either integrated or attached. If it’s an off-the-shelf tracker, there might already be support in OSVR for it via VRPN: see more on the compatibility page. A tracker for an HMD should provide the /me/head alias at the center point between the two eyes centers.
If you have a custom tracking system, and/or if your device has an interface for control and status messages, you might be interested in writing a device plugin to provide more interaction with the OSVR system than just as a display device. See the Building a Plugin section.
You can verify that the tracker is working by using OSVR Tracker Viewer. It will display a set of axes showing the position and orientation of your HMD as you move it about.
You can check that the display descriptor and distortion correction is working well by running one of the demo applications that ship with OSVR-RenderManager.
Finally, we also suggest using the SteamVR-OSVR driver to test your HMD with SteamVR games.
To make your HMD plugin available to the widest audience of OSVR users, we recommend the following:
- Create simple installer to deploy the plugin.
- Add the installer to the OSVR plugin repository.
- If applicable, open-source your plugin code so that the community can assist in porting it to other platforms and improve it.