AvatarGrab performance issues on Quest — Oculus
IMPORTANT:

All Oculus Quest developers MUST PASS the concept review prior to gaining publishing access to the Quest Store and additional resources. Submit a concept document for review as early in your Quest application development cycle as possible: https://developer.oculus.com/quest-pitch/

For additional information and context, please see "Submitting Your App to the Oculus Quest Store".
Welcome to the Oculus Developer Forums!

Your participation on the forum is subject to the Oculus Code of Conduct.

In general, please be respectful and kind. If you violate the Oculus Code of Conduct, your access to the developer forums may be revoked at the discretion of Oculus staff.

AvatarGrab performance issues on Quest

I am testing out the AvatarGrab sample on Quest. I followed the quality setting recommendations here:https://developer.oculus.com/documentation/quest/latest/concepts/unity-build-android/.
 Despite this, the frame rate is very low and the whole scene seems to bounce around a little. It's otherwise functional. Is this normal? 

Comments

  • foohrichfoohrich Posts: 2
    NerveGear
    Same issue here since Oculus integration v1.39. Unfortunately the recent update to v1.40 didn't help. I really want to avoid manual downgrading. But if you want to give it a try, go to the archive and download v1.38.
  • CorysiaCorysia Posts: 55
    Hiro Protagonist
    This is something that has been bugging me a lot.  I set several quality values way way down. Yet even in a simple scene with baked lighting and avatar hands, I see a lot of choppy movement when I move my hands around.  When I pick something up, I see some choppy behavior, too.

    When I record something, I don't see that in my recording.  So it's my guess that it's some sort of timing/vsync issue.  I haven't really looked in to it, but I noticed another long thread about it.

    I started looking at other professional games, like Vader Immortal, and I noticed that the lightsaber and hands are just as choppy.  So for now, I'm not too stressed about it.  It may be that my simple scenes just really exaggerate the issue because I don't have a lot of textures in the background, making it more apparent.
  • takariendiretakariendire Posts: 11
    NerveGear
    Thanks, it's helpful to know others are having the same issue. I need to take another look at Vader Immortal, I hadn't noticed this. 
  • jpeeziousjpeezious Posts: 3
    NerveGear
    I've noticed this same thing with this sample scene in 1.40 EXTREMELY slow. It was actually crashing for me until I fiddled with some settings...
  • takariendiretakariendire Posts: 11
    NerveGear
    Interestingly, the DistanceGrab sample works much better. It does have less elements, but I doubt this is really the issue.  
  • CorysiaCorysia Posts: 55
    Hiro Protagonist
    This weekend, I thought it might be related to Timings, so I wrote a script to adjust them based on which headset is detected.  I haven't tested it yet.
    using UnityEngine;
    using UnityEngine.XR;
    
    public class SetTimings : MonoBehaviour
    {
        void Start()
        {
            Debug.Log("Headset: " + XRDevice.model);
            switch (OVRPlugin.GetSystemHeadsetType())
            {
                case OVRPlugin.SystemHeadset.Oculus_Go:
                case OVRPlugin.SystemHeadset.Oculus_Quest:
                    Time.fixedDeltaTime = 0.0138f;
                    break;
                case OVRPlugin.SystemHeadset.Rift_S:
                    Time.fixedDeltaTime = 0.0125f;
                    break;
                case OVRPlugin.SystemHeadset.Rift_CB:
                case OVRPlugin.SystemHeadset.Rift_CV1:
                case OVRPlugin.SystemHeadset.Rift_DK1:
                case OVRPlugin.SystemHeadset.Rift_DK2:
                    Time.fixedDeltaTime = 0.0111f;
                    break;
                case OVRPlugin.SystemHeadset.GearVR_R320:
                case OVRPlugin.SystemHeadset.GearVR_R321:
                case OVRPlugin.SystemHeadset.GearVR_R322:
                case OVRPlugin.SystemHeadset.GearVR_R323:
                case OVRPlugin.SystemHeadset.GearVR_R324:
                case OVRPlugin.SystemHeadset.GearVR_R325:
                    Time.fixedDeltaTime = 0.0167f;
                    break;
            }
        }
    }
    

  • takariendiretakariendire Posts: 11
    NerveGear
    edited September 5
    I noticed that what affects performance in the sample is displaying avatar hands. When the hands are not displayed the performance is fine. 
  • nstolnstol Posts: 2
    NerveGear
    Did you ever figure this out? I've been fighting with it all day!
  • nstolnstol Posts: 2
    NerveGear
    Okay after 6 hours I finally got the demo to work.
    I've been using the DistanceGrab prefab to test.
    The problems I was having were:
    1. Only one hand showing up at a time (fixed with changes to Android manifest).
    2. Video running super slowly and glitchy (and eventually crashing) when the hands were in-view.

    Someone said I have to add the appID to the Oculus > Tools > Oculus Platform Tool panel. I did that and then I used the option to regenerate the manifest file. After doing that I had two controllers (hands) that actually worked and I as able to pick stuff up! But also the screen got terribly glitchy, with ragged looking edges like it was doing last month. So I decided to make a new project, in the new version of Unity.

    Here's what I did:

    Integration 1.4
    Unity 2019.2.4f1 (Was using 2018.4.5f1 before). 
    I have a feeling that the Unity version itself didn't matter, but when I installed it, a couple things happened.

    A). It asked me if I wanted to upgrade the OVR plugin thingy, and this time I hit "no". I also declined to update the Audio Spacializer plugin, when it prompted me about that next. This was recommended by someone I read online. Not sure if it was the main issue.

    B). When I tried to build, it told me that it didn't support Vulkan, and to go to Player Settings > Other Settings Graphics APIs and remove Vulkan (which was above OpenGLE3). I have a feeling that's what was causing the glitchy video.

    The other things I did, starting from a blank 3d project was:
    Oculus > Avatar Settings > App ID: 
    Oculus>Tools>Delete Androidmanifest
    Oculus>Tools>Create store-compatible AndroidManifest.xml
    Then I added these lines to the manifest:
    <meta-data android:name="com.samsung.android.vr.application.mode" android:value="vr_only"/>
    <meta-data android:name="unityplayer.SkipPermissionsDialog" android:value="false" />

    Interestingly, I forgot to set the device to Quest in both OculusProjectConfig and Oculus > Tools > Oculus Platform Tool. It's set to GearVR or Go, but seems to work just fine. 
  • takariendiretakariendire Posts: 11
    NerveGear
    Thanks for the detailed walkthrough. I feel like I did exactly the same thing as you except declining to update the Audio Spatializer and adding the lines to the manifest. I'll try each separately when I get the time, hopefully isolating the issue :)
  • goodbyesquaregoodbyesquare Posts: 3
    NerveGear
    The issue is for some reason when you have the oculus avatar setup with the app id (enabling showing your hands as takariendire said) the local avatar will continuously generate skinned mesh renderer copies until the game eventually slows down so much it crashes. This is only in 1.39 and 1.40 as far as I've tested it works fine in 1.38.

    @nstol what you did isn't a solution. The localavatarwithgrab is broken. Using a completely different prefab and setup (distance grab) isn't a solution to the other being broken it's just avoiding it.

    Do oculus staff actually read this stuff? Is there any way to submit this bug to them?


Sign In or Register to comment.