Again, a long time has passed since the last news and again we have many things to show you! So much, that we have to split it up into at least four news. The first thing we want to show to you is the new Deferred Shading in [w]tech. I bet, some of you know this technique, some heard about it and the others don't know what I'm talking about.
Lets start with a screenshot of the result:
You see, Deferred Shading is a lighting technique. Many engines and games use it today, just because it is able to create high performance, per-pixel and dynamic lighting. The best way to explain you how it works is to go through each step of the process. We use a simple scene as example:
Here, we have the unlit diffuse color of the rendered scene:
This are the normals, either per face or with a normal map on top, of all meshes in the scene. Normals are vectors pointing into the direction of each face:
And last but not least we need the depth of the scene:
These three shots are the minimal information you need to create lighting via Deferred Shading. Later, we'll add more of them, to get stuff like specular reflections or emissive color working.
So, what is to do with this different types of the scene? We need to render a quad all over the screen for each light. Then we can calculate the right values in the PixelShader, for each rendered pixel. For instance, the depth, isn't needed as depth, but as a source to calculate the world space pixel positions, to apply the light at the right location.
Now, with the diffuse color, the normals, and the vertex position in world space, we can let run everything through a formula, add the result to the BackBuffer, your screen, and here is our lighting!
![[w]tech](https://media.indiedb.com/cache/images/engines/1/1/146/crop_120x90/Preview_moddb.jpg)
![[w]tech team](https://media.indiedb.com/cache/images/groups/1/1/997/crop_120x90/wtechteam_preview.jpg)
Are you really rendering a fullscreen quad for each light? Can't imagine that running smoothly for more than a handful of lights, which would defeat the whole deferred rendering approach.
We must render a fullscreen quad for each light. And of course, this would be a total waste, if every pixel would get shaded. To avoid this, we calculate a clipping rectangle around each light. So only the pixels affected by the light are getting shaded :)
Awesome shader :D. I love the face looks very nice.
Astonishing how many people belief Def-Ren is the "holy grail" of rendering and "fast". It's actually the opposite. Def-Ren is very slow as soon as you do complex lighting situations. The more lights hit the same pixel the more costly Def-Ren gets. The death blow are then shadows. They are the "real" problem of Def-Ren including transparency. There are ways to handle it but in general with 10 or more shadow casting light sources in a room you are happy if you hit 15 fps on a 1680x1050 screen with a high-end graphic card. All this "fast" implementations use tiny light sources with no shadows. Hardly usable for a game.
I am aware of all your points. Please don't think that this is the final solution, there will be static lights later, and I plan to build in a static shadowing system, too. Although I don't know how you connect shadowing with DR? For a point light, you'll have to render a cubemap full of depth maps, which can be used to calculate the shadows. But that has nothing to do with DR. And of course, not all lights will cast dynamic shadows ingame, that would be just insane.
Maybe you have a even better idea to handle dynamic lighting? The implementation is still young, and I'm able to change things easily for now.
Connecting shadow casting to Def-Ren is actually rather simple if you have already a working lighting pass. All it takes is to simply add shadow casting to this lighting pass similar to For-Ren. The costly part is rendering the shadow map. Currently I'm using a static/semi-static/dynamic lighting system (double-shadow map system) I'm going to talk about in an upcoming news-post. Trades run-time cost (rendering shadow maps) with memory cost (reusing shadow maps over multiple frames) so it's not an all-cure. Right now I try to avoid point lights with dynamic shadows faking them if possible. I have to get a proper static lighting system up and running myself in addition to the dynamic one. Mixing static lighting with Def-Ren is quite a tricky job. Lots of tripwires one is not aware of.
So in general concerning dynamic lighting: avoid point light shadows whenever possible. Unless depth cube shadow mapping really is fast on all mainstream graphic cards. Right now there exists no graphic card which has really fast depth cube shadow maps. Especially no graphic card supports proper HW-PCF for depth cube shadow maps and neither can you do offset texture tapping on them so all current (advanced) shadow mapping techniques are unusable since they require tapping in a certain area.
I thought about reusable shadowmaps, too. Maybe there will be just one shadow casting light in the scene, the sun. (Of course some more, but not allways) I don't know if you described that in you last posting, but here is how I'm going to do it for lights like the sun (Which must not move):
First frame ever (Or some toggled event): Render all static meshes to a depth map
In the other frames: Copy from the saved surface and render all dynamics on top of it.
This would also work well on point lights, WHEN they don't move itself. But until I implement shadows, I have some other important points on my todo-list. Then I'll give more thoughts on this.
Why render a fullscreen quad at all? AFAIK you'd typically render primitive 3d shapes representing light volumes while using stencil- and z-buffer to further avoid unnecessary shading. Like what the Killzone 2 guys describe in their presentation:
Guerrilla-games.com
(edit: damn, that reply ended up at the wrong spot...)
While nice in theory stencil light volumes suffer a big problem: you trade one fill-rate for another. In particular you trade the fill-rate of running a light shader on a pixel with the one drawing (and prior clearing) the stencil buffer. Unfortunately graphic cards nowadays are a bit "annoying" when it gets to stencil+depth targets for direct rendering (as you need it for Def-Ren). In particular speed isn't as good so it's hard to gain speed with a stencil-rejection test in Def-Ren. There is though a different solution which is better tailored to the use of renderable depth textures in Def-Ren which does not require messing with stencil buffers at all.
By the way... which moron is down-voting again. Whoever this is for sure has not the slightest fart about GPU programming.
This is looking awesome!
Nice job!