Jump to content
  • Advertisement
Sign in to follow this  
LackOfGrace

Lighting Implementations

This topic is 3998 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
sure, but what you are saying dosent really differ from what im proposing.

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"

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!