BUG: floor height useless on Quest

XRDevice.SetTrackingSpaceType(TrackingSpaceType.RoomScale);

This does nothing of any use at all with Quest. What am I doing wrong? I just want correct height like the entire library of quest games I've played. They all seem to get it right, so I must be doing something wrong?

The above returns false, no matter what. Doesn't matter if I'm roomscale, or stationary, that bad boy is false.

After a week of struggling I'm becoming pretty tired

 

Sure, thanks! (Case 1190607)

 

This used to work for me in a older version (sorry I don't remember the exact version, but it was some 2019 version), so there might be a other issue.

As a warning I didn't work with the Quest for a while, so I don't know the current state of the situation, but: A while ago the Quest was updated and added a feature to run Oculus Go games and as far as I know this "broke" Quest games built with Unity, because you had to edit some android files after the build (I don't remember which, but you might find more information on google). I don't know if this was "fixed" yet, because Unity should output the "correct" files, but maybe it isn't "fixed" in your current version and your Quest runs in the "Go mode", that would explain why it refuses to enable the room scale mode.

This is just a random guess, maybe you can find more information about this topic and hopefully you will find a solution for your problem.

 

I think it might be the Android manifest addition / change you need to do. I did it a while ago in a project for a Quest deployment, I created the following file Assets/Plugins/Android/AndroidManifest.xml

Code (CSharp):

1. <?xml version="1.0" encoding="utf-8"?>
2. <manifest
3.     xmlns:android="http://schemas.android.com/apk/res/android"
4.     package="com.unity3d.player"
5.     xmlns:tools="http://schemas.android.com/tools"
6.     android:installLocation="preferExternal">
7.     <supports-screens
8.         android:smallScreens="true"
9.         android:normalScreens="true"
10.         android:largeScreens="true"
11.         android:xlargeScreens="true"
12.         android:anyDensity="true"/>
13.  
14.     <application
15.         android:theme="@style/UnityThemeSelector"
16.         android:icon="@mipmap/app_icon"
17.         android:label="@string/app_name">
18.         <activity android:name="com.unity3d.player.UnityPlayerActivity"
19.                   android:label="@string/app_name">
20.             <intent-filter>
21.                 <action android:name="android.intent.action.MAIN" />
22.                 <category android:name="android.intent.category.LAUNCHER" />
23.             </intent-filter>
24.             <meta-data android:name="unityplayer.UnityActivity" android:value="true" />
25.         </activity>
26.     </application>
27.     <uses-feature android:name="android.hardware.vr.headtracking" android:required="true" android:version="1" />
28. </manifest>

The important part is the <uses-feature android:name="android.hardware.vr.headtracking" android:required="true" android:version="1" /> That switches you from 3dof to 6dof and from one controller to two controllers if I remember right. The rest was just a vanilla manifest from a build I did.

 

@jackpr do we need to edit manifest still? thanks for any insights.

 

I believe the newer implementations of Oculus Loader/Oculus Android support have a 'Oculus Quest v.2 Signing' tickbox in the Player settings under VR

 

Yeah using it

I suspect I have to poll or look for when tracking changes and call it again. Because if you move out of sitting slightly pause the app, or move to another guardian, it will need calling again, so you can't just set it in start and ignore it thereafter.

I noticed it sneakily popping down to floor again when I shifted to another guardian, so it's probably something related to that. Even so Unity should investigate this as there's a conflict:

Up until now, mobile VR has all been stationary by default, so it defaults to HMD tracking, but even the new quest signing doesn't default it to roomscale, and quest very much should default to roomscale, given it's the USP and point of the device's existence.

 

Aha! thank you

And IMHO I think you should deprecate them as soon as you're able - at least begin the whole warning thing because it'll prevent people still making a bunch of tutorial content and so on which is something I had to wade though. Be nice to get people on the same page sooner - very easy to build against something that will soon change.

 

Just when I had sussed out the XRDevice APIs in my own project.. I'm going to basically start from scratch once those bits are deprecated

A heads up on this as a forum post or blog post would be useful as there is a lot of misinformation around best practices for VR and even though I spend most of my time working in VR I am constantly confused by what I should be doing first when setting up a project.

 

...same here!! That's what I am using!

As @ROBYER1 mentioned I have no idea what I should be doing when starting up a project now (again!). Every time I think I have a reasonably well supported path and project setup the goalposts move.

Whilst you are changing the fundamentals of Unity XR (and the rest of the engine with SRP's etc) we need a CONSTANTLY UPDATED cheat sheet for current project setup, best practice for various popular devices (for me personally that's Quest / Rift + Vive), how to manage a cross platform approach and access platform features if needed, rendering suggestions for Quest esp given its limited power, probably more stuff, help us to get on please.

What makes it worse is know for a fact your competitors have this today, I've tried it and things work straight out the box, no faff. Being honest its only my fear of C++ I know I'd need at some point thats stopped me carrying on with it, however the fight feels fair without the rug constantly being pulled out from me.

For me I'm not super invested yet into Unity (I know the basics and have finished one VR project) and I'm honestly just thinking of leaving all VR work in Unity (again) alone for a year and picking up something that just works, the time I'm wasting I can learn a more about other things as well besides engines which I really need to, I'm firmly in the new to 3D arena.

Sorry if I seem a little upset, I just want to make things!

 

Yep, I've mentioned a few times how the APIs are way too fragmented and a total nightmare to navigate (there are basically 3, mingled) and that needs stopping ASAP, because it's a case of the blind leading the blind and it's getting worse until we see those friendly yellow deprecated messages sooner, rather than later.

I mean nobody even realises the Node stuff will be deprecated too, and are right now, building up their code bases against something with absolutely no future.

UNITY: we don't want you to support things going forward that's already there *without* heavy deprecation warnings. Most if not all of us want to code against a single XR plugin API. Please roll out the deprecation warnings ASAP : ) That alone will suffice, people can then easily navigate through to the correct equivalents and you stop people building toward failure.

And Unity staff: Thank you for your hard work. I don't want to stress you, but it's great you're all doing both your jobs and helping us with ours!

 

Thank goodness, I was going quackers...!

 

Thank you for the update and apologies for the frustration boiling over a little. I'm no Unity expert so having a smooth experience is really important me, I cause enough problems of my own

 

Thanks for the update. I'm having a wide range of weird issues with VR that just weren't there a month ago, due to how fragmented and undocumented the whole XR thing is, and how fast these things are updating and changing.
Looking forward the next updates!

 

Having issues with this again in Unity 2020 now, seems something has changed with how the tracking space is set specifically for the Quest only where the head tracking will be set to the floor for some reason, Oculus Link in Editor does not exhibit the same issue

 

I found this issue too in Release Candidate 1 for 2019.3 and the current latest 2020.1 alpha versions. I was setting the room scale tracking type in Awake which seemed to work fine until the recent 2 Quest updates which enabled Oculus Link. Since then the room scale didn't work until I changed the code to run in Start instead of Awake.

Should I report this also? @hippocoder

 

Yes please!

 

Just set the height of the CapsuleCollider to 1 instead of the default 2 on the PlayerController. This solved to issue for me.