Closed chrox closed 1 week ago
The Pico controllers work fine now after adding the interaction profile for /interaction_profiles/pico/neo3_controller
.
Sorry @chrox , I totally missed you creating this PR.
I'll need to give it a proper review when I have some time and probably @m4gr3d should have a look at this too.
One problem that I think may end up being a showstopper, and the reason we never added more then Quest support to the plugin, is that deploying loaders from other vendors, even if they are unused, will likely be flagged if you actually want to submit your game to the platforms stores.
Just like with the Godot 4 solution, we would really need a separate plugin for Quest, a separate one for PICO, and a separate one for others, with a choice of which one to deploy on export. Sadly we don't have that ability in Godot 3.
We might be able to work around that with export filters but it won't be pretty.
I'm hoping with some tweaks coming to OpenGL support in Godot 4 in the next build, we'll be at a point where Godot 4 is a far better choice for XR projects then Godot 3 and we can start advising anyone who want to target Pico or HTC or other Android based XR headsets to port their game over to Godot 4.
We have already ported our product to Godot 4 so I'm closing this PR in favor of GodotVR/godot_openxr_vendors#13.
This PR is largely ported from
godot4
OpenXR module. And now on Android thelibgodot_openxr.so
will not be linked with the vendor provided proprietarylibopenxr_loader.so
. And the loader for specific devices will be loaded accordingly at runtime by checking the device brand so that only one APK package is needed for both Meta and Pico devices.This PR is tested on Pico 4 and Quest 2 and may help to solve #171.
In order to test on Pico devices, the following meta-data is needed in the AndroidManifest.xml file: