Update plugin code to work with OpenVR SDK 1.0.6

[ChristophHaag]

No problem. Does the current state work already?

[gfrolov]

@ChristophHaag , the plugin compiles and runs, but we're working through the new flow for device detection and activation.

[ChristophHaag]

I get this stack overflow on Linux: https://gist.github.com/ChristophHaag/63f3949888bac430d3cb2aec23ec90f3

Is this expected?

[gfrolov]

@ChristophHaag , please try to recompile with the latest changes. It should fix the compiler error that you were referring in #29 You should also now get the Vive HMD show up in Tracker Viewer, so plugin is mostly working now.

[ChristophHaag]

I still need to add #include <vector> to Properties.h to fix the first error, but I think the second one is gone.

After that I get a new error:

/home/chris/build/osvr-vive-github/Properties.cpp: In function 'void readProperty(const PropertiesStore&, vr::PropertyRead_t&)':
/home/chris/build/osvr-vive-github/Properties.cpp:97:43: error: invalid initialization of non-const reference of type '{anonymous}::GetContainedTypeTag&' from an rvalue of type '{anonymous}::GetContainedTypeTag'
     auto containedTag = val.apply_visitor(GetContainedTypeTag());
                                           ^~~~~~~~~~~~~~~~~~~~~

and

/home/chris/build/osvr-vive-github/Properties.cpp:104:54: error: invalid initialization of non-const reference of type '{anonymous}::ValueSizeGetter&' from an rvalue of type '{anonymous}::ValueSizeGetter'
         static_cast<std::uint32_t>(val.apply_visitor(ValueSizeGetter()));
                                                      ^~~~~~~~~~~~~~~~~

and

/home/chris/build/osvr-vive-github/Properties.cpp:112:23: error: invalid initialization of non-const reference of type '{anonymous}::ValueGetter&' from an rvalue of type '{anonymous}::ValueGetter'
     val.apply_visitor(ValueGetter(batchEntry));
                       ^~~~~~~~~~~~~~~~~~~~~~~

[ChristophHaag]

apparently the compiler just doesn't like that construct, see my updated commit in #29

[ChristophHaag]

Headset is fully tracked in tracker view, RenderManagerOpenGLCoreExample works but only has rotational tracking. Great progress!

[ChristophHaag]

It's been a while now. Tracking the hmd seems to work nicely.

I retried RenderManagerOpenGLCoreExample. I first thought positional tracking isn't working with it, but it is working, just the scale seems off, you have to move the HMD quite a bit to get some positional movement inside the cube. With the HDK2 much smaller movements are required.

My pull request https://github.com/OSVR/OSVR-Vive/pull/29 is still needed to compile on linux. Here are the error messages without: https://gist.github.com/ChristophHaag/833833a099583a15a79d5087adaab1b3

I see you added a config file for the puck tracker. Are you going to add support for the normal Vive motion controllers too? Besides better tracking with lighthouse they are the biggest reason to use the Vive over an OSVR HDK or other HMDs.

[rpavlik]

The regular Vive controllers should already work: they've worked for me for a long time. There are some issues with newer steamvr versions that we haven't figured out yet that are preventing the controllers (and puck) working wirelessly with this branch, and I'm not really sure why (since it did work just fine for me in older steamvr builds), but we think all or essentially all the code is there, just needs some review and experimentation.

[ChristophHaag]

I see, I have only tried them wirelessly so far. Connected with microusb they do work. Not great, but good enough to start playing around.

[DuFF14]

Pushed some code to tell the difference between the puck and controllers. There may be a better way to do this, but I needed to fix this issue and this seemed safe for now.

[ChristophHaag]

This makes it compile with OpenVR 1.0.7, not sure if it needs some more work: https://github.com/ChristophHaag/OSVR-Vive/commit/76344af18bff9b4367c9274fa6b106b7c3bc2920

• Added GetRawTrackedDevicePoses. Provides access to device poses for drivers. Poses are in their "raw" tracking space which is uniquely defined by each driver providing poses for its devices. It is up to clients of this function to correlate poses across different drivers. Poses are indexed by their device id, and their associated driver and other properties can be looked up via IVRProperties.

sounds only optional.

[gfrolov]

@ChristophHaag , check out the latest changes in the plugin. It's now working fully with wireless tracking and hotplugging. It's now pretty much ready to be merged. Let me know if #29 needs to get merged to address Linux compilation warnings. We're going to do openvr 1.07 in a separate PR, but it now works with the latest SteamVR and SteamVR-OSVR driver.

[ChristophHaag]

Yes, my pull request is still needed.

I updated the commit for OpenVR 1.0.7 https://github.com/ChristophHaag/OSVR-Vive/commit/fd37007947a7ac072b41dcfb8bd89d01914f9248 and tested with the pull request + this commit.

On my first try starting osvr_server, the Vive controllers (wireless this time) were not there, on the second try they weren't there either, on the third try they were there, but stuck in the zero position and rotation and then they finally started working on the next try. So it's not super reliable, but it works!

The positional tracking "scale" of the HMD in RenderManagerOpenGLCoreExample still seems off, but the controllers move normally.

[gfrolov]

Thanks for the review @DuFF14 That error is occurring because lighthouse driver is requesting if there is an override to that setting, and it will fallback to its default setting. I lowered the log level to an info because these events are not actual plugin errors. We'll need to look into reading the lighthouse settings from their settings file.