[Unity/Rift S] Unchecking "Use Position Tracking" in OVR Manager leads to weird distortions in HMD
Using: - Unity 2018.4.2 - Oculus Integration 1.38 - Rift S Test Environment: - Clean, new project, only Oculus Integration inside and a test scene with default cubes - Tested on two different machines with two different Rift S headsets Problem: When I disable "Use Position Tracking" in the OVRManager of the default OVRCameraRig, the image inside the HMD gets super distorted. The image in editor is displayed correctly however. What I would expect from this checkbox is to simply disable 6-DoF positonal tracking and switch to 3-DoF instead. So there seems to be a bug of some kind. Does anyone know about this one or can provide a workaround for dynamically switching between 6- and 3-DoF on runtime? Best, Adrian
Locomotion technique that integrates best with positional tracking
Most people agree that natural walking using positional tracking offers the highest presence while not causing any vection-induced VR sickness. But because tracking space is limited, users need to switch to an alternative locomotion technique (ALT) to navigate beyond the confines of available tracking space. The majority of these ALTS are controller activated and include methods such as full locomotion/teleportation/vehicle movement. Because controller based ALTs require little physical effort to be activated while large distances can be travelled quickly, it has been suggested that users may adopt a "lazy gameplay" style where they abandon the use of positional tracking input altogether, leading to a lower presence. Rather than exclusive focusing on developing ALTs that minimize VR sickness, it seems better to focus on exploring ALTs that integrate best with positional tracking and that do not cause users to abandon natural walking input. My research lab did a study on the usage of ALTs in conjunction with positional tracking (see paper). Participants had to complete a navigation task that involved traveling to a waypoint that lied outside the tracking space and then one or two random waypoint were generated that lied within the tracking space that users could walk to and participants repeated this sequence 40 times. When using full locomotion (directional navigation) using a controller we found that users abandoned natural walking input and adopted the controller as their primary locomotion method. Because switching from leg based input to hand based input requires a significant context switch with a high cognitive load, we also evaluated using walking-in-place (WIP) (which closely mimics walking) as an ALT. Surprisingly, when using WIP with positional tracking, participants did not abandon natural walking. Participants also found the use of WIP to offer a higher presence while not causing any VR sickness. Another benefit is that WIP leaves both hands free (useful when playing an FPS with tons of enemies). Here's a video showing our legomotion locomotion solution. Feedback/suggestions appreciated.