So pre PBS (legacy deferred) you could do all the lighting tricks you wanted like doing wrap-lighting - as mentioned here: Unity - Manual: Surface Shader lighting examples
But that section seems fairly pointless now, as is for forward only and not URP/HDRP
Can you achieve that wrap-lighting effect (or other lighting customisation effects) in any deferred modes - built-in/URP/HDRP?
Or is the lighting code simply locked away from any customisation now?
One downside of SRP is that you can’t replace the deferred shader through the Graphics Settings menu anymore.
You can however, create a local copy of the URP/HDRP package and modify everything as you see fit.
Yes that is true - though seems like a drastic move!
The move to super-realism is all very well, but sometimes you just want to more stylised art!
It seems you can modify some lighting code though: Custom Lighting in URP with Shader Graph – Bronson Zgeb
not sure for built-in deferred
That example isn’t using deferred rendering. The URP defaults to forward rendering, and the URP’s deferred renderer is quite recent and entirely optional. However any attempt at custom shading with deferred enabled will result either in that shader not working at all, or falling back to forward rendering.
As a side note, Unity’s legacy deferred renderer from the Unity 4.0 days also didn’t support custom shading models. If you used one, it simply fell back to using forward rendering for that shader. Which is also how custom shading models work in Unity 5.0. Because deferred renderers do not support custom shading models! The whole point of deferred rendering is it divorces the lighting & shading from the per-object shader. So anything that doesn’t use the shading model supported by the deferred rendering pipeline ends up rendering using forward rendering. This includes all transparent objects as deferred cannot support transparency, so all “deferred” renderers are actually hybrid deferred / forward renderers.
For the built in renderer you can easily replace the shader used by the deferred rendering path, as @StaggartCreations mentioned. There are even existing assets on the store that do this, like Lux, Alloy, and Uber. Uber does this in a way that’s backwards compatible with existing Unity shaders, while Lux and Alloy require using their custom shaders on all objects in the scene.
The short version of how Uber works comes down to how Unity’s deferred renderer packs its gbuffers. Specifically there’s one gbuffer with one 2 bit channel that is unused and which Unity’s built in shaders always render a zero to. So Uber (and some other shaders out there) override the deferred shader to look at that unused channel, and change the lighting model if it’s not zero. Sometimes going as far as to completely change how the values in the rest of the gbuffers are used. You could do something similar.
However there is one big caveat to be aware of. The way Unity’s shadows work usually defeat any attempt at wrap lighting as they’re designed to reduce “peter pan” artifacts in shadow maps, as well as ensure self shadowing works as well as it can. That self shadowing usually results in back faces that you want wrap lighting to appear on getting shadowed immediately. So instead of getting nice wrap lighting you get a nasty jagged shadow edge.
Well you can write your own surface shaders with legacy deferred and wrap lighting worked fine for me & I think no shadow issues. However I can’t see where final pass code is…
Yes my mistake regards URP, forward may be a valid alternative if handles many lights…
Wrap lighting could well be rather defeated by shadow issues, but those shader assets sound interesting for experiments