godot_openxr_vendors
godot_openxr_vendors copied to clipboard
GodotVR
Add manifest entries for Magic Leap
This PR adds in manifest entries for Magic Leap 2 based on https://developer-docs.magicleap.cloud/docs/guides/openxr/getting-started/android-manifest-settings/
It's not clearly defined in the writeup here but from what I gather the hand tracking is a normal permission and doesn't require further user interaction.
The interaction can be found under the Khronos heading:
I've not added checks in whether HTC and Magic Leap settings are both selected. There is an argument for splitting these up and creating a Khronos generic, HTC and Magic Leap AAR, we'll likely have to go down that path at some point, but so far it seems to be working.
I can't test on a Magic Leap myself but we have a user on discord who's likely able to test this for us.
I've not added checks in whether HTC and Magic Leap settings are both selected.
We should include a vendor drop down under the khronos section and only show the options for the vendors that is selected.
I've not added checks in whether HTC and Magic Leap settings are both selected.
We should include a
vendordrop down under the khronos section and only show the options for the vendors that is selected.
Is that possible in that interface? That would definitely be the preferred option. It can then also have a "other" options that just exports without any platform specific flags that hopefully works on future devices
I've not added checks in whether HTC and Magic Leap settings are both selected.
We should include a
vendordrop down under the khronos section and only show the options for the vendors that is selected.Is that possible in that interface? That would definitely be the preferred option. It can then also have a "other" options that just exports without any platform specific flags that hopefully works on future devices
@BastiaanOlij The second commit of https://github.com/GodotVR/godot_openxr_vendors/pull/181 showcases how to do so.
@BastiaanOlij Can you update the changelog.
Done, also rebased and added an export preset for Magic Leap.
Turns out Magic Leap is an x86_64 device, not arm :) Had to update the export preset accordingly.
During xR meeting discussed whether we should have an HTC entry and Magic leap entry separate just like we have a Pico entry, to make this more managable. Might redo this PR to show that approach.
During xR meeting discussed whether we should have an HTC entry and Magic leap entry separate just like we have a Pico entry, to make this more managable. Might redo this PR to show that approach.
@BastiaanOlij Should this be put as a draft for now?
During xR meeting discussed whether we should have an HTC entry and Magic leap entry separate just like we have a Pico entry, to make this more managable. Might redo this PR to show that approach.
@BastiaanOlij Should this be put as a draft for now?
Yes I'll change it, I just need to find some time to make the needed changes
Apologies for taking so long to finally redo this one.
As discussed in the XR meeting a few weeks ago, we've decided to start creating separate export plugin entries for each vendor even if they are using the Khronos loader. This so we can separate out the needed manifest entries and privilege handling. As we minimize what we duplicate and ensure in our export that only relevant binaries are included, this seems to be the best path forward to deal with the differences between vendors.
Eventually the Khronos entry should become an entry that makes no assumptions about the vendor and result in an APK that can run on any Android device but won't be able to make use of any vendor specific logic that requires vendor specific manifest entries. This is a future target as this requires changes/enforcement in the OpenXR spec that currently is not available.
At some point in the near future we will thus make HTC its own export plugin, but that is not covered by this PR.
This PR purely implements Magicleap as an export plugin similar to what we've already done with PICO. Both also use the Khronos loader. These two now form the blueprint for other platforms we intent to add in the near future.
XR Meeting 23/08/24
Think we should merge this soonish because we can't fully test this. If there is an issue we can always do a fix. Fredia to do a final Code Review Bas to update CHANGES.MD
Need to time this if we do indeed release a 3.0.1 patch or if we're going straight to a 3.1.0 release as our next release.
@m4gr3d shall we go ahead and merge this? I'm assuming the simulator failure can be ignored?
I'm assuming the simulator failure can be ignored?
I just reran the tests and they are passing! The old logs appear to be gone, so I'm not sure what they were failing on before - it could have been the issue with Meta's NPM server? In any case, seems to be fine now.
Yep, I checked the NPM server when the first errors were logged here and it (the server) was failing on every http request... but don't know enough about the (our?) build process to feel I could confirm or add anything useful at the time. Checked again this morning when Bas updated and it was fine (though up to v68 of the simulator as latest now, which I originally thought might have been a contributing factor. Evidently not, though).
Good spot, and fix, guys. (y)
