On Mon, Nov 9, 2015 at 11:26 PM, David Glenn <da...@dglenn.com> wrote: > Greetings All! > > Is anyone experimenting with OSVR yet? > > I know that there is some Oculus stuff that people have tried with some > limited success, but just wondering if anyone looked at it from the OSVR > standpoint!
I am doing quite a bit of OSVR integration work at my current job, mostly because we use GearVR quite a bit and getting VRPN working on Android and in Unity3D is a pain. It can be done, but OSVR had supposedly supported Android port and more features, so we have tried that instead. In short, the framework parts related to device management and tracking work, even though you need to expect some rough edges. It is basically a layer on top of VRPN (the VRPN maintainer now works for Sensics, the company behind OSVR), with the protocol mostly being compatible. For example, you can use VRPN clients to receive data from an OSVR server for devices like trackers or buttons, of course without the extra metadata. I have also written a few plugins for OSVR to expose data from other sources (Kinect, Natural Point's Optitrack, etc.) or to process/transform tracking data using scripts - the APIs required are there and it basically works, even though a few things are still a bit rough. It is usable, though. Where things could go south is if you try to do things the OSVR developers didn't anticipate - I think I am one of the leading external bug reporters on their issue tracker because we are always finding use cases they didn't expect or that nobody has attempted before. For example, right now it is impossible to use an external OSVR server (i.e. not running on the same machine as your client - probably the most common VRPN setup) with the official code, unless you use kludges like defining an environment variable or a local OSVR server to point to the remote one. The code to allow this is there and works, but I was told that the clients are not supposed to use the sw in this way so it is not exposed in the API. I have a patch submitted for this, but it wasn't accepted yet. I cannot comment on the parts related to HMDs (management of distortion and such) - never used it and Oculus Rift and GearVR that we use pretty much require the use of their native SDKs so unless you have the OSVR HDK helmet, it is probably not going to be all that useful, because the Rift-proprietary features will not be supported (at least with the current code - could change in the future). >From what I can see from the source, the HMD support is right now mostly about publishing the HMD parameters (like the distortion parameters, focal length, etc.) in the metadata tree and then there are some utilities and examples provided that can use that information and calculate the correct matrices for your client application (it uses Eigen everywhere, so it is API agnostic), making it independent from the exact model of the HMD you use. At least that's the idea, the practical implementation (and performance) of this remains to be seen. There may be some other tools available which are outside of the main OSVR-Core tree, but I haven't looked at this part of OSVR in any depth, so take this with a grain of salt. Also keep in mind that OSVR is still under a heavy development - if you need unconditional API/protocol stability, it is probably safer to use VRPN, which is a known quantity and pretty much an industry standard. In addition, there is likely a lot of OSVR development happening out of public view - they (Sensics) are certainly at least in talks with major hw/sw players if not in collaborations already, judging from the list of partners, so things will most likely change quite a bit. On the other hand, VRPN is very limited compared to what OSVR can do, especially when it comes to publishing of the metadata - publishing things like names of the tracked rigid bodies, marker - rigid body associations, orphan markers in the scene, quality of tracking per joint, etc. VRPN cannot deal with any of that without major nonstandard kludges. OSVR is also designed for runtime reconfiguration without restarting the server, so you can have plugins publish changes (e.g. when a new device is connected) on the fly and the client will pick that up and re-establish the data routing correctly. Again not something typical VRPN setups can do. I suggest you test the software and see whether it fits your needs. Regards, Jan _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
