Jump to content
  • Advertisement
Sign in to follow this  
matt77hias

Handling multiple lights

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

Various solutions on the web for handling multiple light sources in forward rendering hardcode a fixed number of lights in the shader or use a texture to encode the lights. Is it somehow possible (and for which HLSL shader model) to directly allocate a variable number of lights?

Or is the forward rendering approach not really useful if one wants to add shadows anyway and should a deferred rendering approach be preferred for each light separately (+ shadow mapping)? How scalable in terms of the number of point lights is the basic shadow mapping algorithm for common scenes?

Share this post


Link to post
Share on other sites
Advertisement
Shadows work pretty much the same in forward and deferred.

The only way to have a variable sized array in HLSL is to use a texture/buffer. Constants / cbuffers must have a fixed size... However, you can define a maximum size and then use a variable to hold the actual size. That lets you write a shader that supports, say, up to 8 lights.

You can draw one light per pass in forward too. The first light for an object uses opaque blending and LEQUAL depth, then all subsequent lights draw that object again with additive blending and EQUAL depth testing.
You can use this in combination with the fixed sized light list technique too -- e.g. the first 4 lights opaque, then thr next 4 draw the object again additively.
Also if you use ambient lighting, you need to make sure it only applies during the first/opaque pass, or you'll double up.

Share this post


Link to post
Share on other sites

Shadows work pretty much the same in forward and deferred.

Don't you mean lighting (since there is no visibility component except some finite volume in space a light affects)?


e.g. the first 4 lights opaque, then thr next 4 draw the object again additively.

Does one normally uses this approach on the level of every model part + material or at the level of the full world (i.e. render the world opaque/additive with these x lights etc.)?

Share this post


Link to post
Share on other sites
Don't you mean lighting (since there is no visibility component except some finite volume in space a light affects)?

I think he means shadows, in that sampling shadow maps is done the same way in both forward and deferred.

Edited by Infinisearch

Share this post


Link to post
Share on other sites

Render geometry visible to light from the perspective of the camera and at each pixel (or is it fragment) transform the point to the light's space
 

Isn't this by definition deferred?

 

Currently I have not implemented shadow mapping, but since you are referring to the light's space i start wondering what the most convenient space is for shading. I currently work in view space, since the view vector is obtained practically for free. The same applies for the shading point in view space as one obtains it before going to projection space. Furthermore, I could world-to-view, view-to-projection and world-to-view inverse transform stay fixed for the full frame.

Share this post


Link to post
Share on other sites

I deleted that part for a reason... its shadow mapping for forward, I'm not sure about shadow mapping for deferred.  IIRC for deferred instead of rendering object geometry you render light geometry (into a light accum buffer).  But I'm not to familiar with deferred, so hopefully Hodgman will answer back.  But the basic principle is the same... sample the shadowmap at every relevant pixel.

 

Isn't this by definition deferred?

No deferred implies a G-buffer. 

 

As to spaces you need the point in the light's space so you can sample the correct portion of the shadow map.

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!