New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Async offset will be limited to yaw-only #15

Closed
balukin opened this Issue Aug 3, 2018 · 11 comments

Comments

Projects
None yet
3 participants
@balukin
Copy link
Contributor

balukin commented Aug 3, 2018

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.

@balukin balukin added this to the v4 milestone Aug 3, 2018

@benjanyan

This comment has been minimized.

Copy link

benjanyan commented Aug 5, 2018

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

This comment has been minimized.

Copy link
Contributor Author

balukin commented Aug 6, 2018

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

This comment has been minimized.

Copy link

benjanyan commented Aug 8, 2018

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

This comment has been minimized.

Copy link
Contributor Author

balukin commented Aug 8, 2018

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

This comment has been minimized.

Copy link

benjanyan commented Aug 8, 2018

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

This comment has been minimized.

Copy link
Contributor Author

balukin commented Oct 5, 2018

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 balukin changed the title Async offset to be removed in v4 Async offset to be removed in v4 | Update: maybe not Oct 5, 2018

@balukin balukin changed the title Async offset to be removed in v4 | Update: maybe not Async offset may be removed in v4 | Update: maybe not Oct 5, 2018

@balukin balukin changed the title Async offset may be removed in v4 | Update: maybe not Async offset may be removed in v4 Oct 8, 2018

@balukin

This comment has been minimized.

Copy link
Contributor Author

balukin commented Oct 8, 2018

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.

@balukin balukin changed the title Async offset may be removed in v4 Async offset will be limited to yaw-only Nov 19, 2018

@min050820

This comment has been minimized.

Copy link

min050820 commented Dec 9, 2018

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

This comment has been minimized.

Copy link
Contributor Author

balukin commented Dec 10, 2018

@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 (0eef9ce)

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.

@min050820

This comment has been minimized.

Copy link

min050820 commented Dec 13, 2018

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

@balukin

This comment has been minimized.

Copy link
Contributor Author

balukin commented Feb 1, 2019

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.

@balukin balukin closed this Feb 1, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment