This is purely OpenXR. There is another layer for OpenVR that emulates controllers called Driver Leap, it existed for 3 years or so.
Iāve been able to get this working (ish) with an Oculus Rift S, First Generation LeapMotion and FS2020 installed via the Microsoft Store (not via Steam).
The OculusXR doesnāt seem to support hand tracking. Therefore, you have to switch to using SteamVR (even without launching the game through steam). To do this:
Launch Steam>Launch SteamVR application>Open SteamVR Settings>Show Advanced Options>Set OpenXR to use SteamVR
Once thatās done restart your PC.
To launch:
Open MSFS and start a flight>Open Steam Client>Ctrl + Tab to launch VR>Oculus and SteamVR will launch automatically (might take a few seconds)>wave your hands infront of your face!
If you want to switch back to OculusXR:
Open the Oculus app>Settings>General>Set Oculus as Active under OpenXR runtime
After playing with it for ~15mins my feedback is:
Initially seems to work fine, a bit finicky with actually getting āholdā of controls/knobs etc but generally works. Iāll try and spend some time tweaking settings to see if I can get it more reliable for me.
However, if it loses tracking on one hand (e.g. when holding a joystick) it doesnāt seem to be able to keep tracking the free hand very well. The ghost hand is still there but the controller model disappears and you canāt select anything. Bringing the second hand back in sometimes brings it back to life (after opening and closing fists) but sometimes the controllers keep springing in and out of existance (even when the ghost hands appear to be steady and tracking fine) and you still canāt select anything.
Yes, thatās the same behavior as I described. If you assign a palm touch gesture to trigger laser/direct mode you will find that after going back and forth you can select things again, but only for a short while until the ghost controller disappears. Hopefuly @mbucchia can sort this bug out. In normal fihgl tracking will be lost all the time, when your hands go to yoke/throttles or just your lap. Leap Motion is only tracking when if hands are in front of you. Which is OK for most of the cockpit. Itās actually a good thing that hands disappear when they are out of the frame, less clutter that way.
Not sure what you mean. This should work with any runtime. What are you getting when using the Oculus OpenXR runtime?
I get the same thing that CanisMajoris77 reported earler in this thread. (Link: Hand Tracking in MSFS - Leap Motion / UltraLeap native support for WMR/OpenXR - #241 by CanisMajoris77)
Using OpenXR debug tool. With the Oculus runtime āsupportsHandTrackingā = False. With SteamVR/OpenXR āsupportsHandTrackingā = True.
Using Oculus runtime the log file states the following:
2022-01-22 16:40:20 +0000: XR_APILAYER_NOVENDOR_hand_to_controller layer (Beta-1) is active
2022-01-22 16:40:20 +0000: XR_EXT_hand_tracking is not available from the OpenXR runtime or any upsteam API layer.
2022-01-22 16:40:20 +0000: The XR_FORM_FACTOR_HEAD_MOUNTED_DISPLAY system does not support hand tracking.
2022-01-22 16:40:20 +0000: Failed to resolve symbols for XR_EXT_hand_tracking.
This shouldnāt be an issue with the Ultraleap device. What was reported above was for a user without and Ultraleap device wanting to use the Oculus built-in hand tracking.
In your case the value you are looking at does not matter, because hand tracking should be provided by Ultraleap and not your OpenXR runtime.
May I ask you to try again with the Oculus runtime? The error log you are seeing is common with first time use, and I think itās something about the Gemini software install (apparently I needs a reboot before first use?).
Iām asking you so I can start gather data on what works/what doesnāt. I just donāt see why using the Oculus runtime would not work here and Iād like to double check what you are seeing. Thanks!
Reset to use Oculus runtime and restarted. Same log file as aboveā¦āXR_EXT_hand_tracking is not available from the OpenXR runtime or any upsteam API layer.ā etc
Changed back to SteamVR runtime and restarted. Unfortunately, this doesnāt work now either! See log below.
Changed to Oculus runtime and restarted (again!). Same log file as original.
In summary, Oculus runtime definitely doesnāt want to work and gives a consitent error. SteamVR runtime seems to kind-of work but is a bit tempremental!
2022-01-22 17:27:50 +0000: dllHome is āC:\Program Files\OpenXR-Hand-To-Controllerā
2022-01-22 17:27:50 +0000: XR_APILAYER_NOVENDOR_hand_to_controller layer (Beta-1) is active
2022-01-22 17:28:02 +0000: The XR_FORM_FACTOR_HEAD_MOUNTED_DISPLAY system does not support hand tracking.
2022-01-22 17:28:02 +0000: Failed to resolve symbols for XR_EXT_hand_tracking.
2022-01-22 17:28:59 +0000: XR_APILAYER_NOVENDOR_hand_to_controller layer (Beta-1) is active
2022-01-22 17:29:01 +0000: Using OpenXR runtime SteamVR/OpenXR, version 0.1.0
2022-01-22 17:29:01 +0000: Loading config for āFS2020ā
2022-01-22 17:29:01 +0000: Emulating interaction profile: /interaction_profiles/hp/mixed_reality_controller
2022-01-22 17:29:01 +0000: Hands display is enabled in projection layer 0 with app (if available) depth buffer
2022-01-22 17:29:01 +0000: Using medium skin tone and 1.000 opacity
2022-01-22 17:29:01 +0000: Left transform: (0.028, -0.054, -0.020) (-0.470, 0.027, 0.102, 0.876)
2022-01-22 17:29:01 +0000: Right transform: (-0.028, -0.054, -0.020) (-0.470, -0.027, -0.102, 0.876)
2022-01-22 17:29:01 +0000: Grip pose uses joint: 0
2022-01-22 17:29:01 +0000: Aim pose uses joint: 0
2022-01-22 17:29:01 +0000: Click threshold: 0.750
2022-01-22 17:29:01 +0000: Left hand āpinchā translates to: /input/trigger/value (near: 0.000, far: 0.050)
2022-01-22 17:29:01 +0000: Left hand āsqueezeā translates to: /input/squeeze/value (near: 0.035, far: 0.070)
2022-01-22 17:29:01 +0000: Left hand āwrist tapā translates to: /input/y/click (near: 0.040, far: 0.060)
2022-01-22 17:29:01 +0000: Left hand āindex tip tapā translates to: /input/b/click (near: 0.000, far: 0.070)
2022-01-22 17:29:01 +0000: Right hand āpinchā translates to: /input/trigger/value (near: 0.000, far: 0.050)
2022-01-22 17:29:01 +0000: Right hand āsqueezeā translates to: /input/squeeze/value (near: 0.035, far: 0.070)
2022-01-22 17:29:08 +0000: Failed to create hand trackers.
2022-01-22 17:29:08 +0000: Application is suggesting bindings for interaction profile: /interaction_profiles/khr/simple_controller
2022-01-22 17:29:08 +0000: Application is suggesting bindings for interaction profile: /interaction_profiles/microsoft/motion_controller
2022-01-22 17:29:08 +0000: Application is suggesting bindings for interaction profile: /interaction_profiles/hp/mixed_reality_controller
2022-01-22 17:29:08 +0000: Binding to this interaction profile!
2022-01-22 17:29:08 +0000: Application is suggesting bindings for interaction profile: /interaction_profiles/oculus/touch_controller
2022-01-22 17:29:08 +0000: Application is suggesting bindings for interaction profile: /interaction_profiles/htc/vive_controller
2022-01-22 17:29:08 +0000: Application is suggesting bindings for interaction profile: /interaction_profiles/valve/index_controller
2022-01-22 17:29:09 +0000: Failed to get hand pose: 475520312
2022-01-22 17:29:09 +0000: Failed to get hand pose: 475520312
ā¦repeats for 4000 linesā¦
Cools thanks for the report I will look into this error code. Can you also use the Gemini visualizer to confirm that a Gemini works? I honestly have had situations where the hand tracking didnāt not work (including using their visualizer) and gave weird errors like this, and unplug replug USB was the only thing that worked.
The āUltraleap Tracking Visualiserā shows up fine and places the wireframe accurately.
Thanks for trying to debug this!
Cool thanks for confirming, itās a different issue then. In my case the visualizer just freezes.
Your case is super weird:
2022-01-22 17:29:08 +0000: Failed to create hand trackers.
This still (unfortunately) indicates an error on the Ultraleap side. This message is the result of the call to the UItraleap OpenXR layer to create the hand tracking handles. My bad for not displaying the full error code. The next version will display the error code so we can use it to debug.
But nonetheless this does not point to an issue on my side I am afraid. Which version of the Ultraleap layer did you download from here Releases Ā· ultraleap/OpenXRHandTracking (github.com)?
An update on this. First off I have to come clean about 2 things:
- I donāt know how to pilot. I donāt play the game. I mean Iāve said that a buncha times already so it should be no surprise
- I havenāt been using the original XR_APILAYER_NOVENDOR_hand_to_controller layer for over 3 weeks now. All of my development is focused on the OpenXR toolkit.
With these 2 things said - my latest report is that the issue seems resolved to me. Using the OpenXR toolkit, Iāve just spend over 15 min messing around with knobs in the cockpit, but also move my hands in and out of the camera FOV, and I was not able to hit this issue once.
So for now I am going to assume the problem is solved until you have a chance to test it yourselves in the coming days.
Iām going to try to do something about the āfloating controllersā when tracking is lost, but AFAICT this is a completely different issue.
EDIT: To be clear I donāt know what could have fixed it, but the OpenXR toolkit being an almost complete rewrite, itās just possible that there was a bug and it got fixed with the newer/better code.
EDIT: Floating controllers is fixed too. Thereās a 1 second delay (adjustable) after loss of tracking, so the ghost controllers still āfloatā for about 1 second. I donāt want to go below 1s to avoid intermittent tracking glitches to cause issues.
2 Likes
It now works again using SteamVR! Tried the following:
Restarting a few times
Re-installing Ultraleap layer (Iām pretty sure I had v1.0.1 already)
Unplugging and replugging Leap Motion
But I think the thing that solved it was:
Increase room lighting!!!
I could recreate the problem by switching between room lights at a reasonable level to having lighting the power of a second sun beaming on to my deskā¦
Still doesnāt answer the question of why it doesnāt work with OculusVR of course!
Look forward to the updated release to see if it does indeed solve some of the hand tracking/persistance issues. Iām happy to swap some virtual flying lessons in return for all the hard effort youāre putting in! 
I confirm there should be some sort of incompatibility with OculusVR: Iām using Ultraleap hand tracking (visualizer working fine), open-xr explorer and open-xr hand to controller info seem ok, but log says:
2022-01-22 14:06:33 +0100: dllHome is āC:\Program Files\OpenXR-Hand-To-Controllerā
2022-01-22 14:06:33 +0100: XR_APILAYER_NOVENDOR_hand_to_controller layer (Beta-1) is active
2022-01-22 14:06:33 +0100: XR_EXT_hand_tracking is not available from the OpenXR runtime or any upsteam API layer.
2022-01-22 14:06:33 +0100: The XR_FORM_FACTOR_HEAD_MOUNTED_DISPLAY system does not support hand tracking.
2022-01-22 14:06:33 +0100: Failed to resolve symbols for XR_EXT_hand_tracking.
Thanks to @mbucchia for his great work!!!
Thatās very strange because this error is only displayed when XR_EXT_hand_tracking is not found in the list, yet the explorer is showing it. Youāre layer order looks correct.
Did you by any chance install the Ultraleap layer elsewhere than in C:\Program files?
No, I confirm that Ultraleap layer is installed in C:\Program Files\Ultraleapā¦
I also tried to uninstall everything and reinstall many times, also changing the installation order of Ultraleap Open XR and Hand to Controller and rebooting after each passage; even tried as last resort to downgrade to an older version of Ultraleap but with no resultā¦ very strange!
Thanks again for your efforts!!!
It would be interesting if someone could report that they managed to get it to work properly with Oculus XR and Ultraleap.
Iāve read the thread so far and, if Iām not mistaken, all successful reports refer to other Open XR implementations (WMR, Steam ā¦).
Hello everyone and thank you for your efforts! Have you noticed any abnormalities due to temperature on the leap motion controller? At robotshop.com there are complaints about very hot devicesā¦
Hi there, the devices do get warm, but not hot enough to hurt anyone or the device itself. If you think you have a problem, please do reach out to support@ultraleap.com
1 Like
I havenāt done any long flights yet with the Leap Motion. But I havenāt noticed it getting too hot. A bit worm maybe. Note that the mouting type can really affect it. If the deviceās aluminium shell is enclosed at all sides and the only side exposed is the camera side, it may very well cook itself, especially if the surroundings are thick-walled and heat has nowhere to go. But even my 3D-printed mount has it enclosed except for two patches for cable notch and the opposite side. It would be easy to modify the mount to include many ventilation holes if needed. I will do that if I encounter thermal issues.
1 Like
I have now ordered the leap motion scanner with the mount and cable. I hope to provide you with my thoughts in future.
Please stay curious 
1 Like