Per pixel / unified lighting model

[ShePearl]

I remember when DOOM 3 was launched back in 2004.
John Carmack highlighted per pixel and unified lighting model in IdTech 4 engine used in DOOM 3.

Now, it's been almost 10 years now since the engine/game was released.

How far have we come from then?

Unreal Engine 3.x, CryENGINE 2 and 3 (for Crysis 1, 2 & 3), X-Ray engine (for Stalker), Frostbite 2 engine (for Battlefield 3) to name a few. Do they now all support per pixel lighting and unified lighting/shadowing system ??
Also, what engine does Dead Space 2 use? Last time I checked, lighting & shadowing looked very, very good. (Is this another example of per pixel lighting & unified lighting shadowing system?)

 

[Sycraft]

Most engines these days are per pixel lighting, I can't think of any major ones that are vertex based anymore. We have the power and it looks a lot better. In terms of "unified" by which I guess you mean "everything has an in-game light source" no, nothing does that because they'd rather look good.

Doom 3 was overly dark not just because of style choices, but because it is all the lighting setup would really allow for. It lacks any sort of global illumination or radiosity or anything. So a light source can cast a light that bounces from a surface to the camera, but not one that can bounce from surface to surface. That means all shadows are very hard, and very dark.

We don't have the computer power to accurately simulate real light physics with radiosity and caustics and so on in realtime. So we have to fake it or simplify it. Doom 3 simplified it and what you got was something really dark.

That style doesn't work for most games, and doesn't look particularly realistic, and so other engines do things different.

If you want to know about BF3's rendering engine, one of the leads gives a big talk on the tech involved.

 

[socK]

Doom 3 is probably a pretty good example of where traditional forward rendering can begin to fall flat in regards to performance scaling. The lighting can become excessively heavy performance wise because of the sheer number of passes it can potentially take for the end all result to converge.

The results are additively composed (put colored lights together and they'll mix as expected). For each light hitting that given chunk of geometry, it effectively ends up being redrawn. Even if it's a tiny light, you're potentially dealing with a nasty overhead. This would only be exasperated by making the light radius even larger. That's one of the things deferred lighting / shading tries to solve -- effectively decoupling the lighting pass from geometry. You dump all the information you need into a (potentially large) buffer of data and use that to resolve your lighting in a way that's more closely related to a post process. Then you're (ideally) paying for what you use in terms of screen space -- only the pixels you light. One problem with deferred shading was that it's potentially bandwidth / memory heavy (especially with MSAA). The practical result of this was that there was a heavy "initial" load, so depending on the scene, it could of went either way. Nothing really interesting going on? Maybe you'd be losing performance. 50+ lights all over the place? Probably no comparison.

Shadows are another story. Doom 3 used stencil shadows, notorious for being razor sharp among other things (and they've since been more or less forgotten about, shadow maps are the hotness and probably will stay so for a while). They're an entirely different can of worms, but you're also redrawing geometry for shadows and they can become expensive quick if you have a lot of shadow casting lights.

Then you get into 1293812x variations and mutations of the techniques...


Fast forward to now, realtime GI is now feasible (and at reasonable quality). Not too many more holy grails to go, just refinement... less hacks and more proper as power continues to go up.

 

[ShePearl]

IdTech 5 engine used in RAGE, is this deferred renderer or forward renderer ?

How about Dead Space 2 (and 3) ? This is definitely deferred renderer, right?

 

[wonderfield]

Tech 5, in terms of the Rage implementation, has a forward renderer. It's actually very traditional, Quake-era technology in many respects, with the notable inclusion of virtualized surface data. The virtualization system is extremely complicated, but the core rendering pipeline, when the GPU has its final texture data to chew on, is relatively straightforward.

With regards to unified lighting and shadowing, it was an interesting direction to take, but not viable for a very wide range of scenarios. It worked well for Doom's dark, cramped environments, but it starts to fall apart as geometry increases and as lighting complexity increases. As pointed out by others, approximations tend to pay out better in rasterization, so that's what most graphics developers tend to suffer over.