Lighting Implementations
Author
I have been pondering about different ways of lighting a scene.
it seems like there are three "ways" of doing it on current hardware
(really brief)
1. One-pass
Render all lighting in one pass
2. Multi-pass
Render color first then render lighting over afterwards
3. Deferred
Render pixel information to a fat buffer, then render all lights in one pass
thinking about it i always return to belive that Multipass lighting should have the best avarage between looks, performance and customizationess
in my head it seems that the cost of rendering shouldnt be overly costly for a standard scene ( lets be realistic, 4-6 lights )
i also belive that it would be really easy to set wich type of lighting model a specified object should use
and it also seems that it wont need either a really developed ubershader , nor a complete shader library
the only drawback it seems, is that when the amount of lights increases the performance will greatly drop.
on the other hand, using good scene management and culling with some precompiled shadowmaps would adress these problems quite good.
why are he rambling like a mad man about lights and stuff you might ask.
(i just noticed that the post where getting rather long for a simple question)
im in the planning stage of a renderer (my portfolio needs some additions)
and this is the only thing im uncertain about.
would be really nice to get some advice from you guys.
thanks
Light can be accumulated in R,G,B wavelengths separately so you can't just render the hue and then increase the value based on your lights.
It seems silly to make 2 or 3 passes just to accomodate 2 lights. I think it makes more sense to have each pass be capable of adding the effects of 2-4 lights, and then dynamically doing additional passes for every additioanl 2-4 lights you need.
It seems silly to make 2 or 3 passes just to accomodate 2 lights. I think it makes more sense to have each pass be capable of adding the effects of 2-4 lights, and then dynamically doing additional passes for every additioanl 2-4 lights you need.
Author
sure, but what you are saying dosent really differ from what im proposing.
i didnt say that there should be one pass per light.
what i meant was that i should start to render the color ( without lighting )
and then render lighting ontop of the colormap
so its perfectly viable to process x number of lights in one of those after passes
so, if i process four lights per lighting pass, i would end up with 3 passes
one color/depth pass and two lighting passes
another possibility is that im "out in the forest"
Quote:
It seems silly to make 2 or 3 passes just to accomodate 2 lights
i didnt say that there should be one pass per light.
what i meant was that i should start to render the color ( without lighting )
and then render lighting ontop of the colormap
so its perfectly viable to process x number of lights in one of those after passes
so, if i process four lights per lighting pass, i would end up with 3 passes
one color/depth pass and two lighting passes
another possibility is that im "out in the forest"
Don't underestimate the cost of multiple passes over the scene. On DirectX9 there's a considerable CPU cost to every draw call so having to draw the same object multiple times is best avoided. That's alleviated a bit on DirectX10 but there's always going to be CPU overhead to multiple passes.
On top of the CPU cost there's quite a bit of GPU cost as well. When you accumulate the effect of multiple lights in a single pass in one shader you're combining all the values in the GPU registers. Once you go to multiple passes you have to write out values to video memory and then read-modify-write in your frame buffer blend to accumulate lighting. That leads to increased memory bandwidth and the trend with graphics hardware is that shader ALU performance is increasing quite a bit faster than memory bandwidth.
Then there's all the redundant extra work that you have to do with multiple passes. You have to re-transform all your vertices, and re-skin them for animated models. You have to re-rasterize all those triangles and z-test them again. You have to re-fetch any textures that are involved in the lighting calculations (normal maps, spec and gloss maps, possibly others depending on the complexity of your lighting). If you have a tangent space normal map you have to re-transform it. There's a lot of redundant work involved in multi-pass lighting, and the more complex your lighting the greater the amount of redundant work. Deferred rendering's main benefit is reducing this redundant work to a minimum by caching as much as possible in full screen render targets.
On modern hardware (SM3+) that has high instruction count limits and fairly efficient static and dynamic branching there's not many good reasons to use multi-pass lighting. The biggest remaining benefit is increased orthogonality between your shaders but IMO the tradeoff is not worth it for most engines.
On top of the CPU cost there's quite a bit of GPU cost as well. When you accumulate the effect of multiple lights in a single pass in one shader you're combining all the values in the GPU registers. Once you go to multiple passes you have to write out values to video memory and then read-modify-write in your frame buffer blend to accumulate lighting. That leads to increased memory bandwidth and the trend with graphics hardware is that shader ALU performance is increasing quite a bit faster than memory bandwidth.
Then there's all the redundant extra work that you have to do with multiple passes. You have to re-transform all your vertices, and re-skin them for animated models. You have to re-rasterize all those triangles and z-test them again. You have to re-fetch any textures that are involved in the lighting calculations (normal maps, spec and gloss maps, possibly others depending on the complexity of your lighting). If you have a tangent space normal map you have to re-transform it. There's a lot of redundant work involved in multi-pass lighting, and the more complex your lighting the greater the amount of redundant work. Deferred rendering's main benefit is reducing this redundant work to a minimum by caching as much as possible in full screen render targets.
On modern hardware (SM3+) that has high instruction count limits and fairly efficient static and dynamic branching there's not many good reasons to use multi-pass lighting. The biggest remaining benefit is increased orthogonality between your shaders but IMO the tradeoff is not worth it for most engines.
Author
you are probably right, the only reason i dont like defeered shading is because it requiers a fairly high SM and it dosent support Multisampling.
one other thing is that im using SDL, using wiggle would remove the crossplatform-ness.
so maybe it would be best with singlepass rendering in my case?
one other thing is that im using SDL, using wiggle would remove the crossplatform-ness.
so maybe it would be best with singlepass rendering in my case?
Try and pack as much stuff into each pass as you can. And precompute and store as much static stuff as you can.
It all depends on how you are going to implement your shadows. For instance, if you want to use shadow maps, you can't render all the lights in one pass because you have to render the depths from the each lights point of view.
Another point to consider - if you are going to render the lights in multiple pass’s, you will have to use alpha blending. In that case it is a good idea to render the Z buffer from the cameras point of view first (disable color write), and do the light pass’s using the values in the Z buffer. That way all hidden pixels will be discarded with out getting any artifacts of hidden pixels blended into the scene.
Another point to consider - if you are going to render the lights in multiple pass’s, you will have to use alpha blending. In that case it is a good idea to render the Z buffer from the cameras point of view first (disable color write), and do the light pass’s using the values in the Z buffer. That way all hidden pixels will be discarded with out getting any artifacts of hidden pixels blended into the scene.
Author
well, i was aiming to use shadowmaps, so you think multiple pass lighting would be better?
and thanks for the tip :)
and thanks for the tip :)
Quote:Original post by LackOfGrace
you are probably right, the only reason i dont like defeered shading is because it requiers a fairly high SM and it dosent support Multisampling.
"Fairly high SM" very much depends on your implementation, and how you handle different materials and such. My own deferred renderer uses a rather simple BRDF model, but I assure you it runs quite happily on SM2.0 hardware (even with variance shadow maps).
Multi-sampling depends on what hardware and API you're using. It's very doable in DX10, but admittedly the approach is something of a mix between multi-sampling and super-sampling. Of course super-sampling is always doable from an implementation POV, even if its not feasible performance-wise. I still include it as an option in my renderer, since I always figure a costly option is better than no option at all.
Quote:Original post by doronf
It all depends on how you are going to implement your shadows. For instance, if you want to use shadow maps, you can't render all the lights in one pass because you have to render the depths from the each lights point of view.
Well, what you're saying only applies if you're doing "lazy" shadow-map generation. If you've rendered all of your shadow-maps in advance, there's no reason you can't perform the actual lighting in one pass.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
