Search Unity

Resolved OpenXR/SteamVR: InputTracking.trackingAcquired event not firing

Discussion in 'XR Interaction Toolkit and Input' started by gjf, Sep 16, 2021.

  1. gjf

    gjf

    Joined:
    Feb 8, 2012
    Posts:
    53
    Events registered with
    Code (CSharp):
    1. InputTracking.trackingAcquired
    (or any of the other InputTracking events) don't fire in a Windows (x64) build but work perfectly well in the Unity editor.

    The project is configured to run on Windows/Oculus Quest depending on build settings - everything else (headset rendering, controller input, haptics, etc.) works as intended/expected.

    In Windows builds, the callback is used to determine whether to hide the desktop display if the headset tracking is lost - it prevents some unsightly images for the audience (viewing the VR user).

    Running the following versions:
    • SteamVR 1.19.7 (EDIT: This is the desktop app)
    • Unity 2020.3.18f1
    • OpenXR 1.2.8 package
    • Oculus XR 1.10.0 package
    • XR Plugin Management 4.0.7 package

    Do these callbacks not work?
     
    Last edited: Sep 17, 2021
    gjf, Sep 16, 2021
    #1

  2. TreyK-47

    TreyK-47

    Unity Technologies

    Joined:
    Oct 22, 2019
    Posts:
    1,822
    Hey there! So, the SteamVR plugin is developed and maintained by Valve. You'll want to post your issues on their Github so their team can address.
     
    TreyK-47, Sep 17, 2021
    #2

  3. gjf

    gjf

    Joined:
    Feb 8, 2012
    Posts:
    53
    InputTracking is part of Unity, so I posted it here.

    The SteamVR referenced in my post is the desktop client, not an installed package in the Unity project - that uses OpenXR/OculusXR.
     
    gjf, Sep 17, 2021
    #3

  4. the_real_apoxol

    the_real_apoxol

    Unity Technologies

    Joined:
    Dec 18, 2020
    Posts:
    467
    We will look into this and see if they should be working.
     
    the_real_apoxol, Sep 29, 2021
    #4
    gjf likes this.

  5. the_real_apoxol

    the_real_apoxol

    Unity Technologies

    Joined:
    Dec 18, 2020
    Posts:
    467
    Can you post some code for what you are trying to do? We wrote a test to make sure controllers that lost tracking were having their tracked state changed with OpenXR and that those callbacks were being called and could not find an issue.

    Code (CSharp):
    1.          
    2. InputTracking.trackingAcquired += (ns) =>
    3.             {
    4.                 Debug.Log($"{ns.nodeType}: {ns.tracked}");
    5.             };
    6. InputTracking.trackingLost += (ns) =>
    7.             {
    8.                 Debug.Log($"{ns.nodeType}: {ns.tracked}");
    9.             };
    10.  
    EDIT: I just remembered you said standalone build was the problem, trying that now.

    EDIT: looks like it worked in standalone too
     
    Last edited: Sep 29, 2021
    the_real_apoxol, Sep 29, 2021
    #5
    gjf likes this.

  6. gjf

    gjf

    Joined:
    Feb 8, 2012
    Posts:
    53
    Thanks; my code is similar:

    Code (CSharp):
    1. InputTracking.trackingAcquired += TrackingAcquired;
    2. InputTracking.trackingLost += TrackingLost;
    then ...

    Code (CSharp):
    1. private void TrackingAcquired(XRNodeState node)
    2. {
    3.     //...
    4. }
    I'll take another look in the morning. Which version of Unity did you use? I'm still on 2020.3.19f1

    Cheers,
    g.
     
    gjf, Sep 29, 2021
    #6

  7. the_real_apoxol

    the_real_apoxol

    Unity Technologies

    Joined:
    Dec 18, 2020
    Posts:
    467
    I was using 2020.3.17f1 when I ran these tests.

    What headset and runtime are you using?

    Can you send me a `player.log` for the standalone run so we can take a look?
     
    the_real_apoxol, Sep 30, 2021
    #7

  8. gjf

    gjf

    Joined:
    Feb 8, 2012
    Posts:
    53
    Well, this is annoying.

    The headset was an HTC Vive.

    I've just built the Windows version again and the callbacks are now firing. The ONLY change on my side was bumping the Unity version (from 2020.3.18f1) to 2020.3.19f1. That said, you're using an earlier build... I know that I wasn't imagining it.

    I'm assuming that one of the following has occurred:

    1) 2020.3.18f1/the packages used were broken in some way.
    2) I'm losing my mind.

    I don't have time to go back and install 2020.3.18f1 to confirm that it was an issue, just happy that it appears to be resolved.


    Thanks for taking the time to look at the issue - very much appreciated.
     
    gjf, Sep 30, 2021
    #8
    the_real_apoxol likes this.