I’m almost completely new to real-time 3D, so it’s likely some of my assumptions are completely wrong. Hopefully in that case, someone here with more knowledge can point out what I’m missing.
I’m evaluating using Valve’s Lab Renderer for my VR project. Because the Lab Renderer is unsupported and will not receive any updates from Valve, doing so means taking on its support and maintenance myself, and committing to implementing and maintaining any of its missing features as well.
If you forget about the adaptive rendering and GPU flushing features, the Lab Renderer has one primary optimization- its shader calculates pixel lighting for each light in a single pass using a loop in the fragment shader, as opposed to Unity’s default implementation that does an entire pass per geometry for each pixel light.
In order to achieve this, the Lab Renderer does quite a bit of calculation in managed code each frame to evaluate light frustums and so on and pass the light data as shader variables.
Outside of Unity, I gather that forward renderers commonly calculate lighting iteratively per geometry in a single pass already. So why doesn’t Unity? Given the performance cost, what is the advantage of adding another full pass for each pixel light instead of looping through the lights in each object’s fragment shader in the first place?
I would think that this optimization would be more performant if it was part of Unity’s native pipeline instead of being implemented as a ‘plugin’. So why isn’t it? Is it in the roadmap? Or, what am I missing / misunderstanding / completely wrong about in my statements above?
A small update to this- there are some answers to the “how and why” at this link, and my cursory interpretation is that the answer to “why doesn’t Unity already do this” is that it wasn’t feasible on older DirectX versions, and improvements are underway but with no guarantees or versions set for when they’ll be here.
I’m still very interested in replies or corrections though, from knowledgeable users or Unity staff!
Unity’s forward implementation is kinda old and they haven’t touched it in a while. AFAIK Unity has shown interest in some sort of Forward+ implementation, which will hopefully be much faster with lights.
Thanks for the reply AcidArrow! Just out of curiosity do you have any link to a statement about Unity’s plan for Forward+? That’s actually a step beyond simply moving to Single Pass Forward Lighting.
I’ll see if I can find it, but if I remember correctly, it wasn’t anything more than people asking for Forward+ and then some dev saying “we’ll consider it in the future”.
What Unity has already implemented in their Scriptable Render Loop (the current work for which is viewable here: https://github.com/Unity-Technologies/ScriptableRenderLoop ) is two different versions of what could be considered Forward+, Fine Pruned Tiled Lighting and Clustered Tiled Lighting, both of which can be used simultaneously (one is super fast for opaque geometry, the other is mainly for transparencies, but works on all types). They’re both mentioned in the doc you linked to.
The stuff the Lab Renderer does that you comment on as being “expensive” is the same kind of work Unity is doing behind the scenes for its own lighting existing system, and kind of what you do for any kind of general real time lighting system. Forward+ implementations are even more of this as it’s doing that kind of per light culling, but for maybe hundreds of individual regions instead of just against the one camera frustum. There are some entertaining comments in some papers about Forward+ implementations about making sure the cost of culling is less then the cost of just rendering.
Hey bgolus! You seem to understand the rendering pipeline really well. My understanding is that the ScriptableRenderLoop is being worked on but there’s no promise of it being in a full release product any time soon, right?
Here’s my real, naive, practical question…my app performs better with the Lab Renderer than without it, but I’m reluctant to commit to the Lab Renderer’s limitations and maintenance costs if I don’t have to. Since its only real optimization is moving all lighting calculations into a single pass…what’s the likelihood of Unity doing that natively in a release version in the next 4-6 months?
We can only hope right now. The built in Unity rendering pipeline is quite behind the rest of the industry when it comes to PC or console rendering, and is especially unfortunate for VR, but it works well on a wide range of devices. The scriptable rendering loop has a number of impressive features already implemented, and the technology is based on stuff already used in shipping AAA titles (not using Unity). Even if they never ship the stuff they’re working on officially, the fact that the API hooks are already in 5.6 mean it’s likely we’ll be seeing similar systems pop up on the asset store as full rendering pipeline replacements.
I know personally if they don’t end up shipping it I’ll be using those features myself.