Skip to content
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

Exposing confidence levels through the API #3

Closed
bialpio opened this issue Sep 28, 2020 · 1 comment
Closed

Exposing confidence levels through the API #3

bialpio opened this issue Sep 28, 2020 · 1 comment

Comments

@bialpio
Copy link
Contributor

bialpio commented Sep 28, 2020

The current API shape does not expose confidence levels even though both ARKit and ARCore provide this information, in 2 different ways:

  • in ARKit, the confidence map is a separate attribute available on ARDepthData
  • in ARCore, the confidence values are packed in 3 most significant bits of depth buffer entries, moreover, they are currently documented as being equal to 000s.

It seems to me that the cleanest way to expose confidence levels via the depth sensing API is to add a separate attribute to XRDepthInformation (an Uint8Array?). This would mean that for ARCore implementation, we'd need to make sure to always copy 3 most significant bits of depth buffer entries into a separate buffer (if we decide to expose this information), and mask them in the depth buffer to always be set to 0 in case the underlying ARCore code changes. It would also mean that we'd have to surface this as 1 more opaque WebGLTexture so that it's available for GPU consumption (assuming that we want to optimize for GPU access, see my comment). Additionally, for devices that support depth, but do not offer confidence values, it would be simple to just return null to communicate this.

If the above sounds acceptable, the current API shape allows us to add the separate attribute once that's something that's needed & I'm not worried. Alternatively, if we were to pack confidence levels in the depth buffer entries (ARCore-style), this is something we need to decide on now to ensure we're not making breaking changes later.

@bialpio
Copy link
Contributor Author

bialpio commented Oct 7, 2020

Closing the issue, it makes no sense to follow the underlying SDK's API and try and pack the data since this results in less clean API shape.

@bialpio bialpio closed this as completed Oct 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant