Kikuto Posted May 12, 2019 Share Posted May 12, 2019 Hello You forgot to answer the last question: Can I use HandSDK together with SRWorks in camera seethrough mode? I read the public code in HandSDK but there's no mention to camera input, so this part is in dll function that opens the camera and does steps of hand track algorithm. However, SRWorks are using cameras images, and when I try open camera again with HandSDK, I got a runtime error. So if there a way to pass the image of the frame to GetGestureResult() function avoiding get images from the camera will be possible to use HandSDK + SRWorks. So the point after GetGestureResult() accept the frame as input is what kind of image will be needed, left and right raw frame, after defish algorithm, or just one image. Link to comment Share on other sites More sharing options...
zzy Posted May 13, 2019 Author Share Posted May 13, 2019 Hi Are you using latest SRWorks SDK? There used to be conflicts between SRWorks and Hand tracking SDK, but it should be solved in newer SRWorks SDK. I think you have tried to use both SDK together. Can you give some comments? Best Regards, Zhongyang Link to comment Share on other sites More sharing options...
Kikuto Posted May 13, 2019 Share Posted May 13, 2019 Yes, the latest version 0.8.0.2 for SRWorks and 0.8.0 for Hand Tracking SDK. Great news! Hand tracking in See Through will be a significant improvement :) In the path to use both, I had one problem with OpenCL error in Hand Tracking SDK for my GTX 1060 3gb, openCL just works in driver version 388.71, and I tried to put to work in newer versions, but no success. However, Depth map freezes in 388.71 driver version and just became functional in 390.77 driver version. I searched a lot and tried many things to solve this openCL problem. GPU-Z also checks OpenCL and CUDA. Had someone experienced this kind of issues? Link to comment Share on other sites More sharing options...
zzy Posted May 14, 2019 Author Share Posted May 14, 2019 Hi Have you tried to install newer version of graphics drivers? I think the latest version of NVIDIA driver is 430.64. You can also reference this answer for other possible solutions. Link to comment Share on other sites More sharing options...
ForensicDJS Posted May 14, 2019 Share Posted May 14, 2019 Great Tool! I've tested it in my program and have it working though I am getting a really big hit on CPU usage (both with wireless and wired). I also just tested the sample file and even running that I get 100% CPU usage and degraded quality on the VIVE Pro headset. I am using an Intel Core i7-7700HQ CPU @ 2.8 GHz, 16GB RAM and NVIDIA GeForce GTX1070. Is there any way I can improve performance? If not, I will not be able to integrate into my game. I have tried decreasing the front camera speed, but it always seems to revert to 40Hz, no matter what I do. Link to comment Share on other sites More sharing options...
Kikuto Posted May 15, 2019 Share Posted May 15, 2019 Hi , I'm using 430.64, but as you said was a problem with unity version. Sorry, I didn't read that part in the plugin documentation. So I back to unity 2017.4.27f1 as in SRWorks project and everything works fine. Thanks again for your tip. Link to comment Share on other sites More sharing options...
zzy Posted May 15, 2019 Author Share Posted May 15, 2019 Hi Thanks for the report. We just found the reason for high CPU usage is due to a wrong compiler flag. We are working on it and will release an updated dll next week. Link to comment Share on other sites More sharing options...
MDV Games Posted May 15, 2019 Share Posted May 15, 2019 Hi, What about Vive Hand Tracking plugin for Unreal Engine (for Vive Focus)? Not ready yet? 1 Link to comment Share on other sites More sharing options...
zzy Posted May 15, 2019 Author Share Posted May 15, 2019 Hi We are working on Unreal plugin for Focus. It should be ready in the next version (target is early June). Best Regards, zzy Link to comment Share on other sites More sharing options...
ForensicDJS Posted May 15, 2019 Share Posted May 15, 2019 wrote: Hi Thanks for the report. We just found the reason for high CPU usage is due to a wrong compiler flag. We are working on it and will release an updated dll next week. Awesome, thanks for the quick response; looking forwards to the update (the sooner the better). ;) Link to comment Share on other sites More sharing options...
Recommended Posts