In the 5.4.0b1 thread it was mentioned that future betas would include “VR Performance Optimization”.
Is there any word on what the VR optimizations are? And how big a performance impact we are likely to see? I have a VR project that could really benefit from some engine side optimizations so it’d be great to know what we can expect!
Hi Jon
Currently when Unity performs a render from a VR enabled camera in Unity it will internally perform one set of culling and then in turn render the left eye and then the right eye. The optimizations we are working on internally at the moment move most of Unity over to performing only one rendering pass that will render to both eyes at the same time. This packs both eye targets into one double wide target and when it gets to Unity’s render thread we will at the last possible moment double up the render call again binding appropriate matrices and setting up the viewport to render to the correct half of the double wide target for each eye.
If you look at your current VR project in the Unity profiler you should see that on the Main Thread each camera (“Camera.Render”) that is enabled for VR will generate two sets of “Drawing” markers one for each eye. The second of those markers should go away with the optimizations enabled so reducing the VR “Drawing” time by 50%. We are also seeing a large reduction in the time spent on the GfxWorker Render Thread as a result of this optimizations as well.
Currently we are targeting Oculus Rift and PlayStation VR with this round of optimizations, we’ll be looking into optimizations for GearVR a little further down the line.
Hope this is of some use.
Robin
Thanks for the detailed post! That sounds fantastic and will be a huge benefit to my projects (the dual ‘drawing’ calls are the biggest perf impact for me). Really looking forward to seeing this feature come online 
Are there any plan to support the Multi resolution rendering system from Nvidia? and their SLI system to render one eye per frame. It seems like that would fit good with the work you are doing using only one render pass for both eyes.
This is excellent to hear @robinb-u3d . Any idea on when this is going to be available?
What great news. Very promising indeed.
Any support for Native Cardboard in the near future?
Are these performance optimizations designed in a way that will make it possible to also have them in 3rd party packages, like e.g. the SteamVR Unity Plugin?
Does it reduce the Draw Call to half?
Are these the optimizations you meant - now in Beta 5.4.0B5:
“VR: Optimized Single-Pass Stereo Rendering available in Player settings”
Could somebody please try / compare it and share the results here ?
I guess we don’t get an answer to our questions…
Well, I’m very happy about these news:
Valve brings SteamVR to the Unity Technologies Platform
So now the question is just: When and how? 
Hey all!
Check out Joachim’s part of the Vision Summit 2016 Keynote, starting from 41:26. But if you want the improvements to rendering summed up in one image:
Yes, this was announced in the keynote video, above. No timescale given just yet, however.
The double-wide work will only be available for integrated VR solutions, not plugin ones. As you’ve already noticed though, integrated support for Vive will be coming in the future.
Currently, the number of draw calls on the render thread will remain the same, but have been heavily optimised which should reduce render thread overhead.
Initial work is now available in 5.4.0b5, see “VR: Optimized Single-Pass Stereo Rendering available in Player settings” in the release notes, however 5.4.0b6 is the version that the above data was captured from. Work is continuing on this right now, and will see further improvements and optimisations throughout the 5.4 beta and release cycle.
Hi Sam,
What is the normal time frame for beta releases, how long until we can try b6 out?
yes, I would love to know this as well, this is great news!
Typically we’ve been seeing betas every 1 - 2 weeks so I’d imagine we’ll have it pretty soon.
By the way, big fan of Lunar Flight, your latest updates look great
As @JonDadley said, our beta release cycle means we usually have a new release every week, although this can sometimes take longer if we’ve encountered some issues that we deem too severe to allow the release to go live straight away.
You can expect Valve support added during the 5.4 Beta period but we don’t have a specific date of which beta drop it will be added in. There are still a few logistics to work out to align updates to Valves existing asset store plugin to ensure a smooth transition.
That is very great news! As I am also developing for PlayStation VR, I cannot jump into 5.4 beta too early, anyways (unless some magic happens) but almost certainly will as soon as this is ready (primary platform ATM is HTC Vive, we expect PlayStation VR to be released after HTC Vive, so that’s why we primarily focus on the later).
I know I’ve been bugging you since the alphas … but … just to be sure: Will we keep the TrackedObject components when using the SteamVR plugin? Or even better: Could we finally have native VR support in general done with a component-based approach instead of (just) “checking Virtual Reality Supported”?
A very significant part of Unity’s awesomeness is in its component-based approach and especially for locally social VR games but also from a software-engineering perspective, adding “TrackedObject” and “HmdCamera” components to a camera that should be controlled by tracking and rendered to VR would be very much preferable to a checkbox in the player settings changing the behaviour of every camera (and having no way to disable built-in tracking, for example, to replace it with custom tracking … or have a tracked camera render to a normal monitor instead of the HMD … or have a camera tracked with a controller render to the social screen … and so on ).
Also, why was the functionality that tracked cameras base their tracking on zero changed (I missed that change because I wasn’t using the native VR integration until recently)? If you really need a camera with an offset in position and or rotation, you can always parent it with an object that does this … but there’s quite a few cases where you’ll want the camera to have some position / rotation when not in VR that should be zeroed when in VR.
This optimization apply for google cardboard also?