"Best Practice" Project Settings for Daydream?

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!

 

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.

 

Thanks for the concrete advice, @Tuitive and @thep3000!

 

What about IL2CPP?

 

thanks for the tips, this thread should be stickied!

 

Yeah, performance boost from 30 to 60fps thank you!

 

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.

 

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.

 

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.

 

Out of interest what are you guys approx triangle budgets for Daydream? i.e. total triangles in stereo render (2x monocam in editor).

 

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.

 

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.

 

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.

 

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.

 

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.

 

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

 

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).

 

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.

 

Really? Do you know which phones?

 

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?

 

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

 

@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.

 

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.

 

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.

 

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.

 

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?

 

Aren't they all specced as Qualcomm Adreno 500 series? I took the implication to be that which was faster depended on the application.

 

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

 

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.

 

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)

 

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.

 

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):

 

Empty default scene, Unity 5.6.1f1



Taken from desktop, but culling is 0.2ms out of a 0.10ms total render time. The scene is empty! What is it culling?

 

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

 

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...

 

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?

 

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

 

You should start a new forum thread for this question instead of replying to this thread, which is about project settings.

 

Is the LWRP-VR pipeline recommended for Daydream yet? Would imagine there are performance gains from that

 

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

 

I would like to get some feedback for those who are developing on the lenovo Mirage if possible , Thank you

 

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?