Can't get inputs to update properly using SteamVR (2.6.1) on 2020.1

[GeekBrony]

The simplest way I can describe my issue is that SteamVR absolutely refuses to give me proper readings on inputs.

Tracking pos/rot of the headset and the controllers work, but input isn't quite working.

The live input window won't give me proper values either. I have generated the actions.json and compiled, but nothing is working it seems.

I'm using Unity 2020.1, with a HTC Vive, using XR Management and XR Interactions Toolkit, with SteamVR's implementation of OpenVR (2.6.1).

Here's my manifest.json

{
  "scopedRegistries": [
    {
      "name": "Packages from jillejr",
      "url": "https://npm.cloudsmith.io/jillejr/newtonsoft-json-for-unity/",
      "scopes": [
        "jillejr"
      ]
    },
    {
      "name": "Valve",
      "url": "https://registry.npmjs.org/",
      "scopes": [
        "com.valvesoftware",
        "com.valvesoftware.unity.openvr"
      ]
    }
  ],
  "dependencies": {
    "com.unity.2d.sprite": "1.0.0",
    "com.unity.burst": "1.3.2",
    "com.unity.cinemachine": "2.6.0",
    "com.unity.ide.visualstudio": "2.0.2",
    "com.unity.ide.vscode": "1.2.1",
    "com.unity.inputsystem": "1.0.0",
    "com.unity.jobs": "0.2.7-preview.11",
    "com.unity.mathematics": "1.1.0",
    "com.unity.postprocessing": "2.3.0",
    "com.unity.quicksearch": "1.5.4",
    "com.unity.terrain-tools": "3.0.1-preview",
    "com.unity.test-framework": "1.1.16",
    "com.unity.textmeshpro": "3.0.1",
    "com.unity.timeline": "1.3.5",
    "com.unity.ugui": "1.0.0",
    "com.unity.xr.interaction.toolkit": "0.9.4-preview",
    "com.unity.xr.management": "3.2.13",
    "com.valvesoftware.unity.openvr": "1.0.1",
    "jillejr.newtonsoft.json-for-unity": "12.0.301",
    "com.unity.modules.ai": "1.0.0",
    "com.unity.modules.androidjni": "1.0.0",
    "com.unity.modules.animation": "1.0.0",
    "com.unity.modules.assetbundle": "1.0.0",
    "com.unity.modules.audio": "1.0.0",
    "com.unity.modules.cloth": "1.0.0",
    "com.unity.modules.director": "1.0.0",
    "com.unity.modules.imageconversion": "1.0.0",
    "com.unity.modules.imgui": "1.0.0",
    "com.unity.modules.jsonserialize": "1.0.0",
    "com.unity.modules.particlesystem": "1.0.0",
    "com.unity.modules.physics": "1.0.0",
    "com.unity.modules.physics2d": "1.0.0",
    "com.unity.modules.screencapture": "1.0.0",
    "com.unity.modules.terrain": "1.0.0",
    "com.unity.modules.terrainphysics": "1.0.0",
    "com.unity.modules.tilemap": "1.0.0",
    "com.unity.modules.ui": "1.0.0",
    "com.unity.modules.uielements": "1.0.0",
    "com.unity.modules.umbra": "1.0.0",
    "com.unity.modules.unityanalytics": "1.0.0",
    "com.unity.modules.unitywebrequest": "1.0.0",
    "com.unity.modules.unitywebrequestassetbundle": "1.0.0",
    "com.unity.modules.unitywebrequestaudio": "1.0.0",
    "com.unity.modules.unitywebrequesttexture": "1.0.0",
    "com.unity.modules.unitywebrequestwww": "1.0.0",
    "com.unity.modules.vehicles": "1.0.0",
    "com.unity.modules.video": "1.0.0",
    "com.unity.modules.vr": "1.0.0",
    "com.unity.modules.wind": "1.0.0",
    "com.unity.modules.xr": "1.0.0"
  }
}

Only thing I can think of that may be messing with things is the new Unity input system, although I haven't tested this theory.

Does anyone else have this issue?

[kinacho2]

mmh, try this https://www.vive.com/us/support/vive/category_howto/optin-to-steamvr-beta.html maybe works, it worked for me when I couldn't see the controllers.

[rib]

Struggling here too. I've been trying to activate the default action set or get any action set to show as 'Active' in the SteamVR Input Live View but just not having any luck currently. I'm not actually sure if I'm supposed to explicitly Activate() the default set or if that one is special and it shouldn't be necessary? All the documentation on this stuff is so out of sync right now :/

I was previously using the 2.6.0b4 release, and have tried opting into the steam beta and now updated to the 2.6.1 release of this plugin.

I'm running with Unity 2019.4.8f1 LTS

The xr plugin generally seems to be working for pose information etc but I'm desparately trying to enable SteamVR support in my app and since Valve have explained they won't be supporting the Unity XR Input API I'm trying to also query inputs via this plugin when using the OpenVR XR plugin.

If I run the Simple Sample scene I'm currently seeing lots of errors like:

Internal: deleting an allocation that is older than its permitted lifetime of 4 frames (age = 6)

and

Internal: JobTempAlloc has allocations that are more than 4 frames old - this is not allowed and likely a leak

(I didn't notice those with the previous 2.6.0b4 release)

Would love to have some pointers to even be able to get the most basic example of combining the unity XR plugin (rendering only) and using this steamvr plugin for input, with Unity 2019.4.

[rib]

Digging arround in the implementation I'm seeing that an ActionSet builds on top of ActionSet_Data and that data is apparently not getting initialized by something. I haven't seen any documentation about needing to explicitly initialize action sets but maybe you do now?

It looks like the ActionSet gets initialized via OnAfterDeserialize but it seems notable that ActionSet::Initialize() does not also Initialize the ActionSet_Data because in this case the createNew argument is false (not sure at the moment what that's intended for)

The fact that the ActionSet_Data is not initialized I think will explain why I never see an active action set. The implementation of ActionSet::IsActive calls ActionSet_Data::IsActive which returns false if initialized == false

[rib]

I realised it's probably correct that it doesn't pass createNew in this case. When initializing the ActionSet the code looks up the corresponding data based on the path like /actions/mixedreality.

I'm getting dizzy going around in circles with this code, trying to poke stuff to understand how it's supposed to work.

At some point I saw that SteamVR_Input::Initialize() was never called which seemed suspicious so I tried calling it explicitly but that triggered a null reference exception via:

EVRInputError err = OpenVR.Input.GetInputSourceHandle(path, ref handle);

I think I have to throw my hands in the air - I don't know how to poke this code to do anything :'-( super frustrating trying to develop cross-platform VR code in Unity right now - so many competing/conflicting abstractions :-( ironically maybe even worse right now than it was in the past.

[rib]

I just tried making a blank project from scratch with Unity 2020.1.3f1, imported the steamvr_unity_plugin 2.6.1 release and opened the Simple Sample scene.

In this case I do now see that the default action set gets made active and I can see pose data. Just like the OP though I don't see any other actions working. I'm also testing with a HTC Vive.

A matrix of some kind from explaining what combinations of components are being tested would be so helpful right now, to have a fighting chance at trying to use this stuff.

Personally I really hope Unity 2019.4 LTS is going to work with this soon.

[rib]

Aah, so I realised that with Unity 2019.4 I still had the OpenVR Desktop package (xr.openvr.standalone) installed and that interferes with this. Once I remove that then it looks like 2019.4 starts to behave in the same way as 2020.1 - I can see the default action set get activated but I can only see pose action data. It could be good if some of the quick start documentation clarified that this package should be removed.

[rib]

OK, so my next realization has been that either the Live View is broken or its behaviour is really not what I would have expected.

I found that if I add a very simple behaviour to an object to read an action state within the Simple Sample scene like:

    void Update()
    {
        if (SteamVR_Actions._default.InteractUI.state)
        {
            Debug.Log("InteractUI");
        }
    }

then I do start to see the Live View showing state updates for the InteractUI action. So the Live View is apparently not a direct view of the input itself, but rather a view of the application reading the input data?

Surely that's not how the Live View is intended to work?

Since I've only done an extremely simple test, I don't know if I'll hit some other issues similar to @GeekBrony but at least checking the default InteractUI state worked for me in 2019.4 and 2020.1 with the 2.6.1 plugin.

[zite]

Thanks for going to the trouble of troubleshooting through this @rib . Let me clear some things up. The desktop plugin should get automatically removed if you're using the new xr plugin. That's a bug that we can look into. Live View is intended to work that way, yellow is supposed to show actions that have not been accessed yet. We do a "lazy-loading" style of access so we're not querying all possible actions from every input source. There is an option to change this behavior in the code, but maybe we also need to make this more obvious in the live view.

@GeekBrony are you still having these issues?

[rib]

Thanks for the clarifications.

I can see how it might not be ideal for the viewer to have to poll all possible actions if there's no underlying event mechanism - though does the list of currently active actions typically get that long that it would really pose an issue only while the debug viewer is open? I guess if that's a real concern then yeah maybe there could be some UI tweak to maybe make the behaviour clearer (sorry if I missed some description that already tries to explain this).

About the openvr desktop package, I did disable an auto update option because I got stuck in some kind of infinite update loop that I had to break (I interrupted it by putting a compilation error in some of my code) and maybe doing that also short circuited the code that would have checked for the desktop package?