koobas.hobune.stream
additional pass for each per pixel light in forward rendering
Why need additional draw call for each per pixel light in forward rendering? Why not just upload all lights information into constant buffer ,and loop through all of them in pixel shader and add up the result?
It seems UE is doing so. Any particular reason unity3d not doing forward in such a way?
Because that's how forward rendering works: it is more efficient for mobile devices, better at transparency, but more costly if you have a lot of per-pixel lights.
Note that UE4 does not support forward rendering - it only has a deferred rendering pipeline. If you want that behaviour, just switch Unity to deferred rendering mode :)
https://docs.unity3d.com/Manual/RenderingPaths.html
https://docs.unity3d.com/Manual/RenderTech-ForwardRendering.html
If having hundreds of thousands lights, it make sense to go for deferred lighting to pay the tax of fat gbuffer and no-$$anonymous$$SAA support. But with only few lights, forward is sure a better choice. $$anonymous$$y question is not about why using forward lighting, it is about why unity3d implement it in this way. One forwardbase(one pixel light, N vertex light, lightprobe, lightmap) + N forwardadd( per additional pixel lights). Is there any reason not done it in one pass by uploading light info into constant buffer as much as possible. Is there any kind of reason like, on mobile hardware one extra draw call doesn't cost that much than mapping data into constant buffer, or it is just we like to do so because it make the code easy to implement and maintain. :)
Good to know UE4 only support deferred lighting :). But from this forward lighting shader, https://github.com/EpicGames/UnrealEngine/blob/release/Engine/Shaders/BasePassForForwardShadingPixelShader.usf It looks like trying to not shade with only one light per draw.
I really am curious about why 'because that's how it works' that way, just like how deferred lighting is done in the engine, why still do point light and spot light as geometry, rather than go for tiled based deferred lighting. I think there may be some good reasons, like the engine supports a wide range of platform from very low end to high end, the choice is to be able to support as much as possible. :)
