I’ve heard that deferred rendering offers advantages in scenes with a lot of lights.
I’m wondering how this works with normal mapping.
Could I have several normal mapped characters in a scene, each with their own pixel lights? Or is it mainly for stationary lights?
Normal mapping is supported, because in deferred rendering it renders the normals to an image, and then renders the lights based on that. It’s just a matter of transforming those per-pixel normals to match your normal maps. So yes, normal mapping would work just as expected in real time.
Overall, deferred “just works” with normal mapping.
Where it does not work that well, is if you want your characters to have “their own set of lights”. That is, in deferred rendering, lighting happens “on the screen”, where it does not know what objects are there anymore. Which makes it hard or impossible to use different sets of lights on different objects.
That said, quite a lot of character specific lighting variation usually is just written in the shader. E.g. rim lighting, hemisphere lighting etc. - those are usually just hardcoded in the shader, and do not use any “real actual” lights.
Now that I think of it, the main reason we tend to give characters their own specific lights has been because of performance issues.
So, with deferred rendering, I should be able to have multiple normal mapped characters on screen with pixel lights set to light the entire environment. Is that correct? And the performance should be the same whether it’s one or twenty lights?
Like always, depends on a lot of things. Complexity of your environment, your characters, your target hardware, shaders, target resolution and so on.
Lights are never free. Whatever way they are computed, something needs to be computed that result in realtime lighting, and doing anything is never “free”.
In deferred rendering, lighting cost is mostly based on the number of pixels on screen that the light touches. So lots of very small point lights = quite cheap. Lots of directional lights (that by definition touch the whole screen) = quite expensive. However, lighting cost is mostly independent of scene complexity; it does not matter how many or how complex objects the light affects; it’s cost is only the number of pixels it shines on.
In comparison, in forward rendering (at least the way it’s implemented in Unity 2.x) - lighting cost is the number complexity of objects a light touches, and the size of those objects on screen.