Uses /me/eyes/left and /me/eyes/right poses in ConstructModelView

[DuFF14]

If left and right eye poses are present (we are getting reports from /me/eyes/left and /me/eyes/right), use them in ConstructModelView instead of head pose +- ipd

[DuFF14]

I tested this with OSVR-Vive plugin and Vive trackers aliased to each eye, using this config file (rename to .json): osvr_server_config.rm.eyes.HDKv2.0.direct.json.txt

[russell-taylor]

@DuFF14 Do you want me to do the merge? I was assuming that you would since you issued the pull request.

[DuFF14]

@russell-taylor thanks, I wasn't waiting for you to merge it. I need some clarification of the expected behavior I was asked to implement. could @rpavlik or @JeroMiya take a look?

In my initial commits, if eye pose data is present, each eye used those poses instead of being a translation in headspace. With the latest changes, the eyes rotate with the head. Is eyespace always in headspace by definition?

[rpavlik]

So the answer is, the eye pose path is assumed to be in room space - often something like

{
  "translate": [-0.33, 0, 0],
  "child": "/me/head"
}

That allows for IPD setting in config.

In some cases that transform might be dynamic so that e.g. an IPD dial works in real-time, but the general idea is that before, we were "faking" the presence of /me/eyes/left by using head and half of a hard-coded IPD, while now, if they give us that, we're happy to accept it.

[DuFF14]

latest change refactors "eyes" to "viewpoints" and looks for poses at /me/viewpoint/left and /me/viewpoint/right. It also reverts to the behavior where the viewpoints are in room space, rather than headspace.

[DuFF14]

@JeroMiya thanks for the review... unfortunately that last refactor messed things up and I'm having some trouble sorting the git history out, so I just opened a new PR with the refactored changes. https://github.com/sensics/OSVR-RenderManager/pull/366