Skip to main content
Up and Coming
December 5, 2014

SetYRotation() and ResetOrientation() are dearly missed

Hello Oculus,

Please bring back SetYRotation(float YRotation) functionality, which used to be part of OVRCameraController prior to 0.4.3. We offer Unity developers a VR toolkit, and we have situations where the neutral yaw = 0 needs to be pointing in a specific direction (other than where the tracking camera is) from the start.

I know that we can get the same result by rotating the parent object, but that is way more confusing for developers who use our VR toolkit and easily leads to bugs.

EDIT: Looks like we need OVRDevice.ResetOrientation() back as well. OVRManager.display.RecenterPose() does not work for us because it also changes resets the position tracking origin, which causes unwanted side-effects
    This topic has been closed for replies.

    17 replies

    Inspiring
    December 5, 2014
    OK, I have filed a feature request for this.
    AMD Ryzen 7 1800X | MSI X370 Titanium | G.Skill 16GB DDR4 3200 | EVGA SuperNOVA 1000 | Corsair Hydro H110i Gigabyte RX Vega 64 x2 | Samsung 960 Evo M.2 500GB | Seagate FireCuda SSHD 2TB | Phanteks ENTHOO EVOLV
    TtakalaAuthor
    Up and Coming
    December 5, 2014
    Thank you!
    Inspiring
    December 6, 2014
    Can you just use cameraRig.transform.rotation = cameraRig.centerEyeAnchor.transform.rotation or cameraRig.transform.rotation = Quaternion.Euler(cameraRig.centerEyeAnchor.transform.rotation.eulerAngles.Scale(new Vector3(1, 0, 1)))?
    TtakalaAuthor
    Up and Coming
    December 9, 2014
    Hi vrdaveb,

    Short answer is no.

    Our VR toolkit is intended for novice VR developers, and we want them to have full control of the cameraRig transform. If our scripts and their scripts both modify that transform simultaneously, the developers will just get confused.

    SetYRotation() and ResetOrientation() worked great for us because they let us do things "under the hood", without messing with the scenegraph that is to be controlled by developers using our toolkit.

    If SetYRotation() and ResetOrientation() are against your current OVR API design philosophy, an alternative solution could be adding a tracker pose offset (rotation and translation offset) variable, which would affect eye camera transforms, OVRTracker.GetPose(), OVRDisplay.GetHeadPose(), OVRDisplay.GetEyePose(), and related properties.
    Inspiring
    December 11, 2014
    OVRCameraRig's transform represents the initial center eye pose, meaning that's where the camera would be without any tracking information. If you want to change that frame of reference, you need to move the GameObject yourself. However, we can probably make the RecenterPose() function more granular. Would it work for you if we added arguments such as RecenterPose(resetOrientation=true, resetPosition=true)?

    Taking that a couple steps further, we could provide a scale factor for each axis of the position and rotation where you call RecenterPose(Vector3.one, Vector3.one) to make it a full reset of position and orientation for all 3 axes, or set a different value for one of the axes to control the weight of the reset for that axis, where 0 retains the original value. Thoughts?
    New Participant
    December 12, 2014
    This is exactly what i need to modify the Unity .dll for :)

    In our case, we need to set the Orientation directly. I don't want the Oculus to reset it's frame of reference, i want to tell the Oculus what the new frame of reference is.

    Best,
    Marvin
    New Participant
    December 12, 2014
    Specifically, i would like access to the CenteredFromWorld variable in Tracking_SensorStateReader.cpp. Just need modify the setter to be part of the api on your end.

    BTW, if you open up the Unity .dll code, i wouldn't need to bug you :)

    Best,
    Marvin
    TtakalaAuthor
    Up and Coming
    December 13, 2014
    Thanks for the reply vrdaweb,

    Yes, it would help us to have a granular RecenterPose(resetOrientation=true, resetPosition=true).

    I can imagine that some people would want to use a scaling factor for position and rotation. But for us the most important thing is to be able to set the "forward direction" (HMD yaw = 0) to an arbitrary direction with something like SetYRotation().

    Is there some documentation about the camera tracker coordinate system? I.e., the how are the values returned by OVRManager.display.GetEyePose(OVREye eye) related to the camera's optical axis? Is the coordinate system's Y-axis corrected so that it's aligned with gravity, or is the coordinate system's Z-axis always perfectly parallel with the camera's optical axis?

    It would nice if there was a RecenterPose(Vector3 positionOffset, Quaternion rotationOffset) where RecenterPose(Vector3.zero, Quaternion.Euler(new Vector3(0, yawOffset, 0)) would make GetEyePose() and other pose functions return values in a coordinate system where the origin is in the camera center and the orientation was offset by yawOffset.
    New Participant
    December 15, 2014
    +1

    I have a similar situation in which I'm combining the Oculus with an OptiTrack system. I'm using the OptiTrack for positioning and the Oculus' built-in stuff for orientation, but I need to be able to initialize the Oculus' orientation with the OptiTrack system in order to align the Oculus with the OptiTrack world...

    Would be very handy to be able to go SetYRotation(OptiTrack rigidbody y-rotation) for the first couple of frames.

    Any ideas / workarounds for now? Only other thing I can think of is doing the inverse - i.e. transforming the OptiTrack data based on where the Oculus camera is pointing at first, but that gets very messy...
    Inspiring
    January 4, 2015
    For an upcoming release, we're thinking of adding a GameObject representing the tracking coordinate system. It's a child of the OVRCameraRig and the parent of the eye anchors. When calling RecenterPose(), you could also apply any rotation or translation you want to the tracker space. We may also add a PoseChanged event that lets you filter or stomp the poses from tracking, such as for third-party trackers. Would those two changes be enough?