XR elevation control

[QuintessentialForms]

Let the user control elevation (y-level altitude, to raise or lower camera view) with the right controller y-axis (currently unused).

Because the navigation is missing this control, in order to adjust elevation viewpoint in a scene, the user must stand on a chair or get a ladder in the real world, which can cause injury when wearing a VR headset. (This is a joke, no one would try that. It is necessary to use a different viewer app.)

Description

Allowing the viewer to control the elevation is standard in all VR/XR applications, except for first-person games where mobility is restricted for gameplay rules. But in the Playcanvas engine WebXR viewer navigation system, when viewing a scene in VR or AR, the user is locked into a single elevation. In AR, if the scene's data floor doesn't align with the real-world floor, the scene is permanently broken and unusable with this viewer.

Fix

The fix requires one line to adjust the elevation.
I implemented in my local dev version, tested it, and found it working flawlessly on Desktop (SteamVR) and Mobile (Quest3).

I appreciate you taking the time to read this pull request. If you would like me to make any changes, please let me know, or feel free to change as desired.
Thank you for all the hard work and time you have invested in this great viewer for the open-source community.

Checklist

• [ ✓ ] I have read the contributing guidelines
• [ ✓ ] My code follows the project's coding standards
• [ ✓ ] This PR focuses on a single change

[Maksims]

Allowing users to move Y of the camera origin, in most cases will lead to undesirable results, and cannot be done precisely by user, to match virtual floor level with estimated floor level. This should be done by application developer, ensuring that floor plane is at Y 0.

Let the user control elevation (y-level altitude, to raise or lower camera view) with the right controller y-axis (currently unused).

When using local-floor space type, the VR platform will estimate your elevation over the floor, and position camera accordingly.
Adjusting manually elevation in such case - is highly unrecommended, to ensure user fell planted on the floor, instead of unintentionally floating. This applies to standing and sitting cases.

When using local space, then yes, it is reasonable to provide some control over elevation, as VR sub system will position camera at Y 0 by default. And application can rely on that various ways - for example lying down on the bed, or first person flying, etc.

Allowing the viewer to control the elevation is standard in all VR/XR applications, except for first-person games where mobility is restricted for gameplay rules. But in the Playcanvas engine WebXR viewer navigation system, when viewing a scene in VR or AR, the user is locked into a single elevation. In AR, if the scene's data floor doesn't align with the real-world floor, the scene is permanently broken and unusable with this viewer.

In AR - this should not be allowed at all, as in AR application is almost always using floor based tracking, and will require scene match with the world 1:1. So virtual floor should be placed at Y 0, as WebXR system will be expecting in in various ways, not only from tracking point of view, but also all other APIs (e.g. hit-testing).

So instead of providing unreliable way of adjusting height to users, which they will not be able to do precisely ever. Application should simply match Y 0 with the floor.

[QuintessentialForms]

So instead of providing unreliable way of adjusting height to users, which they will not be able to do precisely ever. Application should simply match Y 0 with the floor.

Well, I have the modified code for myself, so this doesn't hurt me. But when someone has a g-splat of a two-story building, they want to go to both stories. When they have a model, they want to see it from above and below. When they have an AR object, they want it on the floor, then to move it to the desk. Always, giving the user control is the right way to develop.
It is a strange response, but this is why I don't do open source. Have a good holidays.

[Maksims]

So instead of providing unreliable way of adjusting height to users, which they will not be able to do precisely ever. Application should simply match Y 0 with the floor.

Well, I have the modified code for myself, so this doesn't hurt me. But when someone has a g-splat of a two-story building, they want to go to both stories. When they have a model, they want to see it from above and below. When they have an AR object, they want it on the floor, then to move it to the desk. Always, giving the user control is the right way to develop. It is a strange response, but this is why I don't do open source. Have a good holidays.

Good example. For that app developer should provide a meaningful way to switch between floors, with set altitudes. So that user have good experience navigating the splats.