Forum Discussion
Rotation Multiplication
I'm attempting to multiply the DK2's rotation by some factor c, with position tracking off. Essentially, if the headset is turned by x degrees, I want a rotation of cx degrees displayed to the headset. I assumed it would be possible because as far as I can tell, Unity receives orientation and position data in a Posef. Modifying the orientation data every time a change is detected should create a multiplied effect while avoiding the lower-level rotation calculating code.
So far I've only messed around with the Unity integration files (OVRCameraRig, OVRManager, OVRPlugin, etc.) but no matter what I change, the Oculus continues to accurately track rotation. Intercepting and modifying the centerEyeAnchor's orientation to return the same Quaternion (except a y multiplied by 2) changes nothing and throws no errors. Returning a new, null Posef in methods which seem to be responsible for orientation, like OVRPlugin's GetNodePose, changes nothing and doesn't throw errors either. Adding a script which directly manipulates the CenterEyeAnchor works for a few frames, but automatically corrects itself. If anyone is interested, I have more details on what has failed to work.
Is this possible with Unity, if at all? Has anyone else had some experience with this? Any suggestions on how to proceed? Thanks!
So far I've only messed around with the Unity integration files (OVRCameraRig, OVRManager, OVRPlugin, etc.) but no matter what I change, the Oculus continues to accurately track rotation. Intercepting and modifying the centerEyeAnchor's orientation to return the same Quaternion (except a y multiplied by 2) changes nothing and throws no errors. Returning a new, null Posef in methods which seem to be responsible for orientation, like OVRPlugin's GetNodePose, changes nothing and doesn't throw errors either. Adding a script which directly manipulates the CenterEyeAnchor works for a few frames, but automatically corrects itself. If anyone is interested, I have more details on what has failed to work.
Is this possible with Unity, if at all? Has anyone else had some experience with this? Any suggestions on how to proceed? Thanks!
4 Replies
Replies have been turned off for this discussion
- Although I would really discourage messing with the head rotation due to the severe comfort issues it's going to cause, you can do whatever you want by registering a handler for the event OVRCameraRig.UpdatedAnchors.
- I registered a handler and a listener to the UpdatedAnchors event called modRotation and it is being called every frame update. However, modifying centerEyeAnchor, leftEyeAnchor, and rightEyeAnchor still produce no differences.
As an initial test, I set all three of the above's localRotation to the quaternion (0f, 0f, 0f, 0f) in the listener method. Based on the way UpdateAnchors handled orientation, this should display an unchanging environment to the Oculus (no matter which way the real rotation is, OVRCameraRig should face the same direction). However, the headset operates as normal. Even odder, logging the three localRotations after calling the UpdatedAnchors event (but in the UpdateAnchors method) constantly returns an orientation of (0f, 0f, 0f, 0f) despite the headset displaying a rotation. In other words, it seems that the local rotation is being set, but the headset is being displayed to sparate of OVRCameraRig's anchors.
Is there something I'm missing, since Oculus says you can use UpdatedAnchors to modify the headset position/orientation? - You could instead apply the extra rotations to the parent transform.
Btw are you doing all axis - or only yaw?
I did a similar scenario for a Fast turn mode when pressing a button. Worked quite well:
http://talesfromtherift.com/vr-look-turn/ - Thanks! Applying rotations to a parent transform worked—and it seems to be the only thing that works.
Directly modifying the code responsible for both rotation and position tracking in OVRCameraRig or through an attached handler seems to have no effect. As even deleting the majority of the code in the UpdateAnchors method and the attached handler has no effect on the accuracy of the rotation/position tracking, I think the only way to modify their behaviors is to add one or two extra parents.
However, a single parent that rotated didn't work well with position tracking. Because the position tracker moves OVRCameraRig's position relative to the parent (and there's no way to change that), moving and then turning caused the rig to swing in an arc.
What I ended up doing was adding two levels of parents on top of OVRCameraRig, so it looked something like GameObject1 > GameObject2 > OVRCameraRig. GameObject1's position was set to OVRCameraRig's position, and its rotation was set to counter or add to OVRCameraRig's. GameObject2's position was set to the opposite of OVRCameraRig's local position, since the rig's local position was being modified and there was no way to stop it. GameObject2 essentially shifts OVRCameraRig so it's directly above GameObject1.
Now, to modify rotation, I just change GameObject1's rotation multiplier values. When I move, GameObject2 corrects OVRCameraRig's change in localPosition, and turning no longer results in arcing movements.
It's a roundabout method, but I couldn't think of anything better...
