Proposal to Expose several convergence distances #101
Conversation
- Expose two different interpretations of convergence distance. This is more relevant for objects reaching into the intimate space. In both cases, the convergence distance is not factored by looking up, straight, or down. - Distance to the convergence plane (triangle height) This convergence distance corresponds to the distance between the convergence point and an infinite line passing through the two gaze origins. - Distance to the convergence point (length of median line segment) This convergence distance corresponds to the distance between the convergence point and the point between the two gaze origin. - For both interpretations, the distance is exposed as float values from 0 to 1 where the maximum distance saturates at 20 metres, 10 metres, 5 metres, 2 metres, and 1 metre. A float value of 1 would be the maximum distance or above. - For both interpretations, bool parameters indicate if the distance is under 20 metres, 10 metres, 5 metres, 2 metres, 1 metre, 50 cm, 20 cm, and 10 cm. - When the user's eyes happen to be parallel or diverging, then an infinite distance is assumed, causing all floats to saturate at 1. - Eye tracking data is ignored when at least one of the eyes reports as invalid (i.e. when it is closed). In this case, the distance is not updated.
|
Is the IPD exposed via SteamVR or Sranipal? The Vive Pro Eye is aware of it and reports it when you adjust the knob on the headset. Is it possible that as the calculated convergence distance approaches the margin of error of the eyes' rotational position, the code applies more and more smoothing? The perceived effect on the eyes between a convergence distance of 2 meters and 3 meters won't be as great as between 1 and 0 |
|
As far as compacting the parameter in it's current iteration, the distance indicator (under 20, 10, etc...), you could compact that into a 3 bit binary parameter (which would have 8 'steps' which should cover all the bases) and it could cover all your distance thresholds, then have the base float that returns the value be adjusted accordingly in-code to saturate the distance to the returned value and be handled appropriately in the animator. As far as needing a distance threshold indicator I'm just assuming it's to work around float precision? Or is there another reason? Overall very neatly proposed! Just a bit iffy on having to eat through more parameter space 😥. |
Looks like the IPD is pulled from the differential of each individual eye gaze origins from SRanipal. Also the smoothing idea is pretty neat! Would definitely be a good approach for a single-parameter implementation if some really want to crunch parameters, it could also help to skew the precision to fill out the closer values and lower precision on the outward values but then introduce smoothness to it as a counter-measure. |
|
The IPD is indeed derived from SRAnipal. According to the diagram, the gaze rotation angles are based on the gaze centers, which move during operation of a single person as their eyes look left/right or converge. This dynamic IPD is not constant per-person unlike lenses IPD per-person. For the smoothing, I'm very interested in looking into it. I think the convergence distance needs to remain as snappy as the eyes tracking normally is. The booleans are entirely debatable, I'm not sure about them myself. They could potentially be replaced by bit versions of the floats, leaving the handling to the animator creator. Here's their original intent: The distances booleans under 1m, 50cm, 20cm, 10cm, etc. are booleans that I put there following my negative experience with the inaccuracies over 1.0m. My intent behind these booleans was that, the accuracy loss is so significant over 1.0m that it's hard to come up with any gimmick over that 1.0 threshold. By extension we could avoid consuming 8 bits by just making use of boolean thresholds when creating gimmicks. This is highly subjective: I believe that convergence happens to be good for avatar gimmicks in two cases:
The booleans are effectively here to trigger transition conditions at the selected range. i.e. breaching 20cm, 50cm, 1m can trigger a change in a gimmick. It's meant to facilitate these creations as you'd only choose to sync a couple of them as a gimmick creator. |
This is a draft proposal to Expose several convergence distances.
I'd like to submit this PR as a draft first for discussion as this adds a significant amount of parameters, some of which are highly subjective.
conv-github.mp4
Apparently the SDK has structures for the convergence point but it doesn't appear to be functional.
In this proposal, the convergence distance is derived from:
Using this data, two interpretations of convergence distance are produced.
In order to use them in animators, several float parameters are exposed for various distances, and several bool parameters for distance thresholds.
However, during experimentation of this feature, the calculated distance greatly loses in accuracy and become erratic for convergence distances greater than around 1.0 meter, on my current hardware and software.
Such accuracy loss is expected as tiny change in angles result in greater changes in distances as it becomes larger.
However this might mean that the exposed parameters over 2 meters may be impractical.
In addition there is a possibility that an implementation error on my part could result in a inaccurate distance calculation or one with an avoidable loss of precision.
You will find a description of the commit contents below.
In both cases, the convergence distance is not factored by looking up, straight, or down.
This convergence distance corresponds to the distance between the convergence point and an infinite line passing through the two gaze origins.
This convergence distance corresponds to the distance between the convergence point and the point between the two gaze origin.
A float value of 1 would be the maximum distance or above.
In this case, the distance is not updated.