With 5.7 deprecating the use of clustered deferred shading and that feature being left more or less unsupported in 5.8 and onward, what would be the suggested alternative?
Megalight seems to require raytracing (either hardware, or using distance fields) and will not work if the project does not have raytracing enabled. (and seems fundamentally stochastic)
The “legacy” deferred path can be way too slow depending on the scene (we observe a pretty big difference between the two in some scenes).
For context, we use VSMs (and have some geometry that is absolutely not ray-tracing friendly) and have scenes with a few lights (not too many, and they are localized very few overlaps). We also have a pre-filter pass for the VSM, meaning we can bypass the “shadow projection” part of the light pipeline for most lights.
Clustered Deferred Shading was ideal in our specific case, so seeing it deprecated I was wondering what was replacing it.
The long and short of it is that we have never observed this benefit that you describe - the clustered path has never been something we use in any internal projects. So it is very rot-prone and pure overhead.
So I guess I’m surprised you are seeing this perf difference. I’m not sure what the pre-pass you are talking about is - sounds similar to the one-pass VSM projection we already have?
Basically, with VSM we removed a number of the previous really obnoxious barriers, so unless you use some feature that push you back into the barrier-between-every-light it is generally faster with traditional deferred & we have improved batching further recently with light function atlases and whatnot. IT would be good if you can zero in a bit more on where the perf improvement is actually coming from - is it barriers between lights (my main suspect)? If so, what causes them?
Basically, from what you describe - not many overlaps, not very many lights - I don’t see where clustered would win vs the more precise bounds of traditional. The key win is in reading the gbuffer once, but that is not really important if there is not a lot of light overdraw plus it tends to be much worse occupancy making the light pass worse on a per light basis.
I’ve looked into it a bit more and discovered that the problematic lights were flagged as “static”, and static lights in editor have a preview shadow indicator which force them to have a shadow-projection-on-opaque pass right before them.
The difference of cost is mainly this. After a `ShowFlag.PreviewShadowsIndicator 0`, the difference between the clustered and traditional lighting is insignificant.
Builds do not have this issue.
AFAIK, with VSM and no light-maps/baked shadow-maps, there is no difference between a static light and a stationary one, and the shadow preview indicator is non-applicable.
That makes sense, since it’s an editor only feature we would not have bothered trying to make it batchable.
Perf measured in the editor is never going to be particularly representative.
That the indicator breaks batching when VSM is enabled sounds like a bug & could not find a ticket for it but I’m submitting a fix since it is trivial.