Sorry your browser is not supported!

Hey people,

I'm refreshing my lighting skills these days and I want to present my progress and discuss lighting techniques in general.
I've been reading through some very interesting papers and I'm currently building a new dynamic lighting system.
So far I have shader-based Vertex Lighting and Per-Pixel Lighting done.
I have already experimented with Unified Lighting.
My next big task is to get into Deferred Rendering. I know it's a very complex subject but I think this method has great advantages and lots of potential once done right. I'm already making big steps, but there's not much to show yet.

Here are a few screenshots of what is completly working right now:

Vertex Lighting



Per-Pixel Lighting


As you might know there are thousands of ways to achieve good and realistic lighting, so if anybody wants to give their 2 cents please do so
I'm willing to help and open for suggestions.

Cheers.

I want to learn all this stuff, for myself, and for dosp. I don't really have time to though at the moment. I have decided to concentrate on utilising other peoples shaders for now.

Is there any chance you could briefly explain:
Vertex Lighting
Per-Pixel Lighting
Deferred Rendering

If its too technical and time consuming, don't worry about it.
Also, will you be sharing any more of your shaders with us?

The same for me. Of course there may be lots of great shaders and techniques out there, but I just want to make my own



Sure. One of my intentions for this thread is to exchange some knowledge. It's a very complex subject after all so here you go:

Vertex Lighting:
One of the most basic lighting techniques that has been used in the past a lot. It works like this: Light contribution is done on a Per-Vertex basis, so every vertex of a model/scene gets light applied. This is very fast since you're not working on pixels here, just on vertices, which are far less of course. The lighting calculations (distance, attenuation,...) takes place in the vertex shader. The drawback is, that the quality of the light is just as good as the amount of vertices, because light just gets interpolated between a polygons vertices.
Vertex Lighting is used in DarkGDK by default.

Per-Pixel Lighting:
This is one step further than Vertex Lighting. Here you do the light calculations on a per-pixel basis, which means they take place in the pixel shader. Because every pixel of the model/scene has to be calculated, this is a lot more power consuming. But the results are a lot better and precise, because it doesn't matter how many vertices or polygons you have.
You can see this in comparing the two screenshots above: in the first one the cube's faces have light distributed on them a bit strange and unrealistic (interpolated from one vertex to another).
In the second image you can see that the light is distributed more fluently and smooth even on low-poly objects like the cube.

Deferred Rendering:
Ok, this is a bit more complicated, as I'm getting into this for myself at the moment. I'll go into detail later.
For now just remember that this is basically a very different approach to rendering. You're separating (deferring) rendering steps with this. So you first process all the data you need (geometry, normals, depth, materials/specularity,...) and write that data to what is called a G-Buffer. Then in a second step you perform the lighting based on that data, but just in the areas that are affected by light (lights are actually rendered objects here, like spheres and cones). This basically allows you to have a much greater amount/flexibility of dynamic lights in a scene. But the programming is not that easy, since you have to take care of everything what's normally done by the fixed function pipeline.

So, I hope this little info helps you.
Please consider that we haven't even touched on shadows here! Things get a lot more complex with that.



Yes, but I'd like to finish things up and build some small demos/usage examples around it, so people will actually learn from it.

Questions/suggestions are very welcome!

it looks nice man, you can add normal maps to the scene, it looks really cool & realistic with it

Yes thanks for the advice. I already did that, not very complicated but nice results.
My main concerns right now are how to get the Deferred Rendering working and dynamic shadows. I'm not quite sure what method to choose for that. I already did Shadow Mapping a while ago, but I'll have to implement that into my new lighting system. Don't know about Shadow Volumes. Any suggestions?

So where does radiosity, lightmapping and ray-tracing (as far as lights go) fit into all of this?

JTK

I'm not quite sure about Radiosity lighting techniques, but I think they are very time consuming. I guess that wouldn't work well for realtime graphics rendered with DarkGDK.

Lightmapping is very useful and performance-friendly for static lights. The lights influence on the scene is pre-computed and stored in a texture, which is then blended with the diffuse texture to produce a lighting effect.

Ray-tracing is also very time consuming, because the light is computed by casting many rays of light (like real photons do I guess). Not very usable for games as far as I know...

I think lightmapping can use ray-tracing, thanks for all the info pauli.

Is it possible to have dynamic lights/shadows on objects that have been lightmapped? I'm sure it is, but is it complicated?

I've been playing with Evolved's and your shadow shaders, they both have their different uses, have you tried yours with a 'jitter' texture applied, Evolved's one uses it and it stops(improves) that strange effect around the edges of the shadows that your one has.

Yes, that shouldn't be too hard. You can add lightmaps to almost any shader, you just have to put the lightmap-textures color value into the pixel shaders output color.



I know. I just made this shader to see how fast it could get without any optimizations. The quality of the shadows can be improved in many ways, like doing a Gaussian Blur on it.
But I'm checking various shadow techniques at the moment, have to see what fits my needs best...

I knew that radiosity and ray-tracing were *very* slow, and provide excellent results; but are pretty useless in real-time (ie: games)...

But, I never really looked into vertex/pixel shading so I didn't really know what they were about; thus, I needed a bit of clarification (as compared to my original thoughts on ray-tracing techniques)...

It seems to me, and maybe in this understanding - I'm wrong, that pixel shaders are quite similar to ray-tracing; but somehow optimized.

I know when I wrote a ray-tracing program (way back when) I shot a ray from the pixel back to every light source looking for occlusions (shadows) - and thus, the algorithm was O((p*l)^2) - where p=no. of pixels * l=number of lights - squared!

I'm not sure, but it seems to me that pixel-shading is doing the same thing... Again, I'm talking ray-tracing as it pertains to lights.

Vertex shading, on the other hand, sounds like an idea I had back then; that fires a ray from each vertex (or in those day's - remember I never really understood 3D [not so sure I do now, really] - "selected points" of the objects) to each light source to figure out how much "shadow" should be rendered... Again, the algorithm would be O((p*l)^2) only this time, p=no. of points in the scene.

While both are the same - in "Big-O" notation, the difference comes from the fact that "p" can be restricted to equal "points of objects on the screen" - Huge difference... Or am I wrong here?

Never really persued neither approach to lighting as they just don't seem right to me...

I don't know but I thought back then (and still do now) that our lighting techniques are not optimal... I know there's a lot of brilliant minds working on this topic - and by that very fact, I know that my intuition is right - as they too feel that what we have now is not *right*...

So, just look for me to #include <"my-two-cents"> from time to time, ok?

JTK