![[de]](/mwf/flags/de.png "Germany")
Here a video:
http://www.youtube.com/watch?v=-Q6ISVaM5Ww&NR=1
this game uses a rendering technique called "deferred shading" that means, a complex scene is once rendered with color, normals and depth and in each following renderpass, lights, blurring and other post scene effects are applied.
Modern game engines like CryEngine are using this technique because it can handle a huge ammount of lights (theor. unlimited).
http://www.youtube.com/watch?v=-Q6ISVaM5Ww&NR=1
this game uses a rendering technique called "deferred shading" that means, a complex scene is once rendered with color, normals and depth and in each following renderpass, lights, blurring and other post scene effects are applied.
Modern game engines like CryEngine are using this technique because it can handle a huge ammount of lights (theor. unlimited).
Sigh, okay. One hand: I already know about this, and actually have plans on using something similar - look at the point where I'm talking about multi-pass shaders.
Other hand: You are so unspecific I can't tell what you actually plan on doing with this. You might have a good idea there, but I can't tall just from a link and a few facts about how it is used in a different context.
So please tell me: What problem are you trying to solve? And how does this help with said problem?
Other hand: You are so unspecific I can't tell what you actually plan on doing with this. You might have a good idea there, but I can't tall just from a link and a few facts about how it is used in a different context.
So please tell me: What problem are you trying to solve? And how does this help with said problem?
The render target should be (or is already) a Framebuffer that draws on MRT (multiple render targets) the following targets:
- color attachment
- normals in global space
- depth attachment. (maybe can be left out [or used for shadowing])
Afer having the full scene in full color, we generate a second FBO: the light map.
the light map is filled with the ambient light and for each light source, the light map is filled additive with the light sources (that use the pre-rendered normals of the objects) to get a lightmap that is then multiplied with the color map.
So we need for each graphics that is rendered in clonk
- a color attachment
- a normal map (pre-rendered, by default a flat normal map is attached)
- Models do have normals anyway
- Models should enable their lightning because it's done in the lightning map.
i hope, it is easy to implement into the openclonk rendering architecture.
i will try to implement this technique in gwX, too so you can see how it would look like.
- color attachment
- normals in global space
- depth attachment. (maybe can be left out [or used for shadowing])
Afer having the full scene in full color, we generate a second FBO: the light map.
the light map is filled with the ambient light and for each light source, the light map is filled additive with the light sources (that use the pre-rendered normals of the objects) to get a lightmap that is then multiplied with the color map.
So we need for each graphics that is rendered in clonk
- a color attachment
- a normal map (pre-rendered, by default a flat normal map is attached)
- Models do have normals anyway
- Models should enable their lightning because it's done in the lightning map.
i hope, it is easy to implement into the openclonk rendering architecture.
i will try to implement this technique in gwX, too so you can see how it would look like.
You still did not answer Peter's most fundamental questions:
> So please tell me: What problem are you trying to solve? And how does this help with said problem?
I'm not solving a problem, guy.
You are here in the "Ideas and Concepts" board so why do you need to solve a problem here?
My answer gives a concrete way how to implement it, but I will not do it because of ck's hard push conditions (I cannot read pagan letters).
You are here in the "Ideas and Concepts" board so why do you need to solve a problem here?
My answer gives a concrete way how to implement it, but I will not do it because of ck's hard push conditions (I cannot read pagan letters).
> You are here in the "Ideas and Concepts" board so why do you need to solve a problem here?
Well, the normal way to go about these kind of things is that there is a specific problem to solve, or a feature which I want to be implemented, and then I choose a technique which allows me to do so. Instead one might get the impression that you want us to use the latest and greatest technology only for the sake of doing so.
> but I will not do it because of ck's hard push conditions (I cannot read pagan letters).
Sorry, I don't understand what you want to say with this.
>Sorry, I don't understand what you want to say with this.
"I will push your changeset when you can say me what is written here http://www.astro-stern.de/images/runen.jpg"
don't remember?
Hey, that was a CM joke :). If I remember correctly what we were looking for turned out to be Tifinagh.
this joke was not funny.
I was fighting for my commit that it gets pushed and in such moments, i don't understand jokes >:o
I was fighting for my commit that it gets pushed and in such moments, i don't understand jokes >:o
but if you want, you can use my source code:
http://goldenwipf.de/hg/index.cgi/file/tip/src/deferredshading.pas
http://goldenwipf.de/hg/index.cgi/file/tip/src/deferredshading.pas
Yeah, as I already said - I know what deferred shading is. But what is the upside for us that makes it worth to do the rendering in (at least?) two steps? Why can't we just use direct shaders? In contrast to 3D games, the count of light sources shining on every point is likely to be very low. If it becomes a problem, I would rather subdivide the landscape into parts than have a two-stage rendering process.
Concerning the video you posted first: Having pre-calculated images with depth information is a definitely a neat idea that ties well into this - but it's exactly the opposite of what we're doing right now with the object drawing code. We decided to go polygons, we decided to now have true Z-level-checks (if I'm not mistaken). He's going "no polygons, use trick for Z-level checks". At core, his idea isn't about shading.
Concerning the video you posted first: Having pre-calculated images with depth information is a definitely a neat idea that ties well into this - but it's exactly the opposite of what we're doing right now with the object drawing code. We decided to go polygons, we decided to now have true Z-level-checks (if I'm not mistaken). He's going "no polygons, use trick for Z-level checks". At core, his idea isn't about shading.
>Why can't we just use direct shaders?
When you try to implement multiple lights in an other way, you will need a whole geometry pass per light or you will loose color information and the scene looks like in CR (make everything darker and add some gray value)
>In contrast to 3D games, the count of light sources shining on every point is likely to be very low.
Just imagine a street with hundrets of street lamps.
>We decided to go polygons, we decided to now have true Z-level-checks (if I'm not mistaken). He's going "no polygons, use trick for Z-level checks". At core, his idea isn't about shading.
the interesting part in deferred shading is the normal render target. With this, you get realistic rendering results with more than one light source.
> When you try to implement multiple lights in an other way, you will need a whole geometry pass per light
Why? For every pixel, it's something like
color = mat_tex * (normal * (light_pos1 - pixel_pos) * light_color1 + normal * (light_pos2 - pixel_pos) * light_color2 + ... + ambient)No need for additional geometry passes, as I see it. As long as there is a bound on the count of light sources - and as I said, in contrast to 3D engines we can actually somewhat ensure that - that ought to be faster than having some intermediate result of this equation written to a texture.
With your technique, you would have to generate a new shader when a new light source is visible.
But lightning is just one fact,
there are a lot of other post processing steps that could become interesting for Clonk:
- hardware fire: just mark all areas that are on fire in a back buffer and then draw the fire map in an additional step (blurring etc.)
- landscape movement: you mark the parts of the landscape that should wobble and make waves and the post processing shader would calculate it for you
- underwater sight
- drunken sight
- ray casting shadows
and many others.
deferred shading ist not just a technique, it's an architecture.
an other advantage of deferred shading is that it's faster.
the depth complexity does not affect the light performance, you just draw all the geometry and after this, you have a constant calculation time for each light pass because you only calculate the pixels you really see on the screen.
A third advantage is you dont need to calculate the spotlights for each pixel (just imagine a PeterW-shader with 1 global light, 20 local lights and 30 spot lights), you can clip the area of a spotlight.
Summary:
Your version: fast for one or two light sources
My version: optimal for each ammount of light sources
But lightning is just one fact,
there are a lot of other post processing steps that could become interesting for Clonk:
- hardware fire: just mark all areas that are on fire in a back buffer and then draw the fire map in an additional step (blurring etc.)
- landscape movement: you mark the parts of the landscape that should wobble and make waves and the post processing shader would calculate it for you
- underwater sight
- drunken sight
- ray casting shadows
and many others.
deferred shading ist not just a technique, it's an architecture.
an other advantage of deferred shading is that it's faster.
the depth complexity does not affect the light performance, you just draw all the geometry and after this, you have a constant calculation time for each light pass because you only calculate the pixels you really see on the screen.
A third advantage is you dont need to calculate the spotlights for each pixel (just imagine a PeterW-shader with 1 global light, 20 local lights and 30 spot lights), you can clip the area of a spotlight.
Summary:
Your version: fast for one or two light sources
My version: optimal for each ammount of light sources
Only if more light sources are visible than I set in the shader. If it's less, I can just skip in the shader - I guess I can just set light color to black.
The generation of some spare screen-sized textures and a few complete re-initializations of the shader pipeline simply can't be that cheap. Maybe the GPU is stupid and applies the shader for pixels that aren't even visible, but this isn't really our problem here.
I don't see how any of these require deferred shading. Another shader pass, yes, in the worst case - but not deferred shading.
Standard algorithm (I didn't invent that): Easy, fast for few light sources
Deferred shading: Complex, fast for things with a lot of overlap and many lights, most likely slower for whatever we're going to do
> an other advantage of deferred shading is that it's faster.
The generation of some spare screen-sized textures and a few complete re-initializations of the shader pipeline simply can't be that cheap. Maybe the GPU is stupid and applies the shader for pixels that aren't even visible, but this isn't really our problem here.
> hardware fire: just mark all areas that are on fire in a back buffer and then draw the fire map in an additional step (blurring etc.)
> - landscape movement: you mark the parts of the landscape that should wobble and make waves and the post processing shader would calculate it for you
> - underwater sight
> - drunken sight
> - ray casting shadows
I don't see how any of these require deferred shading. Another shader pass, yes, in the worst case - but not deferred shading.
> Your version: fast for one or two light sources
> My version: optimal for each ammount of light sources
Standard algorithm (I didn't invent that): Easy, fast for few light sources
Deferred shading: Complex, fast for things with a lot of overlap and many lights, most likely slower for whatever we're going to do
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
