July 2016 developer updates


Key additions to OSVR capabilities since the last developer update:

  • Enhanced support for OSVR devices inside SteamVR including direct mode and distortion correction
  • Support for the new OSVR HDK 2 as well as new support for HTC-Vive
  • Native support for OSVR inside Unreal 4.12
  • OSVR support inside WebVR

See below for details




The SteamVR-OSVR driver allows gamers to play SteamVR games on any supported OSVR hardware. A number of features and improvements have been added to the driver recently:

  • The driver now works with the latest released version of SteamVR (v1.0.2). You should no longer need to use the old beta release.
  • Distortion correction is now provided.
  • Direct mode is supported in Windows if you have an AMD or NVIDIA (but not NVIDIA Optimus or NVIDIA on a laptop) graphics card with up-to-date drivers. First, run DisableDirectMode.exe put the HDK in extended mode. This allows the SteamVR driver to see the HDK and figure out what its position is in relation to your other monitors. Start up SteamVR and from the menu, select Devices → Direct mode. SteamVR will restart with the HDK in direct mode.
  • Along with direct mode, we now detect your monitors and automatically set the HDK’s position properly. This means you should no longer need to edit the osvr_server.json configuration file to set the position.
  • Room setup (standing mode) should now complete successfully. Completing the room setup should also fix the head-stuck-on-the-floor problem.
  • The tracking camera is now recognized by SteamVR.



The OSVR team has completed first step in integrating OSVR into WebVR. The patch has landed in Mozilla Firefox and is officially scheduled to be released in 49.01a milestone.
The goals of WebVR in remaining device agnostic align perfectly with OSVR philosophy and with OSVR integrated, it brings support to dozens of devices that can be used expanding the use of WebVR.

With the current integration, OSVR-WebVR allows users to experience WebVR with any device supported by OSVR. This includes HMDs such as OSVR HDK, Sensics, Vuzix, Oculus and HTC, numerous position and orientation trackers, controllers such as the Razer Hydra, HTC Vive Controller, the Nod Backspin and others. One of the most important goals of WebVR is interoperability, meaning that users can experience content across a wide spectrum of hardware.

The following capabilities are supported:

  • Device detection
  • Positional and orientation tracking
  • Display configuration which allows users to demo WebVR in extended mode.

Upcoming improvements: Now that the initial OSVR integration with Firefox is complete, WebVR could potentially use all the available OSVR interfaces such as eye tracking, plugins such as augmented reality target recognition and more. Hundreds of VR devices that were not supported by WebVR are now available by virtue of the OSVR integration. Moreover, as new devices get added to OSVR, they automatically become available to WebVR. The remaining part is for WebVR to connect its API to these additional OSVR interfaces to bring out all the benefits it has to offer.

The OSVR team is working to enhance this integration by incorporating the OSVR Render Manager to enable direct mode, asynchronous time warp, distortion correction and more across a range of HMDs and graphics cards, thereby improving latency and fidelity of the experience.

Useful links:

Instructions for trying OSVR in WebVR
Nightly build downloads
The WebVR 1.0 API Spec
Bug tracker for WebVR 1.0 implementation


  • OSVR is now natively integrated in Unreal 4.12. Just enable it in the Virtual Reality section of the project plugins window.
  • Updated tutorial video on YouTube for Unreal 4.12, using the built-in plugin: https://www.youtube.com/watch?v=Co2IiLVS3r8&feature=youtu.be
  • Fixed projection matrix calculation to support off-center projections.
  • Fixed flickering black mesh issue due to an incorrect render target texture format.
  • Updates for Unreal 4.12 compatibility.
  • VR headset should now go to black after exiting VR Preview mode in the editor when running in direct mode.


  • Added an OSVR editor window accessible through the Unity menu bar. It includes:
    • Links for launching utilities (TrackerView, Reset Yaw, DirectMode Enable/Disable, etc.) located in the OSVR Runtime/SDK directory.
    • Ability to launch any osvr_server.exe and config files from the Unity editor. Useful for faster testing of various server/render configurations.
    • Links to installers and documentation.

  • Added OSVR Server Autostart feature for Windows Standalone platform. This can be enabled or disabled on the ClientKit prefab for now, until it becomes a server config option.
  • Bug fix for crash when switching scenes in direct mode.





OSVR-Central, a new application serves as a main hub for controlling OSVR. It includes the following features :

  • Device Detection (hotplugging)
  • Ability to detect and launch OSVR server
  • OSVR Tools
  • Developer Tools
  • Access to RenderManager utilities and examples.

We are planning to soon add auto updating features and on-demand plugin downloads. OSVR-Central also lets you access OSVR-Config easily and is included in the latest runtime and SDK.

Device Detection: OSVR continues to add support for new devices (See section below about new LaputaVR HMD) and we added hotplugging feature to detect when a user plugs in or removes an OSVR compatible device. This is one of the steps we continue to improve the ease of use with OSVR as we are working towards plug-n-play experience.

Developer Tools : There are a variety of useful tools for developers to use such as Render Manager tools and demos, and OSVR related tools. OSVR-Central organizes them for an easy access. This feature is available with the SDK.


  • OSVR-Config is now included in the OSVR runtime installer.
  • Some improvements to the display and sample configuration layouts.




With the release of HDK 2, users should note the new display descriptor and sample config files distributed with the OSVR SDK. We recommend this configuration as a good starting point for orientation-only tracking with direct mode support, distortion correction, and client-side predictive tracking.

One issue Windows 10 users may notice is that when a new display is detected, the default magnification is set to 200%, resulting in an image that looks “zoomed in”. When using the HDK 2 in extended mode, the “Change the size of text, apps, and other items” option in Windows Display Settings should be set to 100%.


The OSVR-Vive plugin adds support for the HTC Vive (and Vive Pre) HMD, tracking system and hand controllers to OSVR. It has been released and updated to work with the latest (at this writing) build of SteamVR (1467410709). Tracking of HMD and controllers within the calibrated “room setup” space, buttons and touchpad, proximity sensor, and custom per-unit factory calibrated display/distortion correction in direct mode as well as extended mode are all functional when using the Vive with OSVR.

Pre-compiled binaries are available for Windows. Thanks to community contributions, the plugin also builds and runs on Linux and macOS.

This is not to be confused with SteamVR-OSVR module. The SteamVR-OSVR module is an add-in for SteamVR that allows using any OSVR-supported HMD with SteamVR applications. The OSVR-Vive plugin is a driver for OSVR Server that exposes the Vive hardware to OSVR applications.

Access OSVR-specific usage instructions for VIVE here
Access source code here


  • Head-tracking supported with all versions of Oculus SDK from 0.4.4 to 1.5.0.
  • Rendering is supported only with Oculus SDK 0.7 or older.


OSVR adds support for a new HMD – LaputaVR Hero. Together with the OSVR plugin, this HMD provides:

  • Orientation tracking
  • 110 degree FOV
  • 2560 x 1440 resolution
  • Distortion correction
  • No additional drivers/software required to get it running
  • Native VRPN driver


Under the hood



  • Completed implementation of C API for the OpenGL rendering library, including new example program.  Also includes utility functions to generate color and depth render-texture targets.  This paves the way to complete the port of RenderManager to non-Windows (and thus non-DirectX) platforms.
  • Direct3D C API updated to compile cleanly from both C and C++.  Direct3D C API example program added.
  • Reworked OpenGL header file structure to support a single set of headers on all platforms, including the ability for the application to decide which OpenGL header files to use.
  • For clients using CMake to build against OSVR-RenderManager, the osvrRenderManagerConfig.cmake file has been updated:
    • The osvrRenderManager target has been moved to the osvrRenderManager namespace. This means if you’ve written target_link_libraries(mytarget PUBLIC osvrRenderManager) in the past, you should update it to use osvrRenderManager::osvrRenderManager instead.
    • A new osvrrm_install_dependencies(<install_directory>) function has been added which will install the RenderManager library and all its dependency libraries to the specified path. This is useful in Windows for creating more portable installations.
  • Added alpha support for RenderManager in the OSVR-Android-Build project.  The current RenderManager master branch can now be compiled on this platform.
  • Merged contribution from Steffen Keiss, who provided an approach to enabling RenderManager to be used with other windowing libraries than SDL, and who also provided a Qt-based example of how to do this.
  • Sharing OpenGL contexts between the application and RenderManager, including new example program showing how to do it.
  • Beta version of distortion correction for the OSVR HDK 2 compiled into the library. See sample display descriptor using this distortion mesh in “displays/OSVR_HDK_2_0.json”.
  • Exposes distortion-correction machinery for use outside of RenderManager.
  • Merged Cailei’s VRGate HMD vendor ID.
  • Added projection matrix calculation for Unreal.  Generalized D3D projection matrix calculations to support off-axis projections on both axes.  Repaired OpenGL off-axis projection matrix calculation.
  • Added renderer-independent call to blank the screen, as requested by game engines to handle transitions between scenes.  The first renderer-agnostic example program (SolidColor) provided to show how to use it.
  • Fixed crash when constructing a new RenderManager after having destroyed a previous one.
  • Performance optimizations in the render-mesh construction and in the DirectMode rendering pipeline.  Reduction of image-tearing artifacts in DirectMode.
  • Added support for additional color buffer formats.
  • Saving and restoring D3D state during the final render pass to avoid interfering with application settings.
  • Merged contribution from Matthew Dutton, who reduced the number of vertices calculated in the distortion mesh by a factor of six, greatly improving startup time.
  • Fixed crash issues in some cases for Asynchronous Time Warp.  Also waiting for rendering completion in ATW to reduce tearing.
  • No longer has the side effect of pulling a display out of DirectMode if the config file says that it should be opened in extended mode.
  • Avoids creating callback-based render targets when they are not being used, reducing GPU memory usage.
  • Synchronized the passing of multiple eyes to an ATW buffer, ensuring display of consistent views for both.
  • Enabled applications to operate via buffer-copy when using ATW, rather than requiring them to construct two sets of buffers and alternate presentations.  This enables apps to use ATW without modification, though it does incur a slight rendering time increase.





  • High-performance logging framework now built-in, logging to console as well as to file, with client and plugin APIs to log to those same log sinks – see below.
  • Build compatibility with Boost 1.61.0 verified and build updated accordingly.
  • Adjust Windows timer frequency when a client is connected, for lower, consistent latency. https://github.com/OSVR/OSVR-Core/pull/424
  • Added configuration files for OSVR HDK 2


Logging interface

OSVR-using apps will now log not just to the console/terminal (if they had been before), but also to file, when possible, in more detail. Log files are given a name preferably with the application name (“osvr” as the fallback) and the date and time, and, if needed (if you run OSVR Server for longer than a day, for instance) they are rotated daily.  Here is an example of the logging interface running on a Mac:

  • The location for log files is platform-specific:
    • On Windows, they’re in %LOCALAPPDATA%\OSVR\Logs (for example, C:\Users\Ryan\AppData\Local\OSVR\Logs )
    • On Linux and other *nixes, the XDG directory standard is followed so they are placed preferably in $XDG_CACHE_HOME/osvr/logs, or if that environment variable is empty or not defined, $HOME/.cache/osvr/logs
    • On macOS, they are placed in your home or user directory, under Library/Logs/OSVR
    • On Android, logging output is directed to the standard Android logging interface (“logcat”) rather than file or console.
  • Where console output is visible, you’ll see information on where the log file is placed and its base filename on-screen at the top of the output.
  • Log entries are marked with a timestamp, a “severity”, and a log source in [square brackets].
  • For developers:
    • Both PluginKit and ClientKit provide logging functions that let you specify a severity and a message string.
    • Messages you log will be associated with your plugin or app via the log source tag automatically by providing a valid context as the first argument to the function (in the C interface) – while failing to do so will not cause crashes or cause the loss of the message, it will cause the message to show up with an ugly note about a missing context.
    • Existing log messages from within OSVR functionality, but triggered by your code, will also be associated with your application or plugin by inclusion of your ID in the log source tag.
    • Now would be a great time to double-check your application IDs and plugin IDs (reverse domain-name format!)
    • When you can, port any existing direct output to the new logging functionality, to provide a unified, improved experience for both users and developers.


  • getBinaryLocation() (used to find plugins, etc) fixed on macOS, should improve behavior when running osvr server by typing ./osvr_server https://github.com/OSVR/OSVR-Core/pull/436
  • Build fixes for using libc++ on non-Mac platforms such as Android.
  • Improved display descriptor and distortion correction for the DK2.
  • Path normalization for server autolaunching/server locate.
  • Fixed variable naming to improve compatibility with some configurations.
  • Fix Android build issues related to gtest.
  • Fixed angular velocity transformations.
  • Various compiler warning fixes.




Release 1.2.7: https://github.com/OSVR/OSVR-HDK-Windows-Drivers/releases/tag/v1.2.7

  • Updated device metadata packages to clarify that a device may be an HDK 1.3 or 1.4, since they are indistinguishable from the data that the device metadata system has access to.
  • Minor .inf updates:
    • USB serial port driver now installs on Windows 10, wrapping the bundled Windows 10 USB serial port driver and providing a name for it.
    • IR camera driver modified to fix a corner case where the displayed name in the Device Manager would not always be overridden by the .inf file on Windows 10.

Tips and Tricks


Super-sampling and Sub-sampling

Recently, attention has been drawn to “hidden settings” in Oculus software and SteamVR to enable supersampling. Supersampling renders a larger, more detailed initial buffer than strictly needed to map 1-1 per pixel in the final output image. Supersampling results in every pixel in the output being sampled from more rendered data. It requires more graphics performance, but may lead to a perceived visual improvement – it’s a form of spatial anti-aliasing and essentially a (high-overhead) variant of MSAA.

OSVR RenderManager has had this capability for quite some time, as well as its inverse, subsampling, which renders fewer pixels and upscales to compensate for lower performance graphics processing. The setting is easily accessible in the RenderManager configuration, usually a separate file referenced from your OSVR server config file. The value you’d want to change is called renderOversampleFactor in the renderManagerConfig object. The default value is 1.0 (one pixel in the render buffer per pixel in the output), and the values work just like those discussed for SteamVR. Larger values render more pixels than necessary and blend/sample for the output, smaller values render fewer pixels than 1-to-1 and upscale, potentially improving performance at the expense of rendering sharpness.

Changing this setting and restarting your OSVR server will affect all native OSVR applications using RenderManager. Notably, it will not affect SteamVR as SteamVR does not use the OSVR RenderManager for distortion correction, client-side prediction, time-warp, and direct display output; however, the “Vive” supersampling configuration change should actually work with devices used through the SteamVR-OSVR plugin as well.

Client-side vs Server-side Predictive Tracking

In the context of AR and VR systems, predictive tracking refers to the process of predicting the future orientation and/or position of an object or body part. Prediction can run on the server or client, but only one of those options should be enabled for best performance. By default, server-side prediction is enabled because it works on every machine running OSVR. However we recommend using client-side prediction for machines that support it. This document gives an overview of predictive tracking and describes the steps to enable or disable client and server-side prediction.

Additional Contributions from the OSVR Community

  • Steve Le Roy Harris has created a number of new OSVR plugins:
    • OSVR-OpenHMD is a wrapper around OpenHMD which provides native driver support for the Oculus DK1 and other HMDs.
    • OSVR-KinectV2 provides joint position and orientation data from the Kinect for Xbox One.
    • OSVR-Wiimote uses the wiiuse library to support up to four Wii Remotes + Nunchucks.
    • OSVR-Fusion combines position data from one plugin with the orientation data from another plugin to present a fully-fledged tracker to OSVR clients.

The culmination of Steve’s work (video) is the ability to use Wii remotes, an Oculus DK1, and a Kinect to play games that require a tracked HMD and tracked controllers.

Additional Resources

As a reminder, we’ve set up developer chat rooms at Gitter, and they are tied to the GitHub projects.
The list of all rooms is here: https://gitter.im/orgs/OSVR/rooms
Some existing rooms:

The list of supported devices, operating systems and engines is here
The OSVR documentation repository is here

VR tutorials written by the experts at Sensics on key topics such as eye tracking, optical design, time warping, foveated rendering more are here. To only see the tutorials, click on ‘key concepts’ on the right side of that page.

Want to Participate?

Interested in contributing? Start here: http://osvr.github.io/contributing/

Current areas of high-priority “help wanted” are improving render manager on non-Windows platforms, tools to simplify the user experience, support of additional devices and video “compositor”

Any questions or issues? email support@osvr.com

Leave a Reply

Your email address will not be published. Required fields are marked *