Skip to main content
Anonymous
November 15, 2016

Multiplayer with OVRPlayerController prefab and center eye issue

Hi!
I'm trying to make a multiplayer application using Unity 5.4.1p1 with Oculus 1.10.0.308075. Using Unet for network management and use OVRPlayerController prefab as spawn info > player prefab. Problem is, when i create a session and load first scene by clicking a button at lobby scene, center eye anchor transforms x rotation doubles somehow. If i click create session button on a panel (center eye rotation ~= x: 24 y:0 z:0), at the loaded level center eye x rotation becomes ~49. Meanwhile left and right eye cameras x rotations are ok (~24).

What can be the reason? What can be the solution?
This topic has been closed for replies.

18 replies

vrdaveb
Inspiring
November 15, 2016
There is a known bug in Unity where it latches the current tracking pose in the tracking reference frame for Cameras that are enabled after the Awake method. You can counteract this by setting the pose of OVRCameraRig.trackingSpace. Alternatively, you could pre-create a pool of OVRPlayerController instances in Awake and later assign them instead of spawning them. Does either of those approaches work for your use case?
Anonymous
November 16, 2016
I think settings pose for OVRCameraRig.trackingSpace with UNITY_EDITOR directive should do the trick in my case.

Thanks!
Anonymous
November 18, 2016
Setting the rotation of OVRCameraRig.trackingSpace solves visual problem, however OVRCameraRig and CenterEyeAnchor differs and this causes a lapse in movement direction.
vrdaveb
Inspiring
November 18, 2016
Does it help to change OVRPlayerController.HmdRotatesY?
Anonymous
November 18, 2016
It will but hmd have to rotate Y because it is a fps type application.
Update: This option only enables / disables rotation of character with hmd. Doesn't affect the distorted synch between OVRCameraRig and modified trackingSpace.
vrdaveb
Inspiring
November 18, 2016
When HmdRotatesY is enabled, the OVRPlayerController rotates to match the CenterEyeCamera's world rotation. To get a different behavior, you would have to modify OVRPlayerController.cs.
treefortress
Inspiring
November 19, 2016
I'm a bit confused with why you guys are pinning this on Unity, when the behavior has existed for 2months+ now, and does not occur in either SteamVR or PSVR w/ Unity. 

The amount of man-hrs being wasted by this bug must be in the several hundreds by now, if not thousands... come on, fix it. I reported it to these forums back in early September.
Anonymous
November 21, 2016
Found the solution just now. Just added an empty game object as the parent of CenterEyeAnchor. Only this solves the problem. I don't have to change its rotation or anything. Gaze pointer is at right place. Movement direction is ok.. Funny!! :smiley:

vrdaveb
Inspiring
November 22, 2016
@treefortress, are you saying the bug doesn't occur with Unity 5.4's built-in support for OpenVR or PSVR? It does appear to be in the vendor-agnostic part of Unity's built-in VR support. The problem is that if a new Camera comes online in Start, a frame of tracking data gets applied to its pose before it can latch that pose as its local reference frame for subsequent tracking frames. We are working with Unity to defer the application of tracking data until after the Camera's initial pose has been latched.
vrdaveb
Inspiring
November 22, 2016
I took a quick look at this and the problem is that Unity isn't marking the Camera's pose as immutable as soon as it's enabled. If a script (such as OVRCameraRig) tries to set a VR Camera's pose in the first frame after it's been enabled, the setting prevails and gets latched as the Camera's new reference frame. The intended behavior is for the Camera to immediately latch its pose and make it immutable to scripts when it's enabled with VR support. For now, you can work around this by modifying OVRCameraRig.cs. If OVRCameraRig.usePerEyeCameras is true, comment out the lines in the following that refer to centerEyeAnchor. Else comment out the lines that refer to left/rightEyeAnchor. We'll ship a slightly more robust code change in an upcoming copy of the Utilities and work with Unity to get the root issue fixed.

		trackerAnchor.localRotation = tracker.orientation;
		centerEyeAnchor.localRotation = VR.InputTracking.GetLocalRotation(VR.VRNode.CenterEye);
        leftEyeAnchor.localRotation = monoscopic ? centerEyeAnchor.localRotation : VR.InputTracking.GetLocalRotation(VR.VRNode.LeftEye);
		rightEyeAnchor.localRotation = monoscopic ? centerEyeAnchor.localRotation : VR.InputTracking.GetLocalRotation(VR.VRNode.RightEye);
		leftHandAnchor.localRotation = OVRInput.GetLocalControllerRotation(OVRInput.Controller.LTouch);
        rightHandAnchor.localRotation = OVRInput.GetLocalControllerRotation(OVRInput.Controller.RTouch);

		trackerAnchor.localPosition = tracker.position;
		centerEyeAnchor.localPosition = VR.InputTracking.GetLocalPosition(VR.VRNode.CenterEye);
		leftEyeAnchor.localPosition = monoscopic ? centerEyeAnchor.localPosition : VR.InputTracking.GetLocalPosition(VR.VRNode.LeftEye);
		rightEyeAnchor.localPosition = monoscopic ? centerEyeAnchor.localPosition : VR.InputTracking.GetLocalPosition(VR.VRNode.RightEye);
        leftHandAnchor.localPosition = OVRInput.GetLocalControllerPosition(OVRInput.Controller.LTouch);
        rightHandAnchor.localPosition = OVRInput.GetLocalControllerPosition(OVRInput.Controller.RTouch);
Show more replies
Terms & ConditionsAccessibility statement