Async offset will be limited to yaw-only

[balukin]

Random offsets don't play well with new rotational smoothing + reprojection and it doesn't seem like there's a real use case for it. External drift correction can lead to many problems and introduces unneeded complexity to tracking mixing.

The feature will also work incorrectly on high-quality VR devices with reprojection in 2.2.x but those devices don't usually need any drift corrections and it seems extremely unlikely that someone uses it in these scenarios.

If anyone is using it and has no way to replace this feature, please comment on this issue.

[benjanyan]

I've noticed that setting an offset in the beta version causes strange things to happen. As in the view ports seem to become smaller depending on the offset. Is that related to this?

If we still want to keep offset in check with V4, does this mean switching to the (potentially performance killing) synchronous headtracking API to correct drift?

My own use case is using a Kinect to keep drift on an LG V30 in check (as well as provide headtracking). Otherwise I have to recenter fairly often.

[balukin]

What you're seeing is reprojection correcting the rotation to original orientation. The higher the drift is, the lower the actually rendered viewport will be (because it becomes more and more out of sync). We left this unchanged in 2.2 because we didn't expect that headsets with reprojection (such as your, as it's Daydream-enabled) would require drift correction.

We discussed how to proceed with offset (both sync and async) because there were quite a lot of changes in 2.2.x versions related to positional tracking. In the end, it was extremely time-consuming to make the offset work in all cases (with API tracking, with Nolo tracking, with reprojection enabled, with controllers (AIO or API) and with any kind of combination of listed options). It becomes even more complex with controllers (some controllers can be recentered in their own environment, some controllers need to use our internal recentering (another offset), the complexity grows dramatically with each device's internal orientation system and recentering mechanism.

Eventually we decided to deprecate it because we can't assure that it will work in all cases. You already experience one of those problems (async offset + reprojection).

Your options are:

1) The wild idea would be to use your external tracking system to detect when you're looking forward and call API's Recenter command every now and then. It might work but I haven't tested it and it might result in some problems. This API call results in the same action on the server side as pressing recenter hotkey. 2) We can build you an APK of 2.2.6 version that has reprojection disabled. This will significantly affect the smoothness in negative way but will still work with async offset. Let us know if you'd like us to build it. 3) Stop using offsets until we figure how to bring it back universally to work with all combinations.

Sorry for the trouble. It can be solved with another layer of math and offset matrix recalculations, we just didn't want to spend a week on it because we weren't even sure if someone uses it. We don't have API access keys/analytics so we're sort of blind when it comes to knowing what is actually used by API developers.

We would like to fix it in v4/2.3 but I can't promise anything solid yet. Let me know if any of the above listed options is viable for you until then. We might come up with something else.

[benjanyan]

Thanks for the comprehensive reply. I've been trying your first idea which sort of works although it's obviously not as flexible as using offset.

I wouldn't like to lose the reprojection as it is quite a nice feature. :) I may just wait and hope that you can come up with an idea to improve this.

I haven't got any other experience with other Daydream devices so I'm not sure if the drift I suffer from is specific to the LG V30. It's noticeably worse than the PS Move controllers.

[balukin]

Daydream drift is quite surprising, really. We didn't expect it as it never came up during our testing but it's always possible that we didn't run tests that were long enough to notice it drifting off few degrees.

We hope to have a solution for it because we need to refactor tracking systems a bit anyway. Currently the most limiting factor is API v1 (from VRidge 1.3 if I recall correctly) which is still compatible as Nolo desktop driver uses it so we can't drift off too much from original specs & tracking mixer. We'll figure something out.

[benjanyan]

I've realised the cause of the drift in my case. The viewer/headset I was using had a magnet on the door so the magnetometer was probably disabled. It's not so much of an issue when I tried the official Google Daydream viewer. It had never occured to me before.

Edit: I take back what I said abouit it not being so much of an issue. It's still an issue that becomes quite apparent with 5-10 minutes. It's present in Daydream apps as much as Vridge

[balukin]

Progress update I'm 99% sure that async offset will stay unchanged and won't have problems with reprojection in 2.3 update. We just need to run all the backwards compatibility tests before being 100% sure.

[balukin]

Currently we're aiming to keep yaw offset working with backwards compatibility (other components would be ignored). Other components are much less usable and yaw is enough to correct sensor drift.

[quartzsaber]

Current on beta channel (2.3.9), Async offset does not work at all. I provided yaw data but the camera did not move.

Tried settings: task type = 201 data = [0, 1, 0], [0, 3.14, 0], [0, 100, 0], [100, 100, 100], [3.14, 3.14, 3.14], [1.57, 1.57, 1.57], [0, (0..10 linear), 0]

All did not work :(

Minor note: Using recenter for drift correction does not feel good because it snaps.

[balukin]

@min050820 Can you show me a code sample?

I just tested both with new and older v3 API clients and it seems to work as expected.

Tested with desktop example from this repo @ latest public commit (https://github.com/RiftCat/vridge-api/commit/0eef9ce41f8bd3edfde9f7d914c31ceb9a1d9cae)

Also, please check out the same desktop example above to see if it works for you. This way we can narrow the source of the problem and check if it's API client or server issue.

[quartzsaber]

@balukin Okay, so it indeed was my fault. I'm terribly sorry.

[balukin]

Closing. Discussed changes are now in effect and merged into stable VRidge channel and master branch of this repo.

Offset is now limited to yaw axis only. Older API calls will be converted and non-yaw data will be discarded but yaw offset should still be correctly applied without breaking reprojection. It will also correctly reorient 3rd party and our controllers.