
This is part of a series on how I approach game lighting, from a more general and conceptual perspective. I build most of my examples in Unity, but this is meant to be generally applicable to any 3D game engine, most of which have similar lighting tools.
We started by thinking about light from a cultural and conceptual lens in part one. In part two, we treated light more instrumentally in terms of level design and readability. Then in part three, we surveyed the three-point lighting method for use in games. But none of this theory matters if we can't actually achieve it within the semi-hard constraints of computer graphics.
Lighting is traditionally one of the slower or "expensive" things to calculate and render in a game engine. Consider the science of visible light: countless photons at different wavelengths bouncing around at unimaginable speeds that somehow enter your eye. To do any of this at a reasonable framerate, game engines must strategically simplify light calculations in specific ways, and then hope players don't notice the inconsistencies. It is "fridge logic" -- we want the player to nod along, as long as it "looks right."
Okay, so how do 3D game engines generally do lighting?