New OSVR Core features: path tree updates

Here is an update on some important OSVR improvements:

OSVR Core:

This relates to version v0.2-1-g0f15a69

This release is an extensive update: fully-configurable path tree, use of device descriptors for auto-routing, and more.

Path tree refresher

Path trees are an important concept in OSVR and perhaps worth a quick reminder. OSVR maintains a “path tree” – similar to a URL or file system path – in which all the sensing and rendering data is made available. Aliases are configured in the server to essentially redirect from a semantic path (a path with a meaningful name) all the way back to the system-specific hardware details. Thus, while direct device access by name is possible, it is not recommended: instead, we recommend accessing semantic paths. This accommodates use cases where the hardware is not immediately available at startup or is changed during operation without any impact to the application developer. Some examples:

  • A path capable of position, orientation, or pose (position and orientation) callbacks or state access, associated with the left hand: /me/hands/left
  • Position of the “0” controller of the Hydra, directly accessed in the namespace of the com.osvr.Multiserver plugin: /com_osvr_Multiserver/RazerHydra0/tracker/0
  • Output of the first smoothing filter in a hypothetical org.example.smoothing plugin: /org_example_smoothing/smooth_filter/0

Just like a game allows mapping of various buttons to various game actions, OSVR allows defining the connection between interfaces, analysis plugins and actions. For instance:

  • /joystick/button/1 → /actions/fire maps the first joystick button into a fire action. While the game could choose to access /joystick/button/1 directly, it is recommended to access /actions/fire in this example because this allows changing the flow of information from the hardware through the OSVR layers without changing the game itself.
  • /com_osvr_Multiserver/RazerHydra0/tracker/0 → /org_example_smoothing/smooth_filter/0 → /me/hands/left specifies that the position of the first Hydra controller goes through a smoothing filter and then is mapped to the left hand.

The connection between interfaces can be pre-loaded or can be changed dynamically.

Key changes:

  • Updated server and client internal data structures, for:
    • Fully-configurable path tree, with support for single or multi-level aliases for semantic name use with no additional performance hit. For instance, this allows a game-friendly path such as /me/hands/left to be dynamically mapped to a path in the plugin /com_osvr_Multiserver/RazerHydra0/semantic/left which in turn is mapped to the physical path /com_osvr_Multiserver/RazerHydra0/tracker/0. All these mappings are resolved up-front so they do not create a performance hit at runtime.
    • More efficient data transfer.
  • Partial to complete auto-configuration of aliases based on JSON device descriptor data embedded in plugins.
  • Full access to external (local or remote) VRPN servers/devices with Tracker, Button, and Analog interfaces. (Previously, only experimental support for Tracker devices) See the updated osvr_server_config.externalvrpn.sample.json
  • Attributes of display now controlled and configurable by the server: see osvr_server_config.dSight.json for config info. This allows switching between various HMDs (or other displays) without recompiling the application.
  • Display descriptor files added for a wide range of HMDs and display modes. See the OSVR HDK descriptor as an example

Breaking changes:

  • To support the data structure updates, some internal messages were changed, so v0.2+ client libraries can only communicate with v0.2+ servers: v0.1 and v0.2 do not interoperate. (However, client ABI or overall client API did not change, so you should be able to just replace the DLLs without recompiling your client application.)
  • If your device driver was not submitting a JSON device descriptor, it will be mostly inaccessible as that is used to populate the path tree. See the example on how these work.
  • The method of configuring access to external VRPN servers has changed, so if you’re using that functionality, see the updated sample config files.
  • Plugins have been renamed, and many configuration files were able to be simplified greatly. See the updated sample config files.

Additional changes:

  • New tools: There are new tools: osvr_print_tree displays the contents of the path tree (try -h for help with command line arguments), and PathTreeExport exports path tree structure to DOT format – see the documentation for usage
  • Support for auto-detecting a USB serial port name by VID/PID.
  • More efficient data transfer
  • The contents of the osvrTransform and osvrRouting shared libraries (.dll files) have been folded into osvrCommon and thus those files are now no longer produced by the build, nor need to be distributed. This is internal API only, so no changes to apps expected.

Definition of OSVR interfaces:

We are working to define and enhance additional OSVR interfaces such as eye tracking, locomotion (for devices like those from Cyberith and Virtuix) as well as support additional devices. If you are interested in participating in this process, please let us know.

Additional updates:

1. The OSVR board contains an overview of issues currently in GitHub issue trackers for all OSVR framework projects. It summarizes the issues in a number of lists:

  • Those under “Contributions Wanted” are likely to be the easiest entry points into contributing, though in some cases they may simply be tasks that require skills that existing contributors do not have.
  • Those under “Ready” are not blocked by any other issues and are approved for development for integration.
  • Those under “In Progress” should typically show a user who is working on them – if you want to take on a task, move it here and assign yourself.
  • The “Done” list should be self-explanatory – it contains closed issues from the past 7 days (automatically removed).
  • All issues not otherwise assigned to a list end up in “Backlog”. You’re welcome to work on these (whether through verification, triage, or development), though please use the issue thread to communicate your plans and progress.

Of course, the issue lists are not all-encompassing: if you’ve got a contribution you’d like to make, we’d love to see it! Filing an issue on the right project would be a great first step.

2. Follow OSVR on Twitter @OpenSource_VR

These latest updates also include contribution from the OSVR community, for which we are very thankful.

Interested in contributing? Start here:

Any questions or issues? email

Thank you for being part of OSVR!

Leave a Reply

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