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

Consider exposing the XRReflectionProbe off the XRSession object #25

Open
kearwood opened this issue Feb 5, 2020 · 3 comments
Open

Comments

@kearwood
Copy link
Contributor

kearwood commented Feb 5, 2020

As the XRReflectionProbe's cube map can likely be used for multiple frames and is not updated every frame, perhaps it should be exposed on the XRSession object rather than XRFrame. It should also have an event to indicate when a new cube map is available.

The WebGL rendering engine could then interpolate between the last and new cube map when a new one is available.

@mounirlamouri
Copy link

Given that it could be updated at most every frame, wouldn't it make sense to have it hanging on XRFrame and make sure the developer is aware/can figure out if the frame has changed?

@blairmacintyre
Copy link

I agree, I would think it would be in the frame. During the discussion of hit test, and real world geometry, we talked about having a single data structure for "real world info" that any information about the world (hit tests, geometry, illumination, and so on) would be part of (to avoid littering the frame object with extra fields as features are added).

@mounirlamouri
Copy link

During the discussion of hit test, and real world geometry, we talked about having a single data structure for "real world info" that any information about the world (hit tests, geometry, illumination, and so on) would be part of (to avoid littering the frame object with extra fields as features are added).

I think the proposal in this repo doesn't use that object. Piotr's proposal that we have behind a flag in Chrome is this though. In general, we are fine either way. It would be nice to have one object holding things but also would create cyclical dependencies between specs for something fairly minor.

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

3 participants