All posts by VRguy

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 waffle.io 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: http://osvr.github.io/contributing/

Any questions or issues? email support@osvr.com

Thank you for being part of OSVR!

Unity plugin improvements, .Net bindings and new projects

Dear OSVR developers,

We wanted to briefly update you on several OSVR improvements:

Unity plugin:

Refers to version: 0.1.71-ga184206

Key changes (see CHANGES.md file for complete list):

  • Updated plugin to be compatible with Unity 5.
  • Increased frequency of OSVR client updates for reduced latency as well as additional performance improvements
  • Dynamically sets display parameters (field of view, resolution, side by side mode) based on JSON display descriptor. This allows the same Unity app to run well with multiple different OSVR-supported HMDs

We recommend that existing users of OSVR Unity plugin re-build their project with this new plugin. The performance and usability improvements are worth it.

Additional updates:

  • Improved locating of DLLs in both the editor and built players, and improved locating of the (temporary, game-local) json file in built players. Previously, some Unity projects ran fine inside the editor but had to have files copied over to run standalone. With this fix, it is no longer necessary to move the built executable to the project root.
  • Modified DisplayInterface to look for json in _Data folder at runtime.     If it’s not there, load json from Unity scene as usual.
  • Moved DLLSearchPathFixer.fix() to Awake().     Removed constructor.
  • Created static DeviceDescriptor.Parse method and moved code from DisplayInterface.GetDeviceDescription over to to this static method.
  • Untabified changes to DeviceDescriptor and DisplayInterface.

This version does not yet include support for Unity 5 64-bit – that is in progress and being tested, expected soon. https://github.com/OSVR/OSVR-Unity/issues/19

Vuzix plugin:

Version v0.1-18-g7758a1c

  • Resolved issues with orientation and zero-point.

 

.NET bindings:

The base .NET bindings for OSVR have been extracted from the OSVR-Unity plugin into a separate repo – https://github.com/OSVR/Managed-OSVR – for optimal re-usability, and are being actively improved by us and the community. This separate version currently includes support for 32 and 64 bit native libraries, have a fully MSBuild-based build system, and builds assemblies for both .NET 2.0 and 4.5 framework versions. A NuGet package is coming soon https://github.com/OSVR/Managed-OSVR/issues/2

New projects on osvr.github.io:

  • OSVR HDK: includes production file for the OSVR Hacker Developer Kit
  • sensics/Latency-test: includes code and instructions for Arduino-based latency tester

 

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. We have updated a couple of white papers on the OSVR site:

2. We are providing additional suggestions for OSVR roadmap on our Wiki page
3. The OSVR waffle.io 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.
These latest updates also include contribution from the OSVR community, for which we are very thankful.

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

Any questions or issues? email support@osvr.com

Thank you for being part of OSVR!

 

Improved Unity plugin (v92), new Unreal and Vuzix plugins

We wanted to briefly update you on several OSVR improvements: an improved Unity plugin, a new plugin for Unreal Engine and a new plugin for Vuzix HMDs.

Improved Unity plugin

Version 92 of the Unity plugin adds several new improvements:

  • Compatibility with Unity 5
  • Added distortion correction shader that uses parameters from the display JSON descriptor (discovered through the distortionizer tool)
  • Support for wide-field HMDs with partial binocular overlap such as the Sensics dSight and VRUnion Claire
  • Performance improvements
  • Added NEWS.md file to summarize recent changes

We also updated the whitepaper describing how to convert Oculus Unity projects to OSVR Unity projects. It can be found at http://osvr.github.io/

New Unreal Engine plugin

The Unreal Engine plugin is now public on Github. Please visit http://osvr.github.io/build-with/ or https://github.com/OSVR/OSVR-Unreal

New plugin for Vuzix HMDs

This new plugin supports Wrap1200 and iWear 720 HMDs. Find the source code here https://github.com/OSVR/OSVR-Vuzix or download the latest build here: http://osvr.github.io/using/

This plugin enables OSVR applications to run on Vuzix products. We are continuing to add support for additional vendors.

These latest updates also include contribution from the OSVR community. Interested in contributing? Start here: http://osvr.github.io/contributing/

Any questions or issues? email support@osvr.com

A brief overview of the OSVR software repositories

The OSVR team opened up most of the source code repositories to the public this weekend, and a few additional repositories will be opened in the coming days.  Many have asked us for a brief overview of the project.

The best place to start is osvr.github.io. If you haven’t read the ‘introduction to OSVR whitepaper‘ you might want to do so.

There are several github projects under the /osvr organization. They are as follows:

Key projects:

  • OSVR-Core : this is the heart of the project. The OSVR_server executable connects the game to the OSVR hardware and software components.

Utilities:

  • OSVR-Tracker-Viewer is a utility that graphically shows the position and orientation of the head and hand controllers. It is also an OSVR client, and thus an example on how to connect to and extract data from the server
  • Distortionizer: a utility to estimate distortion correction parameters for various HMDs and a shader to implement the parameters estimated by the Distortionizer. OSVR has JSON descriptor files for HMDs (and many other objects) and the distortion parameters are part of that JSON file

Game engine plugins:

  • OSVR-Unity includes a prefab component that can be imported into Unity.
  • OSVR-Unreal (to be released later this week) is an Unreal Engine plugin

Development tools:

  • OSVR-Boxstarter is a Boxstarter install that helps quickly set up a development environment on a Windows machine
  • OSVR-JSON-Editor is the source code for a tool (deployed version here) that helps create and edit the JSON descriptor files
  • OSVR-JSON-Schemas is a repository for such JSON files

Plugins:

  • OSVR-Oculus-Rift provides a plugin that allows using the position and orientation data of an Oculus device inside OSVR.
  • OSVR-Vuzix (to be released later this week) does the same for Vuzix headsets
Additional projects are coming. There is also a wiki page. Issues are currently tracked as part of the Github pages of the projects and we are looking to add an open-source project management tool.
OSVR (licensed under Apache 2.0 license) aims to create a multi-platform framework to detect, configure and operate a wide range of VR devices as well as to allow smart plugins that turn data into useful information. This is a big undertaking and there is a lot more work to be done to fulfill that vision, so we are looking for all the help we can get. We are super encouraged by the support and feedback we are getting from developers all over the world that believe in the open-source concept, and want to make their contributions towards moving VR forward.
Let us know what you think. What’s missing, what your priorities are and how we can get you involved. Welcome to OSVR.

OSVR now open to the pubilc on Github

The OSVR project is now open to the public. All key software projects are now available and a few minor ones will be added in the next couple of days.

The best place to start is http://osvr.github.io/

Please also make sure to visit the Wiki, support portal, development blog and other OSVR sites available from the top right menu in http://osvr.github.io/

We look forward to working with the OSVR community to make OSVR better with every passing day.

Welcome!

Distortionizer tool, Imager interface, Unity improvements

Several new capabilities of OSVR are now available to the OSVR ecosystem, including new features in the core, improved Unity plugin, distortion measurement/correction tools as well as additional new resources available to the community.

OSVR Core

A new release of OSVR core (version 0.1.652) has been deployed to access.osvr.com

The release adds several new features:
– Add display descriptor JSON files that describe display parameters such as field of view, resolution, side-by-side mode as well as distortion correction parameters. These files can be used by various applications – such as the Unity plugin – to adjust the rendering parameters to match the VR headset of choice. If you make HMDs, please take a look at the format of the JSON file and send us one for your device.
– Add automatic reconnect for OSVR HDK and Razer Hydra. This eliminates the need to restart the OSVR server if the HDK or Hydra were power cycled or otherwise disconnected from the PC. A more generic mechanism covering additional devices is coming soon.
– Allow controlling the sleep period in the main loop of the server, thus freeing up CPU resources. The osvr_server_config.json file now has a “sleep” parameter under “server”. This parameter, in milliseconds, specifies the sleep in the main loop. It can be 0 (maximum performance, maximum CPU load) or other values such as 1 (samples peripherals every 1 mSec, so 1000 times per second).

Imager Interface

This release also includes an alpha version of the new imager interface which allows routing and processing of video images inside OSVR. It is built on OpenCV, the popular open-source computer vision framework.

The imager interface includes PluginKit and ClientKit interfaces (both are designed for use with C++ though there is an underlying C API). An OpenCV camera capture plugin (with sample config file) and sample client application (displays image data from OSVR using OpenCV “highgui”) are included.

In its current incarnation, the imager interface has significant limitations with regards to image size, number of bits per channel and the efficiency of image transfer between the OSVR server and OSVR clients. These limitations will be addressed shortly. The imager interface includes a lot of infrastructure work which will be used in additional types of device interfaces.

OSVR Unity Plugin

The Unity plugin (version 59) has been improved significantly. It automatically sets the display parameters based on the display JSON files (see https://github.com/OSVR/OSVR-Unity/tree/master/OSVR-Unity/Assets/OSVRUnity/Displays for some examples)

We also created a new white paper showing how to transition Unity games to OSVR. Download it here

Distortionizer Tool

This tool provides a way to empirically determine geometric and color distortion parameters for an HMD as well as an example shader that uses these parameters to correct them. It is found in https://github.com/OSVR/distortionizer

A utility program allows interactively changing the distortion of red, green and blue using a simple cubic distortion function until the image appears best. It then stores these parameters in a JSON file and includes a demonstration program that uses them in a shader. Although the tool can be enhanced for more sophisticated functions, we believe it is useful in its present form.

What’s Next?

In the coming days, towards the close of GDC, we shall open the source code for public consumption. Until then, we are busy making some improvements and adjustments including documentation improvements, formally changing the software license to Apache 2.0. We are also working with many contributors to add plugins and other unique functionality to OSVR. Stay tuned!

Some Housekeeping

A few administrative notes:

– We will be at GDC, primarily at the Razer booth which is booth 602 in South Hall. We’ll have exciting demos from partners and will be available to discuss anything OSVR.
– The wiki pages at access.osvr.com have been updated to include several ‘getting started’ documents, so make sure to take a look from time to time.
– The Github repositories were migrated from the /sensics organization to the /osvr organization on Github
– The best email address for support is support@osvr.com

We look forward to your comments and feedback. Any questions or issues? email support@osvr.com

Thank you for being part of OSVR!

Improved Device Plugin Kit (v63)

A new release of OSVR core (build #63, corresponding to git commit e7e4fccbefe29792b6c6277d266a64f5df646767) has been deployed to access.osvr.com

This release makes it easier to build device plugins and includes new example programs on how to do so: one example for an analog interface (e.g. game controller) and one that combines analog, button and tracker interfaces. This is all covered under the ‘PluginKit’ area of the documentation and source code.

The release also includes numerous small improvements and bug fixes including:
– Sample analog plugin.
– Clean up samples.
– Basic setup methods for the three base interfaces.
– Improve documentation
– Add a constructor method prototype.
– Add generic deleter right to C++ interface of plugin context.
– Add prototypes for orientation reports.
– Generate and submit json in analog plugin
– Change self-contained plugin to be based on the AnalogSync example and include json.
– Doxygen groups for analog/button/tracker pluginkit.
– Update readme file.
– Change default config file to use the OSVR HDK head tracker, and rename some other configs.
– Check serial port state before opening YEI device, printing just a single readable error message.
– Move normalization logic into the serial port helper functions.

We look forward to your comments and feedback. Any questions or issues? email support@osvr.com

Thank you for being part of OSVR!

OSVR Core (v396) and Unity Plugin (v42) updates

New features:

Core:

Major:
Handle external VRPN servers specified in routing directives. This allows running the game on one machine and having some sensors on other machines
* Add OSVR HDK tracker to supported devices. This is detected automatically
* Add alternate config file for users who see x right y down when facing the screen in the sensor suite.
* Add OSVR_calibrate calibration app that provides a zero point for the tracker

Minor:
– Add sample config file for external VRPN server routing.
– Fix/elaborate docs on demo apps.
– Compile-time optional verbose output during USB HID enumeration.
– Add method to directly read the routes from within the server process.
– If server is running when a route is added, re-send routes after the addition. This allows the server to remain running after stopping/starting the application
– Add sample config file for HDK. Requires calibration

Unity:

In general, make sure you re-import the Unity plugin to take advantage of new features and bug fixes
– Add initial demo assets
– Add tooltip to clientkit components
– Add InterfaceCallback prefab
– Update readme in plugin directory
– Add info on using buttons/analogs.

Bug fixes:
Core:
– Avoid t5rying to connect to the same Hydra more than once
– Silence “can’t get to server” messages from vrpn remotes
– Update VRPN for additional HDK VID/PID pair.
– Improve performance of YEI tracker
– Reduce the number of executables we install directly into the bin dir.
– Make sure getting routes is safe threading-wise.
– Add a mutex to enable external call-controlled to succeed eventually if the loop is running
– Automatically handle COM ports of any number on Windows.
– Mark calibration-added transforms, and strip them when calibrating again.

Unity:
– Make sure we disconnect from the OSVR server when the game object is destroyed
– Make the demo assets ASCII
– Delete list of callbacks on stop.

OSVR core (v339) and Unity (v31) updates

A new build of OSVR core and Unity plugin, along with its documentation, is deployed to the preview site.

OSVR core update is numbered 339. Updates are:

Features:

  • Supports routing and transforming tracker reports from external VRPN servers (running on the same or different machine – if same machine an alternate port must be used). This screenshot (of a sample config file included with the snapshot) shows the portion of the JSON transform tree to route data from sensor 1 of a VRPN device called “YEI0@localhost:3884” (that is, running on the local machine, port 3884 instead of the default 3883 – note the leading slash added in the JSON.) This provides initial basic compatibility with all trackers supported by a VRPN server.

OSVRUpdate

  • Silence client-side messages that the server is not responding, which are often spurious due to the current routing setup.

Bug fixes:

  • Fix to routing code to solve issue of missing input data.
  • Avoid re-detecting Razer Hydra upon application connect that triggers a hardware detect.

Documentation:

  • add reference to the separate Unity docs, mention that the server must be running.

 

Unity plugin update is numbers 31. Key changes:

  • Includes fixes from core.
  • Stability and lifetime management improvements.
  • Feature: Button and analog support: Add a Unity-specific wrapper around the .NET OSVR code, to simplify listening for button or analog callbacks. Example scripts included, with example usage in the “minigame” scene.
  • Docs for writing a callback handler.
  • Add “known issues” section to docs, primarily to note that at this time, input data only comes in during the first time a game is run during a single Unity editor session. The workaround is to close and re-open the Unity editor. (No need to restart the server: this is specific to the Unity client)