Pro eye unsuitable for research - data SUPER heavily filtered during fixation.

[performlabrit]

To see this for yourself, fixate a point while rotating your head back and forth, (as if indicating "no" in American culture). This is a standard test of the relative latency between the head tracker and eye tracker.  If latency were low, you would see very little wiggle in the fixation point, as your eye/head rotations cancel one another out.  Unfortunately, the Vive pro eye demonstrates TONS of wiggle.  Worse yet, it also does this in a strange way that seems uncorrelated with the rotation of your head.  Normally, this would suggest very high eye tracker latency.  However, the tracker seems to perform well during pursuit or saccade, and so my guess is that this is evidence of some VERY agressive dynamic filters that are corrupting the data signal during fixation to reduce jitter or slippage.  Can someone at Vive comment on this?  Can the filters be turned off?  

 

Note that a similar discussion was held here, on Reddit:

https://www.reddit.com/r/vive_vr/comments/brxbb5/very_high_htc_vive_eye_latency_well_above_100_ms/

 

The more data transparency the better.  Researchers would love to use your equipment, but cannot do so if you obscure the raw signal with dynamic filters.  We can deal with jitter / slippage.

 

[Daniel_Y]

You can use SetEyeParameter() as defined in SRanipal_Eye.h to tune the filter strength.

[performlabrit]

Great news.  Thanks for the input,  !  I'll let you know how that goes.  I won't be able to test this for a few weeks, but welcome feedback from anyone else.

 

- gD

[performlabrit]

@Daniel_Y, SetEyeParameter() is not documented and is poorly described in the code.  Can you please provide any additional information?  What about the focus and accuracy parameters?  Thanks.  

Edited August 1, 2019 by performlabrit

[Daniel_Y]

Double confirmed. It is documented in SDK document. keyword searching for SetEyeParameter though the description is as same in code.

Refer to VIVE PRO EYE SPECS for accuracy in https://www.vive.com/eu/product/vive-pro-eye/.

Edited August 2, 2019 by Daniel_Y

[gazeBehavior]

Ok, I've created two movies that show 1) I have sucessfully changed the sensitivity, and 2)  this does not resolve the original problem described by PerformLabRIT in the first post of this thread. I've attached the videos and shared via youtube.

That's a 1 meter wide board, and at a distance of 3 meters half the angular subtense is atan(0.5/3)*(180/pi) = 9.5 degrees (the radius of the target).  So, the full angular subtense is 19 degrees.

Notice that the gaze sphere oscillates almost the full radius of the target - 9.5 degrees during the head movement.  Also notice that the change in sensitivity does not affect this.

This makes me think that something is *seriously* wrong with the Tobii/HTC tracking algorithm.

 

 

 

eyeParam1.flveyeParam015.flv

Edited August 2, 2019 by gazeBehavior

[gazeBehavior]

To be clear, I am fixating the center of the dart board in both videos.  Slippage is primarily from the tracker, and does not reflect true gaze behavior.

[Daniel_Y]

From your video, the major factor contributes the oscillation would be the latency between head movement and eye tracker, The other one may be  gaze beyond FOV  20° .

[gazeBehavior]

I agree that it is likely latency - a lot of it..  It's a bit of a guess, but I have enough experience in this area to estimate +100 ms of latency.  This is surprising given that you guys market this for foveated rendering.  This is farrrrr too slow for foveated rendering.

Are there any other filters to worry about or turn off?

Edited August 2, 2019 by gazeBehavior

[gazeBehavior]

"desti hosting" seems to be a spam account of some sort. To recap:  using SetEyeParameter() to change the sensitivity does not address the issue, which seems to be high eye tracker latency.  As @performlabrit pointed out, this issue was previously raised in the attached reddit forum post.  The videos I posted above demonstrate what the post was referencing. 

Can anyone at HTC suggest ways to lower the latency?  It's clearly too high to do anything related to foveated rendering.