VDXR + Bonelab P4 - Controllers not tracked

[soup587]

Describe the bug

Bonelab, as of patch 4, no longer tracks your controllers when ran with VDXR. Button input is read, but your hands get stuck in the same position relative to your headset

Environment

Bonelab - Latest Virtual Desktop - 1.32.4

To Reproduce

Launch Bonelab with VDXR set as the OpenXR runtime, attempt to move controllers

Expected behavior

Controllers are tracked correctly, in-game hands move accordingly

[mbucchia]

Have you reported the issue to SLZ? It's their patch that broke it. As far as I'm concerned it's an issue with the OpenXR plugin they use (also exist in Eleven Tennis Table), and there is nothing I can do (VDXR reported the correct tracking data - game ignores it).

[mbucchia]

Evidence of VDXR reporting valid data to the game:

Y=1.484m this height is correct X & Z are negative (left + forward) as expected Quaternion is normalized (aka valid)

[soup587]

[mbucchia]

Without any explanation of what they think the actual problem is. How cheap. Controllers are working with all games except theirs...

I suppose we will just remove it from our compat list side their developer doesn't want to be helpful.

[soup587]

[mbucchia]

I've already marked the game as not support from my side. I also have no interest in drama.

SLZ has a very short memory it seems. Most OpenXR implementations today contain non-standard code as the result of THEIR MISTAKES that we all had to salvage on launch week because of their incorrect usage of OpenXR. I personally lead the campaign in Sep 2022 to make all vendors across the industry adopt the non-standard extension they needed. This represented over 20 hours of mostly unpaid work. So you'll understand why their attitude today isn't boding well with me here.

[Greased-Scotsman]

Hi @mbucchia. I hear your frustration and it appears that my comments were heard as blame or as accusations, which was not my intent. I was not involved with troubleshooting OpenXR problems in earlier releases, and I can see how my lack of awareness of those issues came off as me invalidating/dismissing the extra work you put in. I'll try to be more careful with my comments in the future.

[yewnyx]

Hi, I'm one of the developers at SLZ who worked on part of the inputs, and originally debugged some of the issues with controller tracking and OpenXR runtime issues.

Apologies for any conflicts, I've never heard of any issues with VDXR nor been contacted about them; I am not very community-facing so there seems to have been some miscommunication along the way.

I would love to know more about issues you've had historically and currently and see if there's anything I can chase down on my end.

[yewnyx]

Hey @mbucchia, I've reproduced the issue locally.

I'll dig in and see what I can do on my side to figure this one out. I have my suspicions, though due to personal circumstances I may not be able to address this right away.

[yewnyx]

Mixed news, but mostly positive:

I'm happy to report that this is working on our development branch. It seems that at some point between the public release, and the current in-development branch, this started working, so at least in terms of an eventual fix, this is a non-issue, and can remain closed, though it may be disappointing in the short term that it doesn't work. Unfortunately, it is difficult at this point in time to backport any fix, as the two versions are diverged.

Here's what I looked into:

I double-checked between the current public release and our latest internal development branch, and tested against VDXR on a Quest 2 and Quest 3. I looked at the device Name and Layout in Unity's Input Debugger for the controller, and both of these resolved to values identical to those found on Touch controllers when they are used directly. These are the raw values before our game systems touch the inputs; the lack of tracking on the release version vs the development version is clearly visible.

The alarming part is that there have not been substantial changes to the input system on our end, other than updating official SDKs (i.e. Meta's), fixing Unity's interaction profiles which are, somewhat alarmingly, incorrect for Touch Pro and Touch Plus (Quest 3) controllers by default, and updating Unity versions. These all entailed some amount of resetting or reconfiguring Unity's XR plugin, which we do not significantly customize (although we do enable an OpenXR extension required for handling refresh rate detection in a consistent fashion, this does not impact tracking).

My best guess is that there was a bug on Unity's end that was fixed with a newer version of their XR plugin, and either they, or the resetting of the XR plugin configuration, were responsible for correcting the processing of input data between the XR runtime and Unity.