bug report

3 Topics

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...
Anonymous
4 years ago Place Unity Development
1.8KViews
0likes
1Comment
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
btelman
6 years ago Place Unity Development
615Views
0likes
0Comments
libovravatar.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.
wallacet_mfm
6 years ago Place Unity Development
951Views
0likes
1Comment