Controller poses seem off in all versions of CloudXR OVR Client for Quest. Anyone else seeing this?

So, I tested this with CloudXR 3.0 and 3.2, just now, on both Quest 1 and Quest 2, and it’s a 100% repro for me. All you have to do is try to hold the two controllers’ rings together and they have a gap between them.

The same exact controller pose when you pause CloudXR client, even temporarily, instantly makes the controller poses correct.

Is this a known bug, and if so, is there a workaround?

Let me know, thanks.

1 Like

Here’s a quick video showing the discrepancy between the controller poses between the local VRAPI-reported pose and that which SteamVR sees through CloudXR libraries:

You can clearly see here, as I toggle back and forth, that the poses don’t match.

This is the same behaviour in 3.0 as 3.2 and several of our customers reported having to use SteamVR Advanced Settings to adjust the controller poses, in order to make the controllers line up properly. This shouldn’t be necessary, right? Anyway it looks like there’s something wrong to me so I’d like a confirmation. I tested it on several machines and on Quest 1 and 2 and several versions of CloudXR and SteamVR. All the same issue.

@GJones-NVIDIA-XR-Team @Veronica_NVIDIA any idea here? This is really a problem for us.

@tegradave Hi Dave, I was just wondering if this is a known issue. The repro steps are very straightforward. Just hold the controllers together ring-to-ring and see if there’s a gap or not.

I’ve been experiencing the same issue. Have you managed to fix it?

Not yet, we put it lower priority for now but have more serious (actually show-stopper) problems with the Quest client connecting / disconnecting. There’s a bug in the connection handling code somewhere we think.

I would love to hear from Nvidia about this, if it’s a known issue on their end and if there is a fix incoming at some point.

1 Like

I did some comparisons between AirLink and CloudXR 3.2 in SkyrimVR, and the controller poses are different there too, in the amount of forward rotation that’s applied.

In AirLink, if I hold a sword or a torch or a mace, it sticks upwards as if I were holding the grip using the touch controller’s grip axis, in the exact same direction. In CloudXR, it points forward by maybe 30 degrees.

you can check client code(at least on oculus as I saw), they have manual offset where you can edit by yourself.

yeah, I’m aware, I just don’t understand why the default value was chosen to be that, as it doesn’t match what SteamVR games expect. So I consider that a bug in the sample code. What worries me more is that the value is actually correct for controllers in SteamVR home (at least as far as rotation goes), but incorrect for in-game. Which would be a far more serious, platform-level bug with CloudXR.

I applied some rotation and position offsets to get it much closer.

For example, the default rotation offset in the sample is set to 0.4 radians, I find 0.8 is much closer to the expected value so that the controllers are pointing the same direction. There is also a position offset needed, in worldspace rotated by the original controller rotation quaternion (prior to the rotation offset). I’ll share the values here to save anyone else the headache. A bit more attention to detail is warranted here I think, the rotation is way off in the sample and there is no translation, which is totally necessary as well.

1 Like