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

Controller and ray position are UA dependent #958

Open
cabanier opened this issue Feb 10, 2020 · 4 comments
Open

Controller and ray position are UA dependent #958

cabanier opened this issue Feb 10, 2020 · 4 comments
Assignees
Milestone

Comments

@cabanier
Copy link
Member

Someone reported an issue on twitter where the pointing ray was intersecting the model that was posted on the WebXR profiles repo.

We addressed that problem but then started thinking if this is something we should have done. Basically, we fixed the problem by changing hardcoded offsets to the positions that were returned by the OS so that the standard controller model and the ray appear in the right location.
However, by adding these offsets on the C++ side, we just changed the location of the pointing rays on experiences that use a different controller.
Moreover, if someone creates a WebXR experience with their own controller model, they will have to test on each platform and keep a list of each platform with different offsets.

/agenda Should there be a standard model that is correct across UAs? Should the WebXR profiles repo also supply correct offsets for position and ray?

@probot-label probot-label bot added the agenda Request discussion in the next telecon/FTF label Feb 10, 2020
@toji
Copy link
Member

toji commented Feb 10, 2020

This is a good topic to discuss, because it's pretty intractable to try and account for every possible custom controller model. Worth pointing out in this case that the primary issue being reported (in my mind) was that the pointer ray in WebXR was noticeably offset from the same ray used by the home screen and other Oculus apps. I'd argue that consistency with the native system is worth making the change regardless of potential issues with custom controller visualizations. The fact that it also happens to fix some clipping issues when using the standard controller model is a pleasant bonus.

@AdaRoseCannon AdaRoseCannon removed the agenda Request discussion in the next telecon/FTF label Feb 12, 2020
@cabanier
Copy link
Member Author

I don't remember exactly what the conclusion was on this topic.
Were we going to wait and see if it was a significant problem down the road and then address it?

@toji toji added this to the Future milestone Feb 24, 2020
@toji
Copy link
Member

toji commented Mar 2, 2020

I don't recall that we had any strong conclusions from this discussion, but I think the general leaning was that this should probably still be allowed to be platform dependent and encourage them to match the platform's native apps whenever possible. Especially given that it's relatively easy to use your own pointer ray when appropriate, but we should also consider advertising the expected pointer ray offset in the webxr-input-profiles entries.

@cabanier
Copy link
Member Author

cabanier commented Mar 2, 2020

I don't recall that we had any strong conclusions from this discussion, but I think the general leaning was that this should probably still be allowed to be platform dependent and encourage them to match the platform's native apps whenever possible.

At least for the Oculus case, we don't return the native platform coordinates. We fiddled with them so the controller from the webxr-input-profiles lines up.

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