5.4.0 b9 Get VR eye position and rotation?

Unity Engine
1

Using native OpenVR, is there any way to get what the eye position and rotation would be for each eye?

I’m trying to achieve a portal effect. In 5.3, the SteamVR plugin would set the position of the camera before rendering each eye. So I was able to do something similar to get a portal effect: I would match up my portal camera’s projection matrix with the VR eye camera, and then before rendering it to a RenderTexture, I would set its localPosition and localRotation to the VR eye camera’s position and rotation. So the RenderTexture was being rendered twice each frame: once for each eye.

With the native OpenVR implementation, I’m not sure how to achieve the same effect. I’m thinking I could set up 2 cameras for the portal: 1 for each eye, then render those into a couple of RenderTextures. Then I would need to have an extra VR eye camera that only renders the RenderTexture from the right-eye portal camera.

The trouble is I haven’t been able to work out how to properly get the eye position and rotation for each eye. At least not in a way that doesn’t make my eyes hurt.

Or maybe there’s a better solution now for creating a portal effect?

2

What about UnityEngine.VR.InputTracking.GetLocalPosition( VRNode.LeftEye ) ?
Does that work for Vive?

3

Thanks! That does indeed return a value, and it positions the eyes correctly relative to each other, but it doesn’t appear to be local to the head. Since the docs don’t say, I decided not to spend time figuring it out. I ended up being able to use SteamVR.instance.eyes.pos instead, which is local to the head.

Finding that was a big help, and then the other thing that made the most difference was realizing that I needed to set the projection matrix for each eye separately:

_cameraForPortal.projectionMatrix = HMDMatrix4x4ToMatrix4x4(SteamVR.instance.hmd.GetProjectionMatrix(eye, _vrEye.nearClipPlane, _vrEye.farClipPlane, Valve.VR.EGraphicsAPIConvention.API_DirectX));

After that, all’s well with my portals. Except that I’m not sure if I’m really getting the full benefit of native OpenVR performance, since I’m splitting up rendering between eyes. Will probably make a separate post about that…