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:
- 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.
- Silence client-side messages that the server is not responding, which are often spurious due to the current routing setup.
- Fix to routing code to solve issue of missing input data.
- Avoid re-detecting Razer Hydra upon application connect that triggers a hardware detect.
- 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)
A new build of OSVR, along with its documentation, is deployed to the preview site.
This build updates to both the OSVR core and is numbered 322
Here are the key changes in this build:
- Interconnection is now user-defined. A key attribute of OSVR is that it allows connecting various software components while providing a common interface to the application. For instance, a Razer Hydra component might be connected to a “1-euro” smoothing filter which then connects to hands/left and /hands/right outputs. Previously, these interconnections (or “the routing”) were hard-coded. Now, they are defined in the osvr_server_config.json files. In the future, we expect an interactive tool or auto-routing, but for now this JSON file provides greater flexibility in changing components.
- Coordinate system transformations. Another part of osvr_server_config.json allows coordinate system transformations such as swapping axes or rotating on a certain axis. This can help with calibration of trackers that are positioned in non-standard ways. For instance, here is an example setting where some of the bold lines show swapping axes or rotations. BTW, you can leave the tracker view app open when you change this, if you want, and just shut down the server, change the config file and start osvr_server again. The viewer app will automatically reconnect.
- Oculus Rift support. This is an experimental plugin that allows using the orientation and position tracker of the Oculus DK2 inside OSVR. This shows the promise of OSVR to support applications across multiple HMDs and can also be used as a debugging tool. If you want to try this out, let us know.
- Hardware redetect. Starting from this release, every time an application launches, osvr_server will redetect the available hardware. This means, for instance, that if you forgot to plug in your Hydra, you don’t need to restart osvr_server after you plug it in. Just restart your app.