Search Unity

"Best Practice" Project Settings for Daydream?

Discussion in 'Daydream' started by Claytonious, Oct 29, 2016.

  1. Claytonious

    Claytonious

    Joined:
    Feb 16, 2009
    Posts:
    571
    Generally speaking, when targeting Daydream VR and Google Pixel (and subsequent Daydream-certified devices):

    * Should we enable vsync or not? Is this setting ignored at runtime anyway?
    * Does using 32-bit display buffer have any special significance on Daydream, good or bad?
    * Should we enable multithreaded rendering?
    * Should we enable Graphics Jobs?

    I know the answers to these have historically varied according to target devices and the specific needs of a each application, but I hope that the vastly narrowed profile of Daydream-certified target platforms will help us narrow down at least some of these options to the "generally best choice", at least as a starting point.

    Thanks!
     
  2. Tuitive

    Tuitive

    Joined:
    Mar 25, 2013
    Posts:
    36
    I gleaned the following pointers on this topic a while back from one of the Google IO vids about Unity Daydream VR settings:
    • Enable 2x Anti Aliasing. (Unity will issue a warning about performance when you build, but it performs fine and looks bad without it.)
    • Disable real time shadows. (They look bad and kill performance.)
    • Disable "Use 32-bit Display Buffer"
    • Stick with Forward or Vertex rendering
    • Enable Multithreaded Rendering
    • Enable Static and Dynamic batching
    The above doesn't address all of your settings questions, but it's what I'm using until someone suggests otherwise. I'm getting good performance in the meantime.
     
  3. thep3000

    thep3000

    Unity Technologies

    Joined:
    Aug 9, 2013
    Posts:
    271
    All of @Tuitive 's suggestions are good.

    Clearing up the remaining points:
    • vsync should be disabled -- each VR SDK has its own mechanism of synchronizing with the display and ignore vsync. With daydream vsync and setting Application.targetFrameRate actually _do_ work, but in general it is only recommended if you need to throttle your framerate lower and rely on reprojection.
    • 32-bit display buffer utilizes more bandwidth which is probably the most expensive thing for mobile VR in terms of power / heat, so it is recommended that you use 16-bit if you can get away with it. Same with depth buffer (there is a setting in the daydream dropdown in player settings VR list).
    • Multi-threaded rendering is absolutely recommended, this will free up time on the cpu main thread which is the bottleneck most mobile games will see first.
    • Graphics Jobs: case-by-case. Experiment with them and see if they help. I'm not entirely sure if there is a huge benefit on mobile.
     
  4. Claytonious

    Claytonious

    Joined:
    Feb 16, 2009
    Posts:
    571
  5. Ethan_VisualVocal

    Ethan_VisualVocal

    Joined:
    Mar 23, 2016
    Posts:
    127
    What about IL2CPP?
     
    Selzier likes this.
  6. sterlingcrispin

    sterlingcrispin

    Joined:
    Oct 23, 2013
    Posts:
    12
    thanks for the tips, this thread should be stickied!
     
  7. joejo

    joejo

    Unity Technologies

    Joined:
    May 26, 2016
    Posts:
    542
    Done. :)
     
    chelnok likes this.
  8. fmielke

    fmielke

    Joined:
    Oct 17, 2016
    Posts:
    35
    Yeah, performance boost from 30 to 60fps :) thank you!
     
  9. mat9054

    mat9054

    Joined:
    Nov 14, 2015
    Posts:
    42
    Regarding texture compression. Which one should I use. My knowledge regarding texture compression is null. But the fact that daydream app will only be used with daydream compatible phone give me the impression there should be one that will gives better results over another.
     
  10. Tuism

    Tuism

    Joined:
    Oct 23, 2013
    Posts:
    28
    Hi, I've tried to use these best settings, but struggling with what @Tuitive said about shadow settings - I have one directional light in my scene, and Shadow Type is "no shadows". In editor there's no shadows, but when I build to device (XL) and run, the really bad shadows remain (in fact it starts out at high quality and as I move around a bit it deteriorates). Why is this?

    I thought bad shadows could at least be solved by moving the light source with the player camera so that the proximity from the light remains close, but it didn't help (nor should it since it's a directional light, right?).

    Thanks in advance guys.
     
  11. SiliconDroid

    SiliconDroid

    Joined:
    Feb 20, 2017
    Posts:
    296
    Nice info @Tuitive & @thep3000 thanks!

    I've also found it necessary to enable Anisotropic (per texture) for floor texture, but only for expansive texture with hard lines in it like roads with markings for which I pushed anisotropic up to 6, other softer or more localized textures don't need it. Didn't notice any FPS loss.

    @Tuism
    UnityMenu / Edit / QualitySettings ...
    Select only one allowed quality level like fastest (untick all others columns).
    Have that level all setup as needed.

    Make sure you have
    UnityMenu / File / BuildSettings ...
    set to android *before* you do the above. I got caught out on this.
     
    Last edited: Mar 27, 2017
  12. SiliconDroid

    SiliconDroid

    Joined:
    Feb 20, 2017
    Posts:
    296
    Out of interest what are you guys approx triangle budgets for Daydream? i.e. total triangles in stereo render (2x monocam in editor).
     
  13. EddieOffermann

    EddieOffermann

    Joined:
    Sep 13, 2015
    Posts:
    11
    I've found the best solution for me is to add a couple more quality settings and explicitly create one for Daydream, one for Cardboard on Android, one for Cardboard on iOS, one for Tango, one for whatever else. The default high/medium/low things are great starting points but if you're not tweaking on a per-deployment platform basis my experience suggests that you're probably going to have a bad time. It's hard enough to deploy this sort of thing for more than a couple of devices because of how much we're pushing the edges of what's able to be rendered already.
     
  14. dmarfurt

    dmarfurt

    Joined:
    Apr 28, 2013
    Posts:
    9
    Eddie, would you mind posting your separate quality settings for the Daydream/Cardboard iOS/Cardboard Android platforms? We're struggling to get our FPS above 30 on most devices and could use some pointers. It's perplexing because the scene is totally empty except for a skybox and a canvas with an FPS counter on it.
     
  15. unityinhance

    unityinhance

    Joined:
    May 10, 2016
    Posts:
    1
    Also, enable 24-Bit Depth Buffer under Project Settings -> Player -> Other Settings -> Daydream VR SDK. This will get rid of shimmering "zig-zag" edges and provide a more consistent framerate.
     
    vonbetelgeuse, MieronVR and sskenth like this.
  16. sskenth

    sskenth

    Joined:
    Sep 23, 2016
    Posts:
    33
    Thank you for this, I had no idea why I was getting this shimmering effect, it was driving me crazy. Tried so many things to try and fix it, but your solution is spot on, I'm amazed I have yet to see this anywhere else.
     
  17. SiliconDroid

    SiliconDroid

    Joined:
    Feb 20, 2017
    Posts:
    296
    Yeah if the difference between the magnitudes of your cameras near and far clip planes is too great then 16 bits simply isn't enough to sort triangle pixel depths and so you get ambiguous triangle edge interfaces. Or if you put two surfaces too close you'll get z-fighting as both surfaces dance around the same depth value.

    In VR we need quite a good clip plane range, so 24 bits recommended.

    A ratio of 500:1 or below for 16 bit... so you'll get away with 16 bits if you had say near of 10cm and far of 50m.

    16 bit depth is a little faster though, more so on older devices.
     
    sskenth likes this.
  18. sskenth

    sskenth

    Joined:
    Sep 23, 2016
    Posts:
    33
    Thanks that good to know. I actually never had the shimmer effect in 5.6.0f1. But that version has a close-bug which stopped me from submitting to daydream. I've just upgraded to 5.6.3f1 but have noticed a drop in fps. If anyone has any further advice in increase fps I'd love to hear it.

    What version is everyone using for their daydream project? 5.6.0 or 5.6.1 or 5.6.2 or 5.6.3? Has anyone found theres better performance on one more than the others?

    On a side note, I can't see much information in the docs about 24-bit-stencil. Does anyone have any more info about that, or could you point me in the direction where I could read up on it?

    Thanks
     
    Last edited: Oct 3, 2017
    SiliconDroid likes this.
  19. SiliconDroid

    SiliconDroid

    Joined:
    Feb 20, 2017
    Posts:
    296
    I cant remember much perf difference on all the 5.6.x unity versions.

    I'm using 2017.1. Single threaded pass rendering gives big boost, but it's not production ready because some phones are rendering black screen with it, but soon it should be good.

    Daydream and cardboard rendering is getting a promised perf increase on next unity release (real release not beta).

    https://en.wikipedia.org/wiki/Stencil_buffer

    I would not bother with stencil on mobile at the moment, the GPUs are using a cell based optimization scheme, and stencilling breaks it. You can test yourself: Set up a big array of overlapping quads with a see through pattern on, like a load of trees or window frames, use alpha shader in one test and use cutout shader (stencilling) in the other:

    Intuitively I thought cutout would be way faster, that's it's purpose, to eliminate overdraw. But on mobile you observe the opposite: the alpha shader is way faster (to a certain overlap depth) and this is because the cell optimization breaks or at least cannot optimize as much. (I cant find official info on this, but other devs have also mentioned it).
     
    Last edited: Oct 4, 2017
    sskenth likes this.
  20. sskenth

    sskenth

    Joined:
    Sep 23, 2016
    Posts:
    33
    Thank you for the info @SiliconDroid, this is really helpful stuff. My game is in open beta, but that final 10 percent to do is a real pain in the neck, I appreciate the tips, looking forward to the new version of unity too. I may try a few 5.6.x versions though just to see if theres a slight performance boost on one over the other. I'll report back if I notice anything valuable.
     
    SiliconDroid likes this.
  21. jmitcheson

    jmitcheson

    Joined:
    Oct 21, 2016
    Posts:
    96
    Really? Do you know which phones? :eek:
     
  22. SiliconDroid

    SiliconDroid

    Joined:
    Feb 20, 2017
    Posts:
    296
    Samsung Galaxy S8/S8+ that I know of.
    Just tested again and single pass renders black, game still runs.
    Same Daydream APK with single pass renders fine on ZTE Axon7.
    Samsungs new phones are always popular so it's already a fairly big chunk of daydream market.
    It may not be a unity problem, it maybe a driver issue that Samsung has to fix?
     
  23. jmitcheson

    jmitcheson

    Joined:
    Oct 21, 2016
    Posts:
    96
    Damn! I just saw the other thread. SP is no-go on S8 then? I don't have one to test. That's a bit worrying - not sure if I can maintain 60FPS with SP off.

    Is there an official bug case anywhere? I tried searching but nada.

    Actually.. maybe this is the closest thing (SP on Mali GPU): https://github.com/googlevr/gvr-unity-sdk/issues/709
     
  24. SiliconDroid

    SiliconDroid

    Joined:
    Feb 20, 2017
    Posts:
    296
    @jmitcheson
    I looked at the github issue, yes it's the issue.
    I just enabled MSAA on my projects quality settings and SP now "works".
    I had MSAA disabled to squeeze out extra perf.

    Something needs fixing still though:

    Regardless of single or multi pass rendering, in fact regardless of any player setting related to VR, (skinning, multithread etc) daydream performance is "glitchy" on my S8: it's like if you dont make 60Hz submit the asynch reprojection does a bad job if your heads moving.

    Same APK runs good on ZTE Axon7, even when it drops to like 58 FPS AVG and I'm not making 60Hz submit.

    Other APKs downloaded from daydream store exhibit glitch on S8, I presume it's Samsungs implementation of daydream that's glitched.

    I've got a few months until release, so hopefully it'll be fixed by then.

    EDIT: The S8 glitchiness also exists in Googles GVRDemo room example, which is a very modest scene.
     
    Last edited: Oct 5, 2017
  25. jmitcheson

    jmitcheson

    Joined:
    Oct 21, 2016
    Posts:
    96
    Ah ok. I watched/read a presentation on Daydream by an ARM engineer that said that MSAA was 'virtually for free'. You might find it interesting.. found it here. Then again, in the same talk he promotes Vulkan which AFAIK does not work yet..

    The S8 makes me nervous. There was another bug I think wasn't there, about random crashes, and some people narrowed it down to the Google VR services version on the phone. Not sure if they ever found out what it was. I am going to try releasing on only the Pixel first as I don't want bad reviews from crashes/driver issues etc.
     
  26. SiliconDroid

    SiliconDroid

    Joined:
    Feb 20, 2017
    Posts:
    296
    Yes I've seen that talk, I would not classify it as "virtually free"; I have scenes that hold 60 without MSAA and drop to low 50s with it (2xMSAA).

    My game uses procedurally generated scenes, so I can dial scene complexity (tri counts, mesh chunking etc) with just a few keystrokes. This way I can explore perf limitations "quickly"... get to the edge and then step back a bit.

    I would not release on S8/S8+ yet either, not unless you want bad review ratings as you say.

    Yes I think another bug is/was: phones are sold with screen res set to half native, to give best battery life. If you start GVR service like that it crashes, user must first set phone to full res (in phone settings). I think they rushed out the S8/S8+ firmware, but yes a worry, let's hope they fix it all up.

    Yes pixel is solid for daydream, and I can vouch for ZTE Axon7 also being solid.
     
    Last edited: Oct 6, 2017
    hungrybelome likes this.
  27. rrrus

    rrrus

    Official Google Employee

    Joined:
    Jul 13, 2015
    Posts:
    14
    16 bit color buffers are not always faster than 32 bit color buffers. There is an issue with Qualcomm GPUs where their bus compression feature is disabled for 16b color buffers causing 16b color buffers to perform worse by 2x than 32b color. When playing with these sorts of settings it is vital to measure the performance difference yourself on various devices.
     
    SiliconDroid likes this.
  28. Claytonious

    Claytonious

    Joined:
    Feb 16, 2009
    Posts:
    571
    But we only have one choice when building the APK. What you're saying is that this needs to be a runtime decision based on the GPU.

    Could you tell us, among the GPU's that are currently and soon-to-be certified as Daydream devices, what % of them behave this way? Or are you recommending that it is best to stick with 32-bit in this market?
     
    SiliconDroid and wojwen like this.
  29. nat42

    nat42

    Joined:
    Jun 10, 2017
    Posts:
    354
    Aren't they all specced as Qualcomm Adreno 500 series? I took the implication to be that which was faster depended on the application.
     
  30. kalineh

    kalineh

    Joined:
    Dec 23, 2015
    Posts:
    67
    I've been tracking a few issues for performance, which applies to all of android really but you'll be needing the performance more on daydream certainly:

    - canvas: the worst; having any of these adds about 0.5ms+ for canvas system overhead; scales linearly per canvas after that; canvas is extremely slow performance and you should outright ban them and write custom code to manage sprite / text renderers
    - animator components: having any of these adds about 0.5ms overhead for system; even if component disabled; if you dont need them, remove all the components (it's default import for a lot of things, be careful)
    - input systems: disable all default unity input axis values (0.2ms~)
    - culling: it's very slow and i dont know how to disable it (1.5ms+)
    - physx: about 1ms overhead for /any/ physics objects enabled (scales linearly after that)

    Still trying to figure out if we can disable culling one day entirely (our scene is always entirely in-view but we still lose 1-2ms for it).

    Also if you're really under heavy GPU load you can use these new built-in settings to cut GPU load a little (for whatever tradeoff of quality/perf you need):

    UnityEngine.XR.XRSettings.renderViewportScale = 0.80f;
    UnityEngine.XR.XRSettings.eyeTextureResolutionScale = 0.80f;


    tldr: ban canvas usage
     
  31. jmitcheson

    jmitcheson

    Joined:
    Oct 21, 2016
    Posts:
    96
    Good post, yes the canvas thing is quite annoying. At least TextMeshPro is now free - although the default texture size is 1024; you can reduce to 256 and it still looks OK.

    I would love a way to disable culling. Obviously you can turn off Occlusion culling in the camera settings, however the viewport culling has no such control. What's worse is that you can see even with a blank scene that there is significant overhead. I disabled all my gameobjects after baking them, and I still spend ~1.5ms in culling! There is some vague release note somewhere which claims to improve "Culling performance" but it doesn't even say which type; or how.

    Sometimes, my render loop spends more time culling than it does drawing :'(

    Thanks for the tip about the input axis values; didn't know about that one.
     
    kalineh likes this.
  32. kalineh

    kalineh

    Joined:
    Dec 23, 2015
    Posts:
    67
    I'd really wish someone from unity would give us some more insight on what's going on with viewport culling / render bounds calculations. It's often more than render time for us too, 1-2ms on a 10ms~ frame budget makes things really difficult. I'm presuming UpdateRenderBounds() in the profiler is also related to the viewport culling.

    I think perhaps skinnedmesh is one issue with culling calculation because it needs to figure out the bounds dynamically to account for animated positions. I just have no insight into the engine to see what it's doing or how to optimize it in any way. None of the occlusion settings anywhere seem to have any impact at all.

    I tried setting up a quick test of scriptable render pipeline, but the way the API works is that you get a list of renderers from the CullResults, and there's no function to bypass the culling and get a raw list of ALL the renderers, so that didn't help at all either.

    tldr; unity plz help (or someone with source code access)
     
    Ethan_VisualVocal likes this.
  33. thep3000

    thep3000

    Unity Technologies

    Joined:
    Aug 9, 2013
    Posts:
    271
    I've only started to hear comments about slow culling in the last week or so. Is this a regression? Or has it been happening in previous versions and nobody has complained loud enough? Also I expect this is not just VR mode?

    I've asked our QA to investigate and provide some numbers with previous unity versions. If anyone wants to provide a bug# we'll prioritize that.
     
  34. Cotycrg

    Cotycrg

    Joined:
    Jan 7, 2016
    Posts:
    3
    I've basically come to accept 0.5ms being eaten on even high end PCs for culling - I figured this was an unavoidable unity problem. Please tell me I'm wrong and this will be fixed! It's been like this since at least 5.6, probably before that too.
     
  35. kalineh

    kalineh

    Joined:
    Dec 23, 2015
    Posts:
    67
    I've been noticing it for about 2 months doing optimization work on current project - it definitely stands out more on the android builds because obviously performance budget is much tighter. It seems on the PC version that there is still a relatively similar relative overhead (but I don't think the culling scales linearly with rendering overhead).

    Bug reference: #979116

    Here's some screenshots and profiler data (android, android, PC):

    starbear-profile-android-bounding-volumes.jpg starbear-profile-android-culling.jpg starbear-profile-PC-culling.jpg
     

    Attached Files:

  36. jmitcheson

    jmitcheson

    Joined:
    Oct 21, 2016
    Posts:
    96
    Empty default scene, Unity 5.6.1f1

    upload_2017-12-19_13-39-38.png

    Taken from desktop, but culling is 0.2ms out of a 0.10ms total render time. The scene is empty! What is it culling? :)
     
    kalineh likes this.
  37. jmitcheson

    jmitcheson

    Joined:
    Oct 21, 2016
    Posts:
    96
    Also aside from bug numbers and patches, just in general it would be really good to have more technical information on culling

    • Separate occlusion and frustum culling in profiler?
    • Allow to disable frustum culling
    • Detail theoretical frustum culling performance in big-O notation (I'm not sure if disabled gameobjects are supposed to reduce culling time)

    Thanks
     
    kalineh likes this.
  38. vonbetelgeuse

    vonbetelgeuse

    Joined:
    Aug 28, 2014
    Posts:
    126
    I really wish Google would put the effort in to give clear concise instruction in terms of build settings, there aren't that many Daydream phones to narrow down the optimum settings...
     
  39. roundham

    roundham

    Joined:
    Oct 28, 2014
    Posts:
    46
    I cannot get antialiasing to work for me on daydream. I tried doing 2x msaa, 4x, even 8x and changed to 24 bit depth format. No change. Is there anything else Im missing?
     
  40. riazuddinjeelani8621

    riazuddinjeelani8621

    Joined:
    Nov 1, 2018
    Posts:
    1
    Hi all,

    I am new to this community, and I need some help choosing the right headset

    I have been in a dilemma which headset to choose between VIVE Pro or Oculus Daydream, I did read some reviews about best VR headsets on https://focusonvr.com/

    But, I would like some advice from people who use above mentioned brands.

    Your input will be much appreciated.

    Thank you kindly
     
  41. Claytonious

    Claytonious

    Joined:
    Feb 16, 2009
    Posts:
    571
    You should start a new forum thread for this question instead of replying to this thread, which is about project settings.
     
  42. ROBYER1

    ROBYER1

    Joined:
    Oct 9, 2015
    Posts:
    176
    Is the LWRP-VR pipeline recommended for Daydream yet? Would imagine there are performance gains from that
     
  43. nirharpaz3d

    nirharpaz3d

    Joined:
    Apr 30, 2019
    Posts:
    3
    With the new devices (like lenovo mirage), are the recomendations by Tuitive and Thep3000 still are the recommended settings?

    • Enable 2x Anti Aliasing. (Unity will issue a warning about performance when you build, but it performs fine and looks bad without it.)
    • Disable real time shadows. (They look bad and kill performance.)
    • Disable "Use 32-bit Display Buffer"
    • Stick with Forward or Vertex rendering
    • Enable Multithreaded Rendering
    • Enable Static and Dynamic batching
    • sync should be disabled -- each VR SDK has its own mechanism of synchronizing with the display and ignore vsync. With daydream vsync and setting Application.targetFrameRate actually _do_ work, but in general it is only recommended if you need to throttle your framerate lower and rely on reprojection.
    • 32-bit display buffer utilizes more bandwidth which is probably the most expensive thing for mobile VR in terms of power / heat, so it is recommended that you use 16-bit if you can get away with it. Same with depth buffer (there is a setting in the daydream dropdown in player settings VR list).
    • Multi-threaded rendering is absolutely recommended, this will free up time on the cpu main thread which is the bottleneck most mobile games will see first.
    • Graphics Jobs: case-by-case. Experiment with them and see if they help. I'm not entirely sure if there is a huge benefit on mobile.
    also what about supersampling
     
    ROBYER1 and jumasudo like this.
  44. jumasudo

    jumasudo

    Joined:
    May 21, 2019
    Posts:
    5
    I would like to get some feedback for those who are developing on the lenovo Mirage if possible , Thank you
     
  45. zforest

    zforest

    Joined:
    Feb 24, 2019
    Posts:
    1
    I'm developing on Mirage and porting a desktop complex scene to it.

    Anti-aliasing has little effect. Turned on both AA in post processing and in render settings. Still bad with many jagged lines

    I turned off vsync but even for a scene with just a textured ground plane, I get vsync related while profiling.

    I get flashes of checkerboard pattern a lot. Perhaps it's the GPU unable to catchup? How to do you profile the GPU?