Add XRView to XRDepthInformation #50
Conversation
|
Spoke offline yesterday and proposed some way to make this not a breaking change, suggested adding a new dictionary member that can be default false and |
|
This was discussed at TPAC and the consensus was that we should return an |
cabanier
changed the title
|
Addresses #45 |
|
Overall this approach seems fine; except that I thought we had also discussed a way for the site to opt-in/acknowledge "Yes, I'm willing to handle this optional view" (Which may have been either a method to populate that view or to otherwise acquire it?) |
Yes, I didn't add that yet because the power outage stopped our meeting mid-way |
|
@alcooper91 do you want to address the optionality first before this is merged? |
|
Yeah, I'd prefer to land that all at once so we don't have a weird in-between state of the spec. I won't be able to attend the next meeting, but I'm happy to go along with whatever folks decide if you think we should continue the discussion at that? |
|
/agenda discuss adding an optional feature that accomodates slower depth refresh rate |
There was a problem hiding this comment.
matchDepthView seems fine, but I think depthNear and depthFar address a different issue, so I'd prefer if we could split them to their own PR (though I also thought we had discussed that maybe we didn't need them, but it somewhat depended on some math that we should potentially include in the spec if we do?).
I'm not sure that the isValid change is necessary, given that we can also simply return null, per the existing spec text? I worry that sites will not check this and will simply expect that if they receive an XRDepthInformation that it is valid.
| }; | ||
| </script> | ||
|
|
||
| The {{XRDepthStateInit/usagePreference}} is an ordered sequence of {{XRDepthUsage}}s, used to describe the desired depth sensing usage for the session. | ||
|
|
||
| The {{XRDepthStateInit/dataFormatPreference}} is an ordered sequence of {{XRDepthDataFormat}}s, used to describe the desired depth sensing data format for the session. | ||
|
|
||
| The {{XRDepthStateInit/matchDepthView}} requests that {{XRDepthInformation/view}} of the depth information must be in sync with the {{XRView}}. If this is <code>true</code>, the {{XRSystem}} SHOULD return depth information that reflects the current frame. If this is <code>false</code>, the {{XRSystem}} MAY return depth information that was captured at an earlier point in time. |
There was a problem hiding this comment.
If we're going to allow an earlier point in time, we should probably add a time element to the data?
There was a problem hiding this comment.
At least on our platform, we don't return the time that the depth was captured. I'm also unsure what it could be used for.
index.bs
Outdated
| }; | ||
| </script> | ||
|
|
||
| The {{XRDepthStateInit/usagePreference}} is an ordered sequence of {{XRDepthUsage}}s, used to describe the desired depth sensing usage for the session. | ||
|
|
||
| The {{XRDepthStateInit/dataFormatPreference}} is an ordered sequence of {{XRDepthDataFormat}}s, used to describe the desired depth sensing data format for the session. | ||
|
|
||
| The {{XRDepthStateInit/matchDepthView}} requests that {{XRDepthInformation/view}} of the depth information must be in sync with the {{XRView}}. If this is <code>true</code>, the {{XRSystem}} SHOULD return depth information that reflects the current frame. If this is <code>false</code>, the {{XRSystem}} MAY return depth information that was captured at an earlier point in time. | ||
|
|
||
| NOTE: If {{XRDepthStateInit/matchDepthView}} is <code>false</code>, the author should do the reprojection using the [=XRDepthInformation/view=] from {{XRDepthInformation}}. |
There was a problem hiding this comment.
Do we want to provide any sample math for this? (I have some in Chromium C++)
There was a problem hiding this comment.
We could add that as an informative note but I prefer if we updated the sample.
There was a problem hiding this comment.
Per meeting this week, let's start with the sample.
|
@cabanier what's the status on this? |
I'd still like to expose this through the depth API. Reprojection of the depth pixels is a lot more efficient if it is done by the developer. |
|
Oh I agree! I was just asking if there were any other blockers beyond the cleanups we had most recently discussed |
I don't think so; I've just been to busy to spend more time on it |
+ made reprojection optional
cabanier
force-pushed
the
viewmatrix
branch
2 times, most recently
from
708607c to
a4969a7
Compare
|
LGTM, I think the only other things we may want to add before we merge are potentially exposing the time and the other little bit of text that may need to be updated? |
SHA: 3cf417f Reason: push, by cabanier Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
/tpac
Preview | Diff