Jump to content


Verified Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About ericvids

  • Rank
  1. Thanks for this! I tried this just now, however I noticed that once I got the NVIDIA OpenCL driver working correctly, the "Detection initialization completed" message never shows because GetGestureResult returns a nonzero index immediately. (Unlike with the Intel driver.) Maybe the line should be something like this instead? (to also allow transitioning from the initial lastIndex value of -1) if (index > 0 && lastIndex <= 0) Debug.Log("Detection initialization completed");
  2. Hi @zzy, you're right... I just discovered that when I let my headset sit for 5 minutes and pick it up again, the hand gestures would just start working. It's really weird that I didn't experience this long a delay before when using the older version (or maybe I did, but it somehow got cached so subsequent startups just work... in which case, I don't know why it's not caching now). I also noticed from my own log above that "Intel(R) OpenCL Intel(R) HD Graphics 630" was being used for OpenCL. I'm guessing this is not normal, and that it should be using the NVIDIA driver instead? Is it possible to include additional logging in the Unity editor to indicate the GestureProvider state switching from Starting to Running (not just on error)? This way developers can diagnose where the problem is whenever the startup time is unusually long, e.g., in my case, to alert me of the fact that my OpenCL is not working correctly.
  3. I have recently upgraded to Unity 2019.4.16f1 and Vive Hand Tracking SDK 0.9.4. I noticed that the hand tracking has stopped initializing properly, even on the prepackaged demo scenes. From a blank Unity project, I did a fresh import of the hand tracking SDK, and turned on VR support and the OpenVR SDK in Player Settings, then I ran the UISample scene from the SDK's samples. Unfortunately, no hands get shown, and the editor log does not show any problems. I have verified that I am getting camera input by using a Vive controller to go to the Steam settings menu and verifying the camera feed. Now here's the quirky part: Occasionally, when I press Home on the Vive controller, the hand suddenly gets initialized and the rest of the scene actually runs okay. This has happened VERY few times however, and I have been unable to track a log file of when this happened. I have also noticed that whenever the plugin is not initializing, OpenVR shutdown is taking longer than expected. I suspect that it is waiting for unfinished calls to the Hand Tracking DLL. I tried this with both SteamVR regular version 1.15.12 and SteamVR beta 1.15.13.
  4. Thank you for your help @zzy -- the whole process you outlined is flawless! I was previously not using the SteamVR plugin (instead relying on Unity's built-in OpenVR support, which was rather limited), so I was trying to get Unity's own WebCamTexture to work for providing the camera feed. As it turns out, WebCamTexture had a bunch of problems (most important of which is that it exclusively locks the camera). Thanks for pointing me towards the SteamVR TrackedCamera API! @ericvids
  5. The Hand Tracking SDK requires the headset's back-facing camera to be enabled in SteamVR settings. However, this stops Unity from being able to access the same device camera as a WebCamTexture when I import the Unity plugin into my project. Is there a workaround to get camera frames as textures, either through the plugin itself (since obviously the plugin initialized it) or some other means, perhaps my own Unity plugin? (I'm ok with having to write C++ code, I just don't know what camera API to use to be compatible with the Hand Tracking SDK.) Purpose: I want to simulate an Augmented Reality setup with hand tracking, mimicking a (very crude) HoloLens. I'm using the original HTC Vive.
  • Create New...