Error when running UWP about openxrhandtracking HOT 11 CLOSED

So we've proved that this works with some underlying changes to the Leap Motion Service (which was thankfully much fewer changes than expected). Once we release a new version, it will resolve this issue. If we release beta-2 ahead of that, we'll look to include a check, which will disable/report hand-tracking unsupported in this scenario.

from openxrhandtracking.

Thanks for the report, this looks like the API layer is visible to the runtime and application in UWP, but that it's failing internally. We'll take a look into this further.

from openxrhandtracking.

If you set the environment variable DISABLE_XR_APILAYER_ULTRALEAP_HAND_TRACKING_1 to anything before calling any OpenXR functions, that will effectively blocklist the API layer and can be done with the current release. For a future version, I can look at detecting UWP and disabling the layer until we can resolve the issues.

from openxrhandtracking.

This should now be resolve in Beta 2 in conjunction with the Ultraleap 4.1 Tracking SDK. Please re-open if you are still experiencing issues.

from openxrhandtracking.

@maluoi, Can I get you to enable UH_EXT_debug_utils and record the log message that's thrown at that point of returning XR_FEATURE_ERROR_UNSUPPORTED, I suspect that it might be:

"Attempted to create an XrHandTrackerEXT when the system does not currently support hand-tracking"

If so I think I may have identified the issue or at least one that might be masking the root cause.

from openxrhandtracking.

The debug logs don't give me a ton of new information, but it does show the message you were expecting!

Immediately before showing the XR_FEATURE_ERROR_UNSUPPORTED error for hand tracking, I get:

Entering loader terminator
Attempted to create a XrHandTrackerEXT when the system does not currently support hand-tra...
Completed loader terminator

from openxrhandtracking.

Thanks for the feedback, we've resolved the issue that was causing that message in the current build, but it's uncovering another issue when I attempt to run StereoKitTest_UWP.exe, The console log looks like everything has initialised correctly, but the HMD is not correctly showing the scene, and instead is showing the WMR white "waiting" orbs. We'll need to dig into it further as it only appears to be affecting UWP mode apps, and only when our API layer is enabled.

from openxrhandtracking.

When running without the debugger attached, I can get the UWP project to run just fine. With debug attached I also get loading orbs for a long time, but it eventually loads with significant stutter! When checking debug information, it looks like it's making progress, just really slowly. Each time I pause, the code is further along and the RAM usage creeps up appropriately. I don't think I ever saw this before the leap layer?

I would guess that the error spam is slowing down execution significantly, but this is still without your fix!

from openxrhandtracking.

Yes, that's exactly what's occurring (error spam), It appears that when operating in a UWP application it's unable to connect to the system Leap Motion Service, probably due to the UWP sandbox. I've attempted to grant the "Private Networks (Client & Server)" capabilities to the app as a test but it thus far hasn't appeared to resolve it.

The XR_FEATURE_ERROR_UNSUPPORTED you were seeing, while technically incorrect, is related to the fact that it can't connect to the Leap Motion service. You might be able to work out the App permissions/capabilities on StereoKitTest_UWP.exe to make it work. There are a few other routes we are also going to look at.

from openxrhandtracking.

This is currently due to the fact that LeapC (and the underlying LeapIPC library) uses named pipes to communicate with the Leap Motion service, and these can't be used from a UWP app (and the OpenXR API layer operates as part of the UWP app in this instance). This is something that needs to be resolved in the underlying LeapC/Leap Service.

from openxrhandtracking.

Yowch! Ok, sounds like a lot of work :(

In the meantime, do you know of a good way to disable it through OpenXR? Off the top of my head, I could probably add an exception to disable hand tracking all up on UWP x64 builds, but that's not an ideal solution. Perhaps on your end, you can prevent the layer from loading within a UWP app until it's fixed?

from openxrhandtracking.