I was curious to see what deferred shading could do, so I put together a very basic demo scene. It is a simple hallway with 50 point lights bouncing around in it. I get from 30-60 FPS on my machine when standing at one end of the hallway and looking down the length of it.
The scene geometry is about as simple as you can get. Six planes make up the walls, and a bunch of cylinders make up the columns. The simple geometry may be giving a deceptive idea of how fast deferred shading can run.
On the other hand I am using point lights with soft shadows, which are supposed to be the most expensive.
On the other other hand, the point lights have small radius, and thus most pixels in the scene are only being hit by one or two lights at a time. The small radius means that the deferred shader is running the lighting logic for each light over only a small area of the scene.
There is some simple specular bumpmapping applied to the walls, ceiling, and columns to better highlight the light movement.
Deferred Rendering is largely a post process. This means that it is done relative only to the pixels rendered on screen. This means that adding increasingly complex geometry does not increase the complexity/time of the lighting calculations.
It also means that the size of the lights does not affect performance greatly either as the lighting is done once per screen pixel, not per triangle pixel.
Dynamic shadows however are very expensive, and a fantastic framerate for 50 dynamically shadowed lights.
I agree with you somewhat about scene complexity. That is the great benefit of deferred shading – you only get charged for lighting calculations on the pixels that are visible. Whereas, with forward rendering, it performs the lighting calculation even on hidden/overdrawn geom.
But the dynamic shadows, as you said, are the expensive part. If I am reading the docs right, real time shadows are definitely affected by scene complexity. It says, “Of course, lights with shadows are much more expensive than lights without shadows. In Deferred Lighting, shadow casters still need to be rendered once or more for each shadow-casting light. And the lighting shader that applies shadows is also more expensive than one without shadows.” This makes me suspect that if you have a really complex scene there can be a lot of polygons that have to be rendered to generate the shadow casters. In this demo the poly count is so low that shadows do not cost much at all.
An easy test would be to substitute some ridiculously high poly count cylinders (say 10,000 to 100,000 each) in place of the ones I am using now, while keeping their radius the same. Screen size in pixels would remain constant, but the cost of shadow casting would go up.
The size of light coverage area on screen must have some affect on framerate. Since lights are applied as a screen space pass, the more pixels the light area covers the more calculations that have to be done. The docs say, “Cost of realtime lights in Deferred Lighting is proportional to number of pixels the light shines on; and not dependent on scene complexity. So small point or spot lights are very cheap to render. Point or spot lights that are fully or partially occluded by some scene objects get their pixels skipped on the GPU, so they are even more cheaper.”
Since the point lights in my scene have small radii, they are relatively cheap. A test I need to do is double or triple the light radius and see how it affects framerate.
Yes, every point light in the scene is casting a real-time shadow.
I’ve seen some discussion on other threads about shadow quality. I think Aras said that shadows are roughly the same quality in deferred shading mode, but have been sped up some. However, he said that forward shading shadow quality wasn’t as good, or at least as flexible, as it used to be.
Here are some quotes from the “Unity 3 beta preview” thread:
aNTeNNa trEE said, “The overhead for realtime shadows does not go away with deferred rendering.”
Aras said, "…I’ve greatly reduced “black shadow rings” from Point light shadows (which were mostly happening on Macs), but I think the fix did not go into the public beta yet. "
Aras said, “You do realize that point light shadows are like the most performance-killing shadows ever? That is, in no way they are “even simple point light shadows”… they kill performance. I think probably 90% of high end games do not have point light shadows at all. Unreal Engine 3 recently dropped support for them completely. For the same reason - they are horribly expensive. In Unity we do support point light shadows, but don’t have soft shadows on them because of performance reasons.”
Aras said, “Forward rendering supports shadows from one directional light in 3.0.” Yikes!!! That is going to hurt.
Aras said, “It used to support shadows from ALL lights…
…
That is true, but in forward rendering, any shadowing options explode shader permutation count; and having shadows from spot/point lights is not very practical in 99% of the use cases. We wanted to make shaders smaller, simplify the rendering code and make it faster for those 99% of the cases. Yes, it does sacrifice shadows for that use case when you want point/spot light shadows in forward rendering, and that’s a tradeoff we made.
…
I was talking about forward rendering only. Deferred rendering has all the old shadowing options of Unity 2.x, with some improvements to both speed quality.”
“Forward rendering supports shadows from one directional light in 3.0.” From this and the rest it sounds like they pretty much force you to use deferred rendering by imposing these limitations.
I wonder, is there really a reason not to use deferred shading?
2 is less of a concern, but no anti-aliasing sounds like an unpleasant surprise. Does it mean that there’s absolutely no anti-aliasing going on (up to removing the feature from the Quality settings), or is it just “limited” in what it can do?
Did you try enabling antialiasing on the demo to see if it does anything at all?
I fear thats no surprise, thats standard for deferred rendering defacto that hardware / driver AA ceases to work
In this case it means that it is technically not possible for the hardware to do AA as deferred shading does not render geometry the normal way anymore. instead it renders various distinct types of data to buffer textures which are then processed and combined and for texture operations there is just no AA.
Its something that shaders must take care of. the edge blur way to get some form of antialiasing.
And no its not taken out of the quality settings but they neither have any impact unless you write a script shader that use them to perform AA through shader
The good news about AA with deferred rendering, IMO, is that this is hardly a Unity limitation, everyone deals with it. The best looking games are using deferred rendering with same limitations, and people clearly don’t mind much. In the end, the highest contrast areas where AA would matter most are likely to be helped a bit with bloom or other edge masking post processing effects.
And there are other tricks, as dreamora mentioned, but in the end hardware AA is not a big deal to lose these days, especially with the resolutions people are running.
Yea, but AFAIK ATI’s stuff is just to handle AA to HDR buffers, not deferred rendering. Standard AA techniques break when dealing with deferred since lighting terms (mainly normals and depth), can’t just be interpolated and produce good results, so any AA technique that just produced the deferred surfaces with one source pixel per screen pixel wouldn’t be able to the trick. The MS interpolation would need to be done after lighting is complete. I remember some talks about the hardware handling that on edge pixels, but I don’t know if it’s actually doable now, I didn’t look into that much. I’m not sure how it could do it without requiring a special context identification for the lighting pass shader.
I’m not fully sure on which buffers are AAed and which not, I’m on NVIDIA and the only way I will ever have an ati in my system is nvidia going out of business
I just posted an update to the demo. I added a small GUI that allows you to change the radius of each point light, turn shadows on and off, and switch between deferred and forward rendering.
This makes it possible to compare the affects of these parameters on framerate.
Here are the results I get, standing at one end of the hallway, and looking down the length of the hall on a nVidia GeForce 9600M GT:
Method Light Range Shadows FPS
D 10 Y 50
D 10 N 80
D 50 Y 12
D 50 N 30
F 10 Y 130
F 10 N 140
F 50 Y 115
F 50 N 115
The first thing to notice is that in deferred shading, the range of the light, or better said, the on-screen coverage area of a light, significantly affects framerate. Going from range = 10 units to 50 units dropped framerate with shadows from 50 to 12 (Note, the hallway is around 250 units long). This is because at the larger range, each light is affecting more pixels, and has to handle more geometry when calculating shadow casters (because more columns fall within each lights radius).
Turning shadows off in deferred mode had a significant affect because of the cost of calculating the shadow casters.
In comparison, in forward shading mode, the light range had very little affect. And shadows had no significant affect. This is because in forward shading mode, there can be only a limited number of lights affecting each object. You can see this by looking at the floor or walls. Of the 50 lights only 4 lights affect the them. Unity automatically chooses the N number of lights which are closest to the object being rendered, and ignores the rest for that object. You can see this on the columns. Each one is lit by a different set of the 4 lights closest to each one.
So, in deferred mode, the on-screen size of a light is important, and the number of polys the light it has to render to create the shadow casters is also significant.
deferred will then be worse if many light pixels are on screen and many shadow pixels (with on screen I also mean visible to the user) and if only few lights are within the view frustum.
on the other hand with longer light ranges, an environment that will have various visual blockers, many lights and complex geometry, deferred should easily kill forward on any computer thats reasonable to be considered deferred rendering usage at all (DX10 / SM4 class hardware)
