Non-vr::VRApplication_Scene programs do not show up in main bindings menu

[sharkyh20]

I've been implementing the new binding system for a program of mine, KinectToVR, which runs in the background of VR games and uses kinect data to emulate Vive trackers with the OpenVRInputEmulator for full body tracking stuff.

However, in order to support the new bindings, I need to have the bindings menu open - but it only opens when the IVRSystem is initialised with a vr::VRApplication_Scene type.

A temporary workaround I've used to still open the menu to set bindings can be found below (It's called from a GUI button, after the initial program initialisation, which includes m_VRSystem = vr::VR_Init(&eError, vr::VRApplication_Background);

After the warnings about unset bindings popup, the user can still set/save bindings, and they correctly work for the next sessions. It just seems that non Scene programs don't show in the main Controller Bindings menu.

// Only scene apps currently actually load into the Bindings menu
// So, this momentarily opens the vrsystem as a scene, and closes it
// Which actually allows the menu to stay open, while still functioning as normal
vr::EVRInitError eError = vr::VRInitError_None;
vr::VR_Shutdown();
m_VRSystem = vr::VR_Init(&eError, vr::VRApplication_Scene);

Sleep(100); // Necessary because of SteamVR timing occasionally being too quick to change the scenes

vr::VR_Shutdown();
m_VRSystem = vr::VR_Init(&eError, vr::VRApplication_Background);

The problem with this hacky implementation is that every time it's called, it leaks memory in 'vrclient_x64.dll', same as if it was normally initialised. Due to the potential for bugs/performance issues in my janky method to get it to work, I believe that Background programs, or at least ones that don't explicitly render yet still take input, should be able to show up in the bindings menu as well.

[bddckr]

In case a maintainer sees this and wonders about the memory leak of the Init call: #195, #310, #467. Possibly related to #578.

[BOLL7708]

I also have a background application that wants to listen to controller events, I got stuck (#879) in the implementation guide as my application would never shop up in the interface 😭 And my manually added bindings never took effect 😐

[sharkyh20]

@BOLL7708 This is the process I went through to get the bindings to work.

You can take a look at my implementation on the development branches for K2VR - the main program stays in Background mode for its operation, but to actually implement the system I had to keep switching over to Scene mode in order to get inputs to show. A side effect of this is that it keeps showing up as not responding, since it never actually renders anything to SteamVR, but it still functions for input purposes.

The relevant ones to connect to the app are "action-manifest.json", and the default Touch bindings in "K2VR_Bindings_Oculus_Touch.json" in https://github.com/sharkyh20/KinectToVR/tree/RGB-Tracking/Input

The actual in-program code to load the bindings can be found here: https://github.com/sharkyh20/KinectToVR/blob/RGB-Tracking/SFMLProject/KinectToVR.cpp#L260

It was a PITA to actually get the manifest to load, and some things I suggest doing are using the Web browser version of the bindings with Developer Mode on (F12) to see the errors (http://127.0.0.1:8998/dashboard/controllerbinding.html) and a mirrored VR one, as some errors seemed to only display in the VR menu.

An additional note, you can sometimes get an idea of what it thinks is wrong with your files in the controller binding webpage by inspecting the binding javascript with Chrome's tools.

Across each attempt at a manifest file, I had to restart SteamVR, as sometimes it used a cached version over the updated one.

Other than that, I had to do a fair bit of manual text file editing in order to get the manifest to load, but once it did, your app has to be in Scene initialised mode, where you can then go into the bindings menu, create a binding, and then save it as a personal binding. (Which saves in C:\Users\NAME\Documents\steamvr\input\YOUREXEHERE_vive_controller.json)

You can rename this saved file and copy it into your Inputs folder for your program, and define it as the default for a device type in the manifest file. I had absolutely no luck whatsoever trying to do the controller bindings files by hand, and had to do it this way.

[SteffanDonal]

I'm running into this issue too - we'd love to take advantage of the new Input system, however this is a massive blocker with no reasonable workaround.

It appears that the only thing preventing this from working correctly is the last_launch_time property inside an application's vrappconfig.
Changing this to a current timestamp (and restarting SteamVR) causes the application to correctly show in SteamVR Input, and from there things appear to function as normal.

Once this is done, I'm able to get input information from the OpenVR runtime without issue.

I'm going to look into ways to force this timestamp to be updated.

[BOLL7708]

@SteffanDonal I'm going to prod you a bit about this.

As noted above I'm also trying to get this to work in a background application. Now I've added a .vrappconfig to my project with a fresh timestamp. Looking at other projects I used [namespace].[app].vrappconfig, basically the same as I've provided in app.vrmanifest as app_key. That is also a file I did not have since before that I've added now. Lastly I also have an ActionManifest.json that I've based on examples, I get no error from loading either the vrmanifest or action manifest so it seems like things should be working.

But, I cannot get anything to show up in the binding interface though, except manifest errors if I screw with my manifests. I've restarted my application as well as SteamVR (my application survives and reinitializes the connection) but no success.

I'll flip over to my sample project I have that is a bit simpler and the code is here on GitHub and see if I have more success. The frustration continues.

[username223]

@sharkyh20 This was fixed in SteamVR beta 1.3.1 around 2019-02-06.

Reference issues that seem to be a semi-duplicate: https://github.com/ValveSoftware/openvr/issues/879 https://github.com/ValveSoftware/openvr/issues/926

We have been using the new input API without issues for the past 6 months on OpenVr Advanced Settings.

(I meant to comment on this 6 months ago but I kind of forgot, I only remembered https://github.com/ValveSoftware/openvr/issues/879.)

[LaySoe]

914