Jump to content
  • Advertisement
Sign in to follow this  
afraidofdark

lighting with multiple lights

This topic is 2447 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

hello, now I am about to implement lighting of a scene with multiple lights. Before I do this, I want to explain how I will go about implementation and I expect recommendations :)

Find which octree nodes are in the field of view of the camera
Find every lights in the visible octree nodes
For each light , list all objects inside light's bounding box { for example light x see objects : a, b, c & light y see a, b , d }
sort each listed objects , do instancing & dynamic batching { briefly generate render jobs for each light }
do all rendering jobs per light

but this way I have to do many pass, I looked at some deffered lighting tutorial, however implementing the algorithm above is simpler than implementing a deffered lighting routin, so first thing will be implementing the algorithm above, but it may be extremely inefficient, so before I do anything, I want recommendations :)

Share this post


Link to post
Share on other sites
Advertisement

hello, now I am about to implement lighting of a scene with multiple lights. Before I do this, I want to explain how I will go about implementation and I expect recommendations :)

Find which octree nodes are in the field of view of the camera
Find every lights in the visible octree nodes
For each light , list all objects inside light's bounding box { for example light x see objects : a, b, c & light y see a, b , d }
sort each listed objects , do instancing & dynamic batching { briefly generate render jobs for each light }
do all rendering jobs per light

but this way I have to do many pass, I looked at some deffered lighting tutorial, however implementing the algorithm above is simpler than implementing a deffered lighting routin, so first thing will be implementing the algorithm above, but it may be extremely inefficient, so before I do anything, I want recommendations :)


At a basic level, deferred lighting is a lot simpler than forward lighting. Deferred looks like this:

Draw everything once
foreach light { draw light volume}

if your scene has hundreds of lights this is the obvious choice.

However, there are ways to simplify the forward lighting system as well, such as drawing light volumes into the stencil buffer before you render and then just rendering absolutely everything within the view frustum repeatedly. So, your render code looks like this:


draw ambient and baked lighting
collect list of lights within frustum
for each batch of 8 lights
clear stencil buffer
draw light volumes
draw everything in the frustum
next

Now, it doesn't look quite so complicated. You can use additional CPU side bounding volume tests if you wish. I don't. You might find that brute forcing your way through the scene a few times isn't as bad as it seems in theory.

Share this post


Link to post
Share on other sites
You might find that brute forcing your way through the scene a few times isn't as bad as it seems in theory.

I did.
You should plan on implementing a few tricks to get this working fast, and by then it might become easier to use deferred rendering.
Then again what I am about to suggest also can be applied to deferred rendering for best results.

Keep attributes of your vertex buffers separate and only activate the ones that will be used.
For example, an ambient-only pass in forward rendering has no use of normals if you are using the standard lighting model. Keep normals, binormals, and tangents in a separate vertex buffer so that you can avoid sending them during the ambient pass.
For generating shadow maps, you only need vertex data, so keep them in their own vertex buffer too.


This makes your ambient-only and shadow-mapping passes much faster (shadow maps become virtually free, especially in Direct3D). Your lighting passes will be the same speed as before (some articles/documentation suggest that using multiple vertex streams is slower than using only one; while this may be true, my tests show undetectable change between the two methods, so whatever slow-down is supposed to be there is negligible).


L. Spiro

Share this post


Link to post
Share on other sites
Just a note, but think first before switching to deferred rendering, if it is sufficient for you. Do you need transparency? Or reflections? etc. Deferred rendering is pretty low quality or slow with these ones. Also, antialiasing - post processed AA will NEVER be at same good quality as "true" AA, and using 4x multisampled textures for deferred rendering is indeed slow.

Share this post


Link to post
Share on other sites
thank you for your recommendationsI'll try both forward and deffered rendering systems at the and I may end up mixing both technique, depending on the scene I may need to switch between two of them. I'll try popular rendering methods and see what is best for me

Share this post


Link to post
Share on other sites

Just a note, but think first before switching to deferred rendering, if it is sufficient for you. Do you need transparency? Or reflections? etc. Deferred rendering is pretty low quality or slow with these ones.


If you use forward rendering for these things (which most people do), then they are just as "low quality" or "slow" as forward rendering is.


Also, antialiasing - post processed AA will NEVER be at same good quality as "true" AA, and using 4x multisampled textures for deferred rendering is indeed slow.


I would really take issue that statement. In terms of pure edge quality MLAA and FXAA often produce superior results to MSAA, especially if you use MSAA with HDR and don't perform your resolve after tone mapping. Where they lose is temporal stability, so it's more of a trade off than a guaranteed step down. I'm also not sure where you get the idea that filtering techniques are not "true" AA.

MSAA also shouldn't be slow with deferred rendering, if you're doing it right.

Share this post


Link to post
Share on other sites
If you use forward rendering for these things (which most people do), then they are just as "low quality" or "slow" as forward rendering is.[/quote]

Ahh.. got a bit confused by this post - but after few minutes I got a point (you mean forward pass after deferred shading). I actually firstly thought about stippling (although it doesn't necessarily look that bad!) or depth-peeling (for order independent transparency with deferred shading - and thats overkill).

In terms of pure edge quality MLAA and FXAA often produce superior results to MSAA, especially if you use MSAA with HDR and don't perform your resolve after tone mapping.[/quote]

Yes, but still - if you do MSAA correctly (e.g. resolve after tone mapping) - there are cases, where MLAA or FXAA fails, MSAA on the other hand don't. Honestly I'm also thinking about switching to MLAA, FXAA or another similar technique (or at least give user ability to use both - these, or MSAA - of course with post tonemapping resolve).

I'm also not sure where you get the idea that filtering techniques are not "true" AA.[/quote]

Thats why i quoted around the true (I thought it would be understandable). They're indeed full AA technique as MSAA is.

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!