Ouch. Apparently not. I loaded a flight, but as soon as I pressed Ctrl-Tab to switch into VR, my monitors went black and after a few seconds PC rebooted itself. This has never happened before. I did instal the public beta of SU7 hotfix, it could be related to that too…
Here’s another thing to try as well: uninstall hand_to_controller as well. There should just be ultraleap left. Then, if I recall the Demo Scene in the Developer Tools should be able to use hand tracking as-is. This will confirm that the Ultraleap layer works.
Then we can start re-adding components and figure out where things go wrong.
I uninstalled your script after reboot and launched MSFS and it happened again - launched the flight and even before the VR, right after launching the flight - black screen and reboot. So if the uninstall script worked, it’s not your layer that’s the problem. Beside the beta, I also did update NVIDIA driver, so maybe that’s the problem. I will roll back to previous driver and try again. Later tonight if I can, or maybe tomorrow… I will also check the Demo Scene, although there is a yellow circle with exclamation mark next to that button, I wonder why…
OK, without updating the driver, I just opened Demo Scene and I got no hands. When Demo scene is open, I get the same error in Developer. When I close it, I can see the normal page, and the only thing in API Layers is
XR_APILAYER_ULTRALEAP_hand_tracking
I have latest Gemini software installed for the UltraLeap., and it’s working in SteamVR. I did uninstall that OpenVR layer just in case.
The ERROR_LIMIT_REACHED is expected to show up when the Demo Scene is opened… That’s why I was saying it’s finicky 
I just tested the demo scene and you are right it does not support hands. I am mixing up with another sample application from our OpenXR repository - too many apps in my head right now.
So this won’t help with confirming that the Ultraleap OpenXR layer works.
I suspect your hard-reboot issue is the GPU driver update.
OK so I found the issue, it’s actually a known issue with the hand_to_controller layer not playing well with any other layer than Ultraleap. I literally already have a TODO in the code for this since last week.
However, by reversing the thing I told you earlier, ie setting up NIS to be first (final order listed below), I could get both hands and NIS to work with one of my tests apps (not tried MSFS yet).
nis_scaler
hand_to_controller
Ultraleap
I’ll have to think about which order is right or wrong, but that order I confirmed to work.
Thanks, I’ll try that. Is it how your list appears? I have XR_APILAYER_ULTRALEAP_hand_tracking and I don’t have Ultraleap. Do I have the correct runtime installed? Also their readme doesn’t say how to I change that runtime options and environment variable at all. I can’t se any config files… Is there anything I should change there?
Yeah sorry I’m being a little lazy on typing the full names from my phone. This is the order you wanna get to:
XR_APILAYER_NOVENDOR_nis_scaler
XR_APILAYER_NOVENDOR_hand_to_controller
XR_APILAYER_ULTRALEAP_hand_tracking
Your runtime version is good.
There are no environment variables for my layers, just make sure you merge the FS2020.cfg files from both layers.
OK, I downgraded the drivers and no blackscreens not. I got the two API layers above just like that (no NIS for now, until I troubleshoot the hands). But there are no hands in MSFS. Ultraleap shows green but no hands are showing up…
I also did downgrade UltraLeap for v4 of the software, like the other API said - I used v5 before. I will try v5 again…
What do you mean shows green? In the Leap Control panel?
I’ve had issues before where it was green in the Control panel but still did not work. I had to unplug replug USB for the Leap.
You can use their visualizer to double check that it works before running MSFS.
If none of this work, please post the XR_APILAYER_NOVENDOR_hand_to_controlller.log file (see my Readme for where to find it).
Visualizer works fine. Here’s the log:
dllHome is “C:\Program Files\OpenXR-API-Layers”
XR_APILAYER_NOVENDOR_hand_to_controller layer is active
The XR_FORM_FACTOR_HEAD_MOUNTED_DISPLAY system does not support hand tracking.
Failed to resolve symbols for XR_EXT_hand_tracking.
XR_APILAYER_NOVENDOR_hand_to_controller layer is active
The XR_FORM_FACTOR_HEAD_MOUNTED_DISPLAY system does not support hand tracking.
Failed to resolve symbols for XR_EXT_hand_tracking.
XR_APILAYER_NOVENDOR_hand_to_controller layer is active
The XR_FORM_FACTOR_HEAD_MOUNTED_DISPLAY system does not support hand tracking.
Failed to resolve symbols for XR_EXT_hand_tracking.
Thanks! Very very strange error message, I know what it means but I cannot explain why you are seeing it. Best guess is that the Ultraleap OpenXR layer is not properly connecting to the Leap software, and so it’s telling my layer that hand tracking is not supported.
Best next move would be for you to try an OpenXR app that supports XR_EXT_hand_tracking directly, something like StereoKit. But I think it’s not distributed as binaries (it’s a developers framework), so I’d have to give you a build I make myself. This will have to be later tonight.
There’s also a bunch of logs created by Ultraleap. The Ultraleap OpenXR layer claims to write a log file but I could never get that to work. Maybe someplace else inside the Ultraleap program folder there is a log that would tell us what’s happening.
Big thanks for your support! It’s working now! Yippeee!!! I rebooted and that’s it. Maybe after uninstalling Leap v4 and installing back leap v5 reboot was needed.
First implression: WOW!!! I can see my hands and I can control things. I will need to do a lot of tweaking, and some getting used to - it was difficult to get controller presses for rotating to register. Does your API layer still have problem opening a cgf file, or can it read saved offsets now? Does it load the offsets the first time, or never at all yet?
My wife will divorce me if I don’t get out of VR now, so will continue later, and add NIS. But I can tell already this is going to be amazing!
1 Like
[quote="RomanDesign, post:72, topic:475308]
Big thanks for your support! It’s working now! Yippeee!!! I rebooted and that’s it. Maybe after uninstalling Leap v4 and installing back leap v5 reboot was needed.
[/quote]
Awesome!! Thank you for helping me work out the issues. Having a proper installer is for sure a must especially now that we combine multiple layers!
[quote="RomanDesign, post:72, topic:475308]
First implression: WOW!!! I can see my hands and I can control things. I will need to do a lot of tweaking, and some getting used to - it was difficult to get controller presses for rotating to register. Does your API layer still have problem opening a cgf file, or can it read saved offsets now? Does it load the offsets the first time, or never at all yet?
[/quote]
Yes I expect that with different hand physiology it needs tweaking. Right now the sensitivity settings are purely based on my hands.
Here is the flow for configuration:
- The API layer loads FS2020.cfg when you (re)enter VR
- You can start ConfigUI.exe and it will keep a connection with the API layer while the application is running
- You can tweak the settings in real time (no need to restart VR, except for a handful of minor options which are listed as “must restart”).
- Note that if you restart VR of any reason, you must do “Push all settings” to reapply all the changes (otherwise the settings were reloaded in the layer per step 1)
- You can save your settings to a cfg file so they will become permanent. Beware that the folder you copied the FS2020.cfg file to (program files) is typically not writable, so you likely need to save to a temporary location then copy to program files.
The thing that does not work is ConfigUI cannot load a cfg file… so when you start it, it will default to settings different from FS2020.cfg. You’ll have to move all the sliders etc to “recreate” the cfg file in the UI before you can make changes. You can find the current settings in my screenshots from a few days ago. Make sure to also write down all the settings on paper before you exit ConfigUI.
Most settings are human readable in the cfg file, except for the hand rotation quaternion.
Good luck!
OK, here’s a quick feedback from a very imited testing (20 minutes) I did after solving all the installation and driver problems:
- WOW!!!
- The hand tracking is very precise and fluid. I didn’t see any issues at all with positioning or motion. The hand rotation can be a bit iffy sometimes, as it seems to be in a slightly offset plane from the real hand. But not enough to be a problem. Pinching a knob and rotating your hand works well.
- It works fine with the public SU7 hotfix beta.
- The rotating controls are very precise! The beta fixed the rough jump problem, and I could dial the barometer, for example, in very fine detail without any problems at all.
- The original MSFS white controller arrow indicator is very important. That is your aim for pressing buttons and grabbing small rotational knobs. Most confusing moments arise from managing the relation of that arrow with your hand.
- You have to be very definite about your gestures, as triggering things can be a challenge sometimes. But after a while I figured out why: if you approach a switch with your finger already slightly bent - it can be interpreted as trigger already pressed and then you pinch, but nothing would happen. You need to let it go before triggering again. So It needs to be planned by each user, what works for him - which gestures (pinch, thumb press or trigger press) work best, and a lot depends on min and max values for triggering gestures set in config. It becomes messy when they are triggered too lightly or not let go fast enough after triggering. Once I realised that this was the problem and paid attention to approach without bent finger or thumb - I trigered and rotated everything as intended every time.
- Because the white arrow is important, some people may prefer to disable visual hand model entirely, because it would be cleaner. So transparentcy should be an option there, up to 100% transparent. On the other hand (pun intended), actually more substantial mesh that totally obscures default controller mesh may be preferrable to some people.
1 Like
Great feedback! Looking forward to working with you on tweaking the gestures to get it even more straightforward and comfortable!
I’ll ask more questions after you get to use it longer. There’s aspects where I don’t want to possibly influence your feedback too early 
Few more I forgot:
-
Grabbing (not pinching) throttles and other levers works very well! But in all their infinite wisdom, Asobo made it impossible to move 2 throttles at once by grabbing the center, its only on at a time, which doesn’t make any sense at all, so hardware throttles are still essential for multi-engine aircraft. But with single-engine it feels very natural and easy.
-
It would really help a lot if settings app could save AND load the the config file, as there are many parameters. It would be easy to run it as admin, if it helps the write permissions. Replicating the confg every time will be very tedious.
-
Adjusting offsets feels very weird. AT least two of the axes are somehow diagonal, instead how I would imaging XYZ angles would go. The ghost controllers move in strange directions. It can still be dialed up eventually, but for example Y is not really vertical, it moves top-and-forward and down-and-backward, and so on. I don’t think you can do anything about that, and it’s not a big deal, as it can be tweaked once and left alone.
Thanks a lot, just downloaded and checked - looks good!
I also found the developer mount on Thingverse, seems that I only need the “holder” part, not the “track” part, correct?
That’s correct if you already have the Leap motion holder that the sensor fits into. If not you can get the Leap model and print that as well.
Mbucchia and RomanDesign you are doing a fabulous job with the leap development. All the effort you are putting in is really appreciated.
1 Like
Yes, my part is what that part fits into. You may want to the developer mount remix that’s “easier to print”. I printed the original part, but it has large overhangs. It still printed out all right, but the remix may be easier.
Do you have a link for that one?