[w]tech combines next generation technologies like full dynamic lighting, voxel based terrain and bullet physics, which are brought to you via a self-explanatory user interface. We are thinking in innovative ways to combine the available technologies and ideas to an edgeless package. Visit wtechportal.com to get more information about the newest features integrated into [w]tech!

Report article RSS Feed Deferred Shading in [w]tech

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.

Posted by [WuTz]! on May 25th, 2010



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:

Examples

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:

Deferred Shading


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:

Normals

And last but not least we need the depth of the scene:

Depth

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!

Complete

Post comment Comments
moci
moci May 26 2010, 4:30am says:

No Shadows?

+1 vote     reply to comment
[WuTz]! Author
[WuTz]! May 26 2010, 6:38am replied:

Shadows have their own rendering process and they will get built in, soon. They also will get their own news =)

+1 vote   reply to comment
Arparso
Arparso May 26 2010, 7:50am says:

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.

+1 vote     reply to comment
[WuTz]! Author
[WuTz]! May 26 2010, 8:19am replied:

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 :)

+1 vote   reply to comment
Kamikazi[Uk]
Kamikazi[Uk] May 26 2010, 8:53am says:

Awesome shader :D. I love the face looks very nice.

+1 vote     reply to comment
Dragonlord
Dragonlord May 26 2010, 9:41am says:

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.

+1 vote     reply to comment
[WuTz]! Author
[WuTz]! May 26 2010, 9:56am replied:

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.

+1 vote   reply to comment
Dragonlord
Dragonlord May 26 2010, 11:17am replied:

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.

+1 vote     reply to comment
[WuTz]! Author
[WuTz]! May 26 2010, 3:09pm replied:

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.

+1 vote   reply to comment
Arparso
Arparso May 26 2010, 4:55pm says:

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...)

+1 vote     reply to comment
Dragonlord
Dragonlord May 27 2010, 12:30pm replied:

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.

+1 vote     reply to comment
cW#Ravenblood
cW#Ravenblood May 27 2010, 9:30am says:

This is looking awesome!
Nice job!

+1 vote     reply to comment
Post a Comment
click to sign in

You are not logged in, your comment will be anonymous unless you join the community today (totally free - or sign in with your social account on the right) which we encourage all contributors to do.

2000 characters limit; HTML formatting and smileys are not supported - text only

Platform
Windows
Company
[w]tech team
Contact
Send Message
Licence
Creative Commons
Release Date
TBD
Engine Watch
Track this engine
News
Browse
News
Report Abuse
Report article
Related Engines
[w]tech
[w]tech Creative Commons TBD
Related Groups
[w]tech team
[w]tech team Developer with 3 members