Pico 4 Ultra Controllers

[kalegd]

Profile id
N/A

Describe the bug
Users have reported to me that their Pico 4 Ultra controllers are not oriented correctly. I'm using the latest version of the input profiles, but the weird thing is that pico 4 ultra isn't even an option, but somehow their controller model is getting loaded? I'm a little confused on how to proceed and rectify this issue

What I know

• This repo only contains the following Pico controllers pico-4, pico-g2, pico-neo2, and pico-neo3
• The above is true when loaded from jsdelivr normally
• When the above link is loaded in the Pico browser, there are additional records for pico-merline and pico-phoenix (`pico-4' is removed)
• A request is then made for oculus-touch-v2/profile.json, but the profile-id comes in as pico-sparrow
• The url for the model says oculus-touch-v2/left.glb, but the model loaded is actually a pico 4 ultra controller

I'm guessing their browser does some weird overwriting thing?

To Reproduce
Steps to reproduce the behavior:

1. Use a Pico device or the Pico device emulator
2. Go to any webxr website that uses webxr-input-profiles like https://sliceofmusic.com
3. Begin an immersive XR session
4. Look at your controllers and see the incorrect orientation

Expected behavior
Generic fallback controller used, or the Pico 4 ultra controller is oriented correctly

Screenshots
Video curtesy of Akumelion from the Pico discord as I don't own this headset (I did verify this strange behavior with the emulator as well)

ScreenRecording_2024.11.11-19.11.45.mp4

3D engine (please complete the following information):

• Engine: three.js
• Version r170

Additional context
Requesting advice on how to best proceed, if anyone has any contacts from the Pico browser/headset teams, or if there are any recommended alternative solutions I could pursue?

[toji]

Hrm. That definitely sounds like they're intercepting the HTTP request and returning their own internal assets. Which I'm not exactly a fan of, but I guess could work out in some limited cases assuming that the assets that they deliver are actually well formatted and aligned. It's unfortunate that they don't seem to have taken the time to validate that here. (Also, this approach won't work for any sites not using that specific CDN.)

@song-fangzhen has contributed assets to this repo in the past on behalf of @picoxr. Perhaps they know who to direct this to? Unfortunately there's nothing that can be done on our side aside from ask that these devices be contributed to the public assets and used normally? Thanks for the analysis, though. It's helpful to know that these kind of strategies are being employed by the hardware manufacturers.

[kalegd]

You're welcome. It looks like @song-fangzhen's last commit in GitHub was October 2023, so I may do some digging to see if I can find a point of contact if they don't respond in the near future

[danny-pico]

@kalegd
Hi,

Do you know if this happens on any other WebXR website? It would definitely help to know the PICO device OS + Browser version. Feel free to send me an email and I can help dig into this issue. I do see the issue with Sliceofmusic.com but it falls back on the Neo3 controller because there isn't a PICO4U profile available as expected. Odd that the user loads up the PICO4 Ultra controller. Did they perhaps add in the controller themselves?

Danny from PICO
[email protected]