Quest 2 No Tracking Problem After Updating To V25
I'm probably one of the first users to get the new update, but the only problem is after I updated I've been getting this problems where my headset loses my tracking and I either have to wait a few minutes or hard reset my Quest. I restarted my quest about 2-6 times about now and it's getting very irritated. Although seeing that this update just rolled out, I can see this being fixed sooner or later. Edit: Forgot to mention that sometimes I just don't see anything when I look into the headset.Unity - Hand tracking disappear forever when adding OVRGrabber
So I was trying to implement a grabber with the Hand tracking but i didnt know why my hands were disappearing at some point in the development. Then I realized that when i added the OVRGrabber to the hands, those disappear from the scene, but they are still there cause I can touch the Guardian system with my hands. So when I delete the OVRGrabber the hands were still invisible. Im sure that the OVRGrabber is causing this, cause i were compiling step by step to catch where the hands were disappearing. Btw im using just the OVRCameraRig prefab, the HandsManager and the OVRHandPrefab. EDIT: So i figured out that you can solve this problem deleting the OVRHandPrefab and grabbing it under the controller anchor again and it will fix... but i dont know why you cant put the OVRGrabber to the OVRHandPrefab...
2 Bug Reports:
I've been getting the 2 same bugs on my Quest: After closing an app on my quest through the universal menu the menu will duplicate and is a pain to close. When I'm trying to view how much space is used on my quest, The Storage menu won't open and will take me back to "Quick Menu" and when trying it again it'll do the same again. Other times it won't load ever. Restarting Won't work. Please Fix!
"Look at your selection and press the volume button" doesn't work!
When powering down my Quest, I am presented with an options menu to confirm what I want to do (e.g. shutdown). The instructions say to look at my desired selection and then press the headset's volume button to select it. In other words, it gives me instructions to make a selection without having to use the Touch controllers. The problem is that it doesn't work! I turn my head to point to the various options but the highlighting doesn't move. The selection doesn't change. Pressing the volume button likewise does nothing. It doesn't even trigger whichever option was selected by default. It's completely broken functionality. I have no choice but to use the controller every time which is a nuisance when all I'm doing is picking up my headset to shut it down.
Performance issues after returning from the Universal Platform Menu when using Unity 2017.4 versions
I have noticed severe performance drops from hitting the home button in an app and coming back to it by hitting resume on the Oculus Go. Another weird issue is that it fixes itself if these steps are repeated again. This was repeatable on an empty project with an empty scene (only had camera and light) without the Oculus SDK. 1. Open app 2. Hit the home button once fully loaded 3. Hit resume on the app paused screen 4. Framerate will be lower than it was before. This varies depending on how many objects are being rendered in a scene, and is not really noticeable in an empty scene until the profiler is used, since it still seems to hover around 60 or slightly below. This happens in 3 different projects set to non-development build with varying amounts of objects and Unity 2017.4 versions, and happens on the latest 2017.4 build. Earliest tested build that has the issues is Unity 2017.3.0f3 2017.4.34f1, empty scene, cube, and simple canvas, project default settings, Single pass (stereo vs single pass does not matter) Oculus SDK: None added, using built in oculus support, but appears like it probably happens on any Oculus SDK (Tested an old Oculus SDK and the latest as of 11/26/2019) Oculus Go Headset versions: 9.0.0.168.450.174044450 (headset 1) and 11.0.0.179.458.183074809 (headset 2) Since this test project did not have the Oculus SDK, it was running at 60fps. Running it at 72 causes the frame rate to drop to 60fps on a mostly empty scene The profiling screenshot is from headset 1, but also looks the same on headset 2 It is worth noting that versions tested of Unity 2018.4 appear to not include this issue (2018.4.9f1, 2018.4.13f1), and work perfectly fine as a workaround to this issue
compilation error with VS2019 16.3.0
Hello, Microsoft released update 16.3.0 to their VS2019 yesterday. https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes#16.3.0 Apparently that breaks compilation with the SDK version 1.40.0. ...\Logging\src\internal\Logging_Tools.cpp(435,41): error C2039: 'experimental': is not a member of 'std' Do you have a patch available or is there an ETA? Thanks -Thomaslibovravatar.dll (version 1.2.3.0) Causing unlogged crashes
Context info (from OVRManager's console log): Unity v2018.2.21f1, Oculus Utilities v1.37.0, OVRPlugin v1.37.0, SDK v1.38.0. ---Yesterday, the sdk version was also 1.37.0, I'm not quite sure how that updated but the crashes have happened with both versions. The crashes are not logged in Unity's output log, nor are there any hints as far as I could tell. I used the OculusLogGatherer tool to finally find what was causing the crash. I'll paste the event logs. The Unity application we're developing is a crane simulation, where we teach the player how to give specific hand gestures/motions to signal a crane. To help with that, we use the Oculus avatar system to record a developer giving the correct signals and play the recording back at runtime for the player to mimic. This project has been in development for 2 years and we have updated our Unity version and Oculus sdk and plugin a few times over that span. The signal recordings were taken a long time ago and we have updated our project since then. So far, the crashes have not occurred predictably; we can sit and watch the recordings playback for several minutes, starting and stopping as expected. Then, in the middle of one of the recordings, the editor (or build) will crash. I haven't been able to establish a clear pattern for it, but it might be related to starting a new recording soon after ending a previous one, but that is a low confidence guess. The crashes occur both on our development machines and on Valve's test machines, which is unfortunately how we first noticed the crashes. I'm guessing our QA team flew through the tutorial so fast that the problem didn't show up. Here are the event logs capturing the crashes, some in the editor and one in the player: Faulting application name: Signal Person Training.exe, version: 2018.2.21.8949, time stamp: 0x5c73f900 Faulting module name: libovravatar.DLL, version: 1.2.3.0, time stamp: 0x5cdb398c Exception code: 0xc0000409 Fault offset: 0x000000000004c23c Faulting process id: 0x1968 Faulting application start time: 0x01d5212f09126f1a Faulting application path: C:\Program Files (x86)\Steam\steamapps\common\CLS Signal Person\Signal Person Training.exe Faulting module path: C:\Program Files\Oculus\Support\oculus-runtime\libovravatar.DLL Report Id: c1a76a9f-e118-4675-bae6-6308941d7cf2 Faulting package full name: Faulting package-relative application ID: Faulting application name: Unity.exe, version: 2018.2.21.8949, time stamp: 0x5c73f759 Faulting module name: libovravatar.DLL, version: 1.2.3.0, time stamp: 0x5d003cf3 Exception code: 0xc0000409 Fault offset: 0x000000000004cc3c Faulting process id: 0x3188 Faulting application start time: 0x01d521e815270000 Faulting application path: C:\Program Files\Unity\Hub\Editor\2018.2.21f1\Editor\Unity.exe Faulting module path: C:\Program Files\Oculus\Support\oculus-runtime\libovravatar.DLL Report Id: 208d504e-7332-474f-b614-47dc04020bc3 Faulting package full name: Faulting package-relative application ID: Faulting application name: Unity.exe, version: 2018.2.21.8949, time stamp: 0x5c73f759 Faulting module name: libovravatar.DLL, version: 1.2.3.0, time stamp: 0x5d003cf3 Exception code: 0xc0000409 Fault offset: 0x000000000004cc3c Faulting process id: 0x1e2c Faulting application start time: 0x01d521f05faa3373 Faulting application path: C:\Program Files\Unity\Hub\Editor\2018.2.21f1\Editor\Unity.exe Faulting module path: C:\Program Files\Oculus\Support\oculus-runtime\libovravatar.DLL Report Id: 59ac9a4a-6b19-42d5-badf-eedd001667db Faulting package full name: Faulting package-relative application ID: After investigating the reported exception code, it looks like this is a stack buffer overflow fault, according to this Microsoft forum (https://social.msdn.microsoft.com/Forums/sqlserver/en-US/aa84a49e-6bfe-4b89-928a-ea477e73c07e/clr-exception-0xc0000409?forum=clr) and supported by other search results. I couldn't find any information on my version of libovravatar.dll (1.2.3.0), but since it's part of the runtime I expect Oculus to automatically update this. Our recording and playback system is based on the provided sample scripts in Assets/Oculus/Avatar/Samples/RemoteLoopback and the guide found here: https://developer.oculus.com/documentation/avatarsdk/latest/concepts/avatars-gsg-unity/ Here's the playback code: TextAsset asset = Resources.Load(filename) as TextAsset; if (asset != null) { MemoryStream s = new MemoryStream(asset.bytes); reader = new BinaryReader(s); loadPacket(); } /// <summary> /// This is called recursively for every frame in the avatar recording. /// </summary> void loadPacket() { if (reader.BaseStream.Position >= reader.BaseStream.Length) {//If we've reached the end of the file, load it again and start over. reader.Close(); this.DelayedInvoke(delegate { loadFile(); }, .1f); return; } int sequence = reader.ReadInt32(); int size = reader.ReadInt32(); byte[] sdkData = reader.ReadBytes(size); IntPtr packet = CAPI.ovrAvatarPacket_Read((UInt32)size + 8, sdkData); OvrAvatarPacket p = new OvrAvatarPacket {ovrNativePacket = packet}; remoteAvatar.GetComponent<OvrAvatarRemoteDriver>().QueuePacket(sequence, p); this.DelayedInvoke(delegate { normalize(); loadPacket(); }, remoteAvatar.PacketSettings.UpdateRate); } private void OnDestroy() { if (reader != null) { reader.Close(); } if (remoteAvatar) { Destroy(remoteAvatar.gameObject); } } normalize() adjusts the scale and position of the playback avatar to make it look nice and appear where we expect. I'm hoping someone can tell me if this is a bug on Oculus' end, or if we are using the api improperly in some subtle way I haven't discovered yet. In either case, Is there a suggested workaround? We could bypass the problem altogether by moving away from the avatar system and just tracking position and pose data ourselves, but that seems an awful waste.
[Gear VR] Release for distribution build fails
I haven't built for distribution since 4.13 (and back then it worked just fine) Finally today I wanted to build my first alpha build for Oculus Home and ... it failed. Some Oculus lib is missing apparently (I've never seen this issue before). Here is output log: https://drive.google.com/open?id=0BwE6dxM0O2PsVklkSEcwMF83dE0 I also filed a bug report with Epic: https://answers.unrealengine.com/questions/598530/gear-vr-release-for-distribution-build-fails.html[Gear VR] 4.15.1 monoscopic renderer crash on level load
Since I finally got 4.15.1 up and running with FMOD and my project seems to work as expected after upgrading to 4.15.1, I decided to give monoscopic renderer a spin. Sure enough right after level was loaded (streamed), the app crashed. Here is logcat: https://drive.google.com/open?id=0BwE6dxM0O2PsVHhlUmZUbjFnYlk Galaxy S6 Android 6.0.1 Exynos / Mali Gear VR service VR Framework version 11.1.0 / VR service version MAIN / 2.6.65 / 266500000 03/15/2017, 3:09:47 AM (got bunch of updates earlier today) Let me know if I should also report it using submission form.
