XRButton defaults to `local-floor`

[michaelthatsit]

Description

Recently switched from ARButton to XRButton and noticed all our content is initializing on the floor, despite setting local as a required option.

Reproduction steps

1. create a scene with XRButton
2. create an object and set it to 0, 0, 0
3. enter XR

Code

this.XRButton = XRButton.createButton(this.renderer, {
    requiredFeatures: ['local']
});

Live example

• XRButton issue

Screenshots

Version

r161

Device

Headset

Browser

Chrome

OS

Android

[mrdoob]

It was intentional.

local made sense for smartphone AR because we were not 100% sure where the floor was nor the scale of things so objects moved around when ARCore/ARKit understood the world better and local-floor resulted in confusing UX.

We are moving towards a Quest 3/Vision Pro world where that's no longer a problem as local-floor is reliable, and the use cases for local become more and more rare.

[Ashbeel111]

An XR button, in the context of extended reality (XR) development, refers to a user interface (UI) element designed for interaction within virtual reality (VR) or augmented reality (AR) environments.

Similar to traditional buttons in graphical user interfaces (GUIs) for desktop or mobile applications, XR buttons serve as interactive elements that users can engage with to perform actions or trigger events within the XR experience.

for more information visit XR Button

[Mugen87]

Shouldn't it still be possible to explicitly request local as a required feature? Since local-floor is always requested as optional feature, I wonder if this breaks the usage of local.

If so and assuming this is intended, we should state local is not supported as a session feature with XRButton.

[mrdoob]

@cabanier what do you recommend we do here?

[cabanier]

@cabanier what do you recommend we do here?

I think we should always request local-floor. I agree local doesn't make much sense anymore.

FYI later this year, we're planning on tackling unbounded spaces; those don't really have a floor (since it can encompass several floors of your house). It's TBD how those are going to be exposed.

[takahirox]

Doesn't renderer.xr.setReferenceSpaceType('local') work for the @michaelthatsit 's issue?

https://threejs.org/docs/#api/en/renderers/webxr/WebXRManager.setReferenceSpaceType

Shouldn't it still be possible to explicitly request local as a required feature? Since local-floor is always requested as optional feature, I wonder if this breaks the usage of local.

My understanding is that requestFeatures and optionalFeatures do not determine the priority of the reference space type used, but are only used to check whether it is supported. WebXR requestReferenceSpace() is called with explicit reference type https://www.w3.org/TR/webxr/#dom-xrsession-requestreferencespace Three.js WebXRManager.setReferenceSpaceType seems to be for choosing a reference space type.

[michaelthatsit]

I feel like requesting local-floor makes sense as the default, but the API provided puts you under the assumption that you can choose your reference space via required features.

This isn't a blocker for us and we found a solution I prefer. But if the defaults can't be overridden in via the feature options, that should be made more clear.

[cabanier]

XRButton.js is not part of the library so you can always take the file and override it with your own logic. I believe it is just providing a reasonable default.