If you’ve done any VR development, one of the key things you should know is that FRAMERATE is crucial! Get ready to learn how the Lab Renderer can help you keep that framerate high.
Even if you have the most entertaining, exciting, innovative, other adjective game, if you can’t stay over the target frame rate consistently, your game will suck.
If you’re working in Unity, my original recommendation would have been to keep your vertex count low, bake as much lighting as possible, and limit yourself to 1 or 2 real-time lights where they really give a big payoff.
A few weeks ago though, Valve did something amazing and released their custom renderer for VR as a Unity plugin.
As the name implies, this is what they used to build the VR title “The Lab“, and I’d say was integral in making it look as nice as it does.
The Lab Renderer
The description on the asset store page doesn’t do it justice though, so I want to cover the performance gains I’ve seen by switching to this plugin for VR projects.
Real Time Lighting
With Unity in a typical VR game, most lighting is baked. In fact, most games in general use quite a bit of light baking.
If you don’t know the difference yet between baked and real time lighting, I’d recommend you give this article a read:
It’s long but worth your time.
The reason most lighting is baked though is purely for performance. Ideally, given unlimited performance, real time lighting for everything would be great. With the lab renderer, you get much closer to this.
In my previous VR games and experiments, I’d come to accept a limit of 1-3 real time lights being active at a time.
The lab renderer however supports up to 18 real time lights with little to no performance hit.
In my most recent VR game Armed Against the Undead, prior to switching to the Lab Renderer, I couldn’t have more than 1 real-time light enabled at a time without my FPS dipping below 90.
When using baked lighting, I was stuck waiting for light baking every time there was a change, in some cases waiting for 15-60 minutes, which as you can imagine can completely break the flow of work.
Once I made the switch, I was able to immediately turn off all baking, enable many more lights, and even make the lights all destructible!
This comes straight from the Lab Renderer page, because I don’t think I could state it better…. but essentially, you get fast MSAA
Single-Pass Forward Rendering and MSAA
Forward rendering is critical for VR, because it enables applications to use MSAA which is the best known anti-aliasing method for VR. Deferred renderers suffer from aliasing issues due to the current state of the art in image-space anti-aliasing algorithms.
Unity’s default forward renderer is multi-pass where geometry is rendered an additional time for each runtime spotlight or point light that lights each object. The Lab’s renderer supports up to 18 dynamic, shadowing lights in a single forward pass.
The key reason you should look into using the Lab Renderer is FPS.
In my experience, the FPS gain from the lab renderer is around 50%. This could of course vary drastically from project to project, but the difference I’ve seen is huge.
For Armed Against the Undead, the FPS gain is enough to take the game well over 100fps on an NVidia 970.
To demonstrate the difference, I’ve copied the existing project and built a side by side comparison of the game using both the standard and lab renderers.
I’ve added screenshots of both, so you can see there’s no real difference visually, but the FPS gain is huge. I’ll let the screen shots speak for themselves..
The Standard Shot
The Lab Shot
While the Lab Renderer offers some great performance gains, there are a few downsides that you need to take into account before making the switch. Some things just aren’t supported yet, and I don’t know when / if that will change.
To take advantage of the Lab Renderer, you need to use the “Valve/VR_Standard” shader. If you have your own custom shaders, this may be an issue. If your project is all setup with legacy shaders, you’ll need to manually convert them and make your assets look right again. While I haven’t had a hard time doing this, I have to admit I’m not an artist and ‘close enough’ works fine for me. But if you’re very picky about the art, this may be an extra time sink or in some cases a breaking change. That said, if you’re using the standard shader for everything, the conversion is practically automatic and works great.
In addition to this, your general full screen shaders won’t work either. If you have special full screen shaders you really need, you may be able to figure out a way to get them working, but in my experience none have worked so far.
The unity terrain uses it’s own shaders, not the standard shader. From what I’ve seen so far, there isn’t an easy way to make the lab renderer work right with terrains. There are of course tools that convert terrains to meshes, and if you already have one that you like, that may be a good solution. If your project makes heavy use of the Unity terrain system though, and you can’t easily swap that out, the Lab Renderer may not be right for it.
So now that you know the benefits, and can accept the drawbacks, it’s time to start implementing.
Luckily, doing this is easy and only takes a minute.
Commit your current project to source control!
If something goes wrong, or you find a drawback/issue you didn’t expect, you’ll want an easy way to revert.
If you’re not using any source control, read my article on Git and set it up before you do the conversion. It will only take you 15 minutes and will prevent a ton of pain going forward.
Find your camera and add the “Valve Camera” script to it.
If you’re using the [CameraRig] prefab from the SteamVR Plugin, add this to the the (eye) not the (head)
Shadows are handled by the lab renderer, so you need to disable the built in system. When you want to adjust shadow settings, look at the “Valve Camera” script you added above.
In your project settings, you need to turn off shadows. To do this, open Edit->Project Settings->Quality
Update your materials to use the new shader
This will convert all of your materials using the Standard shader over to use the “Valve/VR_Standard shader“, and could take a while if you have a large # of them.
Optionally, you can use “Convert All Materials to Valve shaders”, that will find everything in your project, not just your open scene. I recommend the Active ones first because it’s usually a lot faster and will give you a good idea of how things are going to run. If your system is fast though, just select the All option from the start so you don’t need to do it later.
Setup your Lights
Find all of your lights that you want to be realtime (In my case that was all of them), and add the “Valve Realtime Light” script to them.
When you add this, take a look a the options available. You may not need to modify anything right now, but it’s good to know what you can do with them.
After you’re setup and running, you may find your performance isn’t as high as you expect. This could be caused by some materials not being correct.
The automatic update of materials works great to catch things using the standard shader, but if you had some legacy ones you missed/forgot, they could be causing less than optimal performance.
Luckily, Valve already thought of this and added some helper options to the “Valve Camera” script.
Everything using the correct shader will disappear and only things that still need to be updated will be visible.
Swap those over to the “VR Shader” and check your performance again.
My final recommendation is to start using the lab renderer today. Don’t wait until your project is complete as the task will become much more difficult.
If you start early, you can tune your game for the performance available, and avoid the pitfalls of using something that’s incompatible.
If you want to learn more about the Lab Renderer, you can check out the steam forum here: http://steamcommunity.com/app/358720/discussions/0/
And if you have any feedback or tips you’d like to share, please comment or email me.