How to get the tracking in Unity 5 as smooth as the visualizer?

[artistguy69]

We are working on a skills game in Unity 5 utilizing the Leap Motion sensor. I have downloaded and am utilizing the various demos that were on the Unity Asset Store. My question is this:

I am noticing much smoother tracking when running the LM Visualizer than what we are getting inside Unity 5? Is there documentation that deals with the filtering of the data in Unity 5?

Here is what we are seeing:
In the visualizer we are getting pretty smooth tracking of the hands. Sure one or both will change colors from time to time, but the tracking is pretty solid. In Unity, when running some of the demo scenes, we are getting a lot of tracking errors, thus the hands will jitter like mad, or even flip left to right. We would then open the Visualizer to see if this is happening there, and alas no... the hands are fine in the Visualizer.

So... what settings should we be playing with to achieve a smoother track like that in the visualizer? I am assuming there is a filter threshold that can be set to remove large spikes in the error tracking, thus smoothing out the motion of the hands. Any assistance would be greatly appreciated.

-Aaron

[Joe_Ward]

Are you comparing the Unity app and the Visualizer side-by-side? The Visualizer uses the exact same data that is supplied to all other apps so any differences should come down to:

1. Computer load -- this is why I ask if you are looking at the Visualizer and the Unity app at the same time -- if the computer is overloaded, both the Unity rendering performance and the Leap software's ability to produce data will decrease. This should be visible in the Visualizer when both apps are running at the same time.

2. USB load -- similar to computer load. If you are using an HMD that also sends data over USB, then that can degrade the Leap Motion performance significantly. Again, this would be visible in the Visualizer, too, when both apps are running.

3. The asset scripts poll for the Leap data rather than getting it as it is produced. Thus the hands are being updated at Unity's frame rate, not the Leap Motion frame rate. While this could lead to jerkiness as the Unity frame rate decreases, it wouldn't cause erroneous data like left hands being recognized as right hands in the app but not the visualizer.

4. The apps are using old Leap Motion libraries. This wouldn't be the case with the example scenes in our latest core asset package, but might be for 3rd-party examples or older examples in our example gallery which haven't been updated. I doubt this is the problem, the service should be backward compatible, but mention it because it is a possible difference between a particular app and the Visualizer.

There are no filtering settings. You would have to customize the hand and finger scripts to add filtering. This would probably add lag, though.

[fed007]

Hi, I have just begun this as well and notice a huge difference in tracking performance between visualizer and Unity. I thought I had a pretty decent dev set up.. but I may need to upgrade. I put both the Oculus and Leap on the USB 3.0 ports. Hoping that would make an improvement.

GTX 470
Intel Dual Quad core 3.28 GHz
32 GB ram
Win 7 Pro

My questions.

• Can we prioritize or CPU pin this application to a set of cores?

• Would a dedicated Linux Micro controller like Beagle Bone , R-PI, Cubie Board be enough CPU to do the dedicated daemon tasks for the leap? (if so I would just write an socket server to issue the frame date)

• After hardware sensor processing... has anyone measured the max data rate via websockets from the sensor?

I suppose just using the existing leap socket dat captured form another computer would be the best route. Micro or Full PC. (preferably Linux).

Neil

[secretanorak]

Hi there, I might have a solution for you.

I found similar Juddering when trying to run on i3 machines. After a bit of investigation, I discovered that my Unity app was using 100% of the CPU, thus leaving very little room for Leap Motion to process hand movements.

This is caused by Unity constantly attempting to achieve maximum possible framerate by default. In order to fix this issue you can use a simple line of code in the start function of a script to limit the Application's FPS to say 60 for example:

Application.targetFrameRate = 60;

This single line of code, made all of my problems go away.

Hope that helps anyone who reads this.

@Joe_Ward this might be worth mentioning in the docs