• Advertisement
Sign in to follow this  

Lighting Implementations

This topic is 3757 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
well, i was aiming to use shadowmaps, so you think multiple pass lighting would be better?

and thanks for the tip :)

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
Quote:
Original post by LackOfGrace
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


how do you propose determining the color of each pixel before considering the effect of each light? color is not a static property of the objects color (diffuse texture map), even for purely diffuse objects..you can still have colored lights, and for specular reflections there is a specular color which is not always pure white...

Share this post


Link to post
Share on other sites
im thinking of doing an ambient pass first

after than ill (addativly) blend the lighting results


although, ive pretty much dropped the lighting considerations...
instead ive planned the renderer so that itll be easy to test wich will give the best results

Share this post


Link to post
Share on other sites
Just to chime in on the single-pass with shadowmaps ... that's what we're doing right now. We support a maximum number of shadow-casting lights in a single frame. We do all of our shadowmap generation at the start of the frame, and then do all lighting in a single pass (well, single pass after first doing a Z prepass). The shader then does all lights (some with shadows, some without), and performs all accumulation.

It makes our primary surface shader fairly complex, but it does keep things simpler in other ways. The other (minor?) benefit is that (if you really want to), you can do HDR without high bit-depth render targets. Assuming your tone mapper doesn't need the HDR output from the current frame to compute parameters, you could basically do the tone mapping as the last stage in the pixel shader. We haven't done this, but I think it's possible. You could (for example) render your scene twice per-frame ... once to a low-resolution HDR framebuffer, probably with a simplified shader that avoided computation that isn't going to (significantly) impact luminance. Then use that to set up your tone mapping parameters, which can be fed into the main single lighting pass -- running on your high-res, MSAA'd, etc... frame buffer.

Share this post


Link to post
Share on other sites
Quote:
Original post by osmanb
It makes our primary surface shader fairly complex, but it does keep things simpler in other ways. The other (minor?) benefit is that (if you really want to), you can do HDR without high bit-depth render targets. Assuming your tone mapper doesn't need the HDR output from the current frame to compute parameters, you could basically do the tone mapping as the last stage in the pixel shader. We haven't done this, but I think it's possible. You could (for example) render your scene twice per-frame ... once to a low-resolution HDR framebuffer, probably with a simplified shader that avoided computation that isn't going to (significantly) impact luminance. Then use that to set up your tone mapping parameters, which can be fed into the main single lighting pass -- running on your high-res, MSAA'd, etc... frame buffer.


That's actually how Source engine handles HDR. It's very nice in that it doesn't require support for floating-point AA or blending, and doesn't require the memory or bandwidth needed for 64bpp buffers. However IMO, Source games never seem to get the luminance quite right. Your approach with rendering a separate HDR mini-buffer though sounds very interesting though. You'll have to let us know if that works out for you! :D

Share this post


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

  • Advertisement