Deano Calver
Newcomer
Soon(ish) Beyond3D is going to host my article on Photorealistic Deferred Lighting.
Its worth a short introduction, the full article is quite heavy(almost 20 A4 pages with only 1 picture!). The basic idea is that rather then light in the vertex or pixel stage of object rendering, you render out the lighting parameters into a buffer (G-Buffer, as it stores geometrical details, position, normals etc) and then do lighting via rendering them while reading from the G-Buffer. The advantage is that the G-Buffer creation phase (basically the same as standard rendering systems) is detached from the lighting phase. So you can render lots of lights with no need to re-render the object (which mean high-poly) and as lighting is an image space operation lights are proportional to the amount of screen space they cover (so lights far away are cheap). Also one thing the paper explores, is the ability to use fast z-rejects for the lighting phase, so means lighting is truely proportional to what you can see.
It has issues (things like transparency, bandwidth and memory issues) and currently it only works on ATI R3x00 due to missing D3D support under GeforceFX, hopeful these issues will be solved but on ATI R3x00 it generates the G-Buffer in a single pass (by using MRT with four 4 channel 16 bit integer surfaces).
It only runs on a tiny fraction of video cards, so it will be years before its even remotely viable for games but its an interesting glimpse at one possibilty that next next generation engines might be using. Its requires FP24 or higher precision and really wants high precision render targets and multple render targets to really work well.
I'm currently going through the source code for the various samples (which go with it) and decided to take some screen shots.
Under each screen, I've written a bit to explain roughly what your meant to be looking at.
On important principle of Deferred Lighting is that everything is treated equally, this screen shot demostrates it perfectly. The back wall is lit in the same manner as the objects, so you can see a lovely local speclar highlight. Also the (single) shadow correctly casted and is received by all object (including self shadowing). You can also see (just about) 3 points lights (on top of the hemisphere ambient and the directional) affecting the floor and the objects.
A tighter camera shot of the objects, you can clearly see the 3 (o.k. blues's hidden) point lights (there actually spinning around the center teapot). There are no special effects on those lights, the shape is caused by the attenuation model being evaluated per-pixel on the floor surface. Also an important concept is that hidden lights (from the viewer) are VERY cheap, by using the Z rejection hardware the hidden blue point light (its behind the central teapot) costs almost no fill-rate. The strange egg thing is some strange lighting parameters, by fiddling with the lighting equation it has a light halo effect, just some weirdness I was playing with to demonstrate various materials. Each object has a different lighting material, different specular and diffuse materials. There very simple just for the demo, its trivial to change every parameter per-pixel (as the central teapot does).
Now focus on the teapot, as mentioned every parameters is changed per-pixel (via texutre maps). For deferred lighting, per-pixel normals is standard, so perturbing them for bump-mapping is easy. In this case the code fakes a bump map (its doesn't bother with 'correct' bump-mapping because I'm lazy
). As you can see the snake skin looking bump map effect diffuse and specular equally, with all lights surfaces equally effected. Also there are diffuse and specular texture maps, just to show off.
An older light model, this has two shadows and you can clearly see different specular exponents (the back teapot doesn't have sharp highlights). You can also see some back lighting tricks (the green donut appears to be lit from behind), and if you look closely at the back teapot you can see correct shadowing of specular.
Lots of lights, 15 points, 1 directional (with shadow) and a hemisphere ambient to be correct. Every lights effects everything. While frame-rate suffers, its visible pixels not number of lights that really affect things. In other words the more objects you add to the scene the faster it can get! Also the lighting hit is constant, the only cost of adding more objects/polygons is the cost of drawing them once (for ATI 9700), Objects are drawn once (with procedural models if you like) and can be lit by as many lights as you like, for a constant cost per lights (and the constant is determined by the number of visible pixels of the light from the viewer point of view).
Not sure why the JPEG went so wrong with this, I have it as a BMP but its over 1 meg. If you want to see it without the nasty artifacts just shout.
An earlier light model but with 2 shadows, that you can clearly see working correctly (highlights are correctly in shadow and mixing lights/shadows add correctly). Shadows use a 4 sample percentage closest filter. Cost is simple the cost of generating the shadow map (render all objects in the lights view) and then a few (for PCF used here its about 10 including 4 texture samples) instructions in the lights pass. Its really elegant.
Its worth a short introduction, the full article is quite heavy(almost 20 A4 pages with only 1 picture!). The basic idea is that rather then light in the vertex or pixel stage of object rendering, you render out the lighting parameters into a buffer (G-Buffer, as it stores geometrical details, position, normals etc) and then do lighting via rendering them while reading from the G-Buffer. The advantage is that the G-Buffer creation phase (basically the same as standard rendering systems) is detached from the lighting phase. So you can render lots of lights with no need to re-render the object (which mean high-poly) and as lighting is an image space operation lights are proportional to the amount of screen space they cover (so lights far away are cheap). Also one thing the paper explores, is the ability to use fast z-rejects for the lighting phase, so means lighting is truely proportional to what you can see.
It has issues (things like transparency, bandwidth and memory issues) and currently it only works on ATI R3x00 due to missing D3D support under GeforceFX, hopeful these issues will be solved but on ATI R3x00 it generates the G-Buffer in a single pass (by using MRT with four 4 channel 16 bit integer surfaces).
It only runs on a tiny fraction of video cards, so it will be years before its even remotely viable for games but its an interesting glimpse at one possibilty that next next generation engines might be using. Its requires FP24 or higher precision and really wants high precision render targets and multple render targets to really work well.
I'm currently going through the source code for the various samples (which go with it) and decided to take some screen shots.
Under each screen, I've written a bit to explain roughly what your meant to be looking at.
On important principle of Deferred Lighting is that everything is treated equally, this screen shot demostrates it perfectly. The back wall is lit in the same manner as the objects, so you can see a lovely local speclar highlight. Also the (single) shadow correctly casted and is received by all object (including self shadowing). You can also see (just about) 3 points lights (on top of the hemisphere ambient and the directional) affecting the floor and the objects.
A tighter camera shot of the objects, you can clearly see the 3 (o.k. blues's hidden) point lights (there actually spinning around the center teapot). There are no special effects on those lights, the shape is caused by the attenuation model being evaluated per-pixel on the floor surface. Also an important concept is that hidden lights (from the viewer) are VERY cheap, by using the Z rejection hardware the hidden blue point light (its behind the central teapot) costs almost no fill-rate. The strange egg thing is some strange lighting parameters, by fiddling with the lighting equation it has a light halo effect, just some weirdness I was playing with to demonstrate various materials. Each object has a different lighting material, different specular and diffuse materials. There very simple just for the demo, its trivial to change every parameter per-pixel (as the central teapot does).
Now focus on the teapot, as mentioned every parameters is changed per-pixel (via texutre maps). For deferred lighting, per-pixel normals is standard, so perturbing them for bump-mapping is easy. In this case the code fakes a bump map (its doesn't bother with 'correct' bump-mapping because I'm lazy
). As you can see the snake skin looking bump map effect diffuse and specular equally, with all lights surfaces equally effected. Also there are diffuse and specular texture maps, just to show off.
An older light model, this has two shadows and you can clearly see different specular exponents (the back teapot doesn't have sharp highlights). You can also see some back lighting tricks (the green donut appears to be lit from behind), and if you look closely at the back teapot you can see correct shadowing of specular.
Lots of lights, 15 points, 1 directional (with shadow) and a hemisphere ambient to be correct. Every lights effects everything. While frame-rate suffers, its visible pixels not number of lights that really affect things. In other words the more objects you add to the scene the faster it can get! Also the lighting hit is constant, the only cost of adding more objects/polygons is the cost of drawing them once (for ATI 9700), Objects are drawn once (with procedural models if you like) and can be lit by as many lights as you like, for a constant cost per lights (and the constant is determined by the number of visible pixels of the light from the viewer point of view).
Not sure why the JPEG went so wrong with this, I have it as a BMP but its over 1 meg. If you want to see it without the nasty artifacts just shout.
An earlier light model but with 2 shadows, that you can clearly see working correctly (highlights are correctly in shadow and mixing lights/shadows add correctly). Shadows use a 4 sample percentage closest filter. Cost is simple the cost of generating the shadow map (render all objects in the lights view) and then a few (for PCF used here its about 10 including 4 texture samples) instructions in the lights pass. Its really elegant.