BattleAxeVR
commented
6 months ago (and yes, for anyone looking at the code I wrote closely, on Oculus Touch you do apparently have to use /value instead of /click for trigger boolean click events, it just treats the float as a bool)
This is NOT a bug, I double checked it last night, triggers and grips don't support the /click XrPath on Quest:
corporateshark
Hi, I implemented the Touch controller bindings in my branch, do you want me to make a "clean branch" with just that in it and PR it?
Would this be useful to anyone? IMO a complete "hello world" XR app should show and use VR motion controllers, not just display a rotating cube. Like hello_xr. I haven't added any cubes to draw using the grip or aim pose or anything to the base samples (nor do I plan to), but at least having the bindings set up properly is good to have, right? I have bindings handy for all the other HMDs' controller types: HTC, Pico, Touch Pro controllers, and there are a bunch that are PC only.
The current XrApp update loop doesn't call XrSyncActions (in pollActions) so your framework won't support OOTB controllers or other events being polled at all, even if you add those bindings later. I'm not sure TBH if you can even add more bindings after the session is started.
If you actually want this PR I'll clean up my code and stuff it in another branch for a clean PR.
I also have Link Sharpening implemented which looks / works great (at least when using only 1 layer).
Doing this work made me realize that the current implementation of XrApp.h vs two XrApp.cpp has a TON of code reuse which is bad practice and results in duplicated work (see https://github.com/facebook/igl/issues/94).
But I can't help but think that if IGL actually is to become useful to many people, the default main branch should have this stuff and generic code shouldn't be duplicated. I'd rather merge the controller bindings PR for just Touch controllers then you can refactor it after to remove duplicated parts that are common. There's no problem adding ex Vive or WMR bindings in a generic way on mobile, even though they are PC-only devices, because the runtime simply picks the best interaction profile to use at runtime. This is how hello_xr works, of course.
OpenXR SDK Source code is almost entirely generic between PC and mobile builds, the main differences are just in the initialization structs, extensions, and of course in their renderer / platform classes. But those are abstracted away (for better or worse, I needed ability to poll the Xr statuses from another thread for async / higher Hz polling rates used for CloudXR, so I made pollActions public and take an argument specifying which thread it's being called from, main or async thread. It could be enabled in both, as those booleans are independent in my code. Use case: when I connect to CloudXR and the async polling starts of controller states, I don't need the local poses updated so I flip that boolean. However, instead of using an enum to pick which, when I enable a locally drawn UI on top of the video stream, I will need both threads to poll their own states, and thus a separate copy of the states for each one. I've implemented this before and this is the only way to avoid dropped button transition events when one thread is polling at say 240 Hz and the main thread at 90 Hz, synchronous to the refresh rate).