The method you suggested originally is still a feasible idea, just because you want multiple lights doesn't mean you have to use a deferred renderer, the other person said for 5 lights you would have to render a mesh 5 times that's not true at all, you can do multiple lights in a shader like you suggested, that person was explaining multi-pass lighting which is a pretty old technique and was used when hardware lights were limited so you could get more lights than you were allowed in hardware. Why the hell you you would render a mesh 5 times for 5 lights? that is totally insane.
I have implemented both deferred and forward renderers before, at first I thought deferred was great until I realised that actually the performance benefits weren't as good as I had thought they would be.
Deferred rendering introduced some new problems to address : no hardware anti-aliasing, its a bit restrictive in terms of having multiple material types, large fullscreen floating point gbuffers can be pretty hefty in terms of memory consumption (although there are methods to reduce this as much as possible like reconstructing position from depth) and deferred rendering doesn't handle transparent objects well.
Have a look at the pros and cons for each and what you want to achieve, I just felt the advice you had previously been given was completely biased towards deferred rendering, and explained forward rendering incorrectly.
[DirectX 10] Multiple ligths
Author
I think I will try deferred rendering...
I just haven't understood one thing:
-After creating the G-Buffer all pixels are in screen-space coordinates;
-So, when I want to apply the lights/shadow maps, how do I convert the pixel screen-space coordinates back to world space coordinates, so I can calculate if the pixel is affected by the light,shadow map, etc??
I just haven't understood one thing:
-After creating the G-Buffer all pixels are in screen-space coordinates;
-So, when I want to apply the lights/shadow maps, how do I convert the pixel screen-space coordinates back to world space coordinates, so I can calculate if the pixel is affected by the light,shadow map, etc??
I've read about this technique somewhere. Isn't this the same as forward rendering? What is it then?
- Render diffuse
- Render lighting for Light #1 -> Blend it to the backbuffer
- Render lighting for Light #2 -> Blend it to the backbuffer
- Render lighting for Light #... -> Blend it to the backbuffer
And yes, that IS insane. And thats why I don't use it. But putting every light into every shader isn't good at all, too (When you a large scene with many lights). When you would put a mesh with a shader at point A in to the scene, and another with the same shader at point B, you'll get a problem when point A is at the left side, and B on the right side. They both need to process all the lights from point A AND B (Unless you copy the shader for each mesh).
I also said: When you know what lights you are using (For a small game or a demo), putting the lights into the mesh-shader is a good technique. But if you want a user, who don't understands these things to create lights himself, you could get a problem.
I'm sorry for that. Could you tell me what forward rendering is in detail?
@Aqua Costa: In the GPU gems 3 book (or was it 1?) is a chapter about screen space shadow mapping. I think thats what you need. :)
Quote:
Why the hell you you would render a mesh 5 times for 5 lights? that is totally insane.
- Render diffuse
- Render lighting for Light #1 -> Blend it to the backbuffer
- Render lighting for Light #2 -> Blend it to the backbuffer
- Render lighting for Light #... -> Blend it to the backbuffer
And yes, that IS insane. And thats why I don't use it. But putting every light into every shader isn't good at all, too (When you a large scene with many lights). When you would put a mesh with a shader at point A in to the scene, and another with the same shader at point B, you'll get a problem when point A is at the left side, and B on the right side. They both need to process all the lights from point A AND B (Unless you copy the shader for each mesh).
I also said: When you know what lights you are using (For a small game or a demo), putting the lights into the mesh-shader is a good technique. But if you want a user, who don't understands these things to create lights himself, you could get a problem.
Quote:
Have a look at the pros and cons for each and what you want to achieve, I just felt the advice you had previously been given was completely biased towards deferred rendering, and explained forward rendering incorrectly.
I'm sorry for that. Could you tell me what forward rendering is in detail?
@Aqua Costa: In the GPU gems 3 book (or was it 1?) is a chapter about screen space shadow mapping. I think thats what you need. :)
Author
Quote:Original post by mind in a box
@Aqua Costa: In the GPU gems 3 book (or was it 1?) is a chapter about screen space shadow mapping. I think thats what you need. :)
I cant find that article...
Here: http://http.developer.nvidia.com/GPUGems/gpugems_ch14.html
It was in the first part of that book.
It was in the first part of that book.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
