Sign in to follow this  

Limiting light calculations

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

Hi everyone,

Is there a way to limit the influence of lights in a scene to a particular distance. For example, if a lamp is in one corner of the room, the amount of light that reaches the other corner after taking attenuation into account is very insignificant that I may as well have left it uncalculated.

My first idea is to calculate the fragment's world space distance from light in pixel shader and then proceed to evaluate the lighting equation based on that distance. But this requires 'if' statement in pixel shader. I was always advised to avoid dynamic branching in pixel shader. Any ideas?

Share this post


Link to post
Share on other sites
I added a range dependent falloff to ensure, that a light source only lit a limited, spherical area.

intensity *= max(0,1 - square_distance_to_light/(max_distance*max_distance))

Share this post


Link to post
Share on other sites
You can also do cheap squared length tests to check your (sub)objects with your light sources. Then store the ones that affect the object and only process these when rendering that object. Of course you can play with margins there also (bit lower or higher then the distance between them).

Share this post


Link to post
Share on other sites

 

I was always advised to avoid dynamic branching in pixel shader.


1. Shaders will follow the worst case within a warp or wavefront. For a pixel shader, this means groups of 32-64 pixels that are (usually) close together in screen space. What this means is that if you have an if statement where the condition evaluates false to 31 pixels but true for one pixel in the 32-thread warp, then they're all to execute what's inside the if statement. This can be especially bad if you have an else clause, since you can end up with your shader executing both the "if" as well as the "else" part of your branch! 

 

 

So each of the 32 pixels will execute both the if/else cases?

But the pixel will still only contain the result of the "correct" branch I suppose? So no pixels will end up being shaded wrongly due to branching.

Share this post


Link to post
Share on other sites

I was always advised to avoid dynamic branching in pixel shader.


1. Shaders will follow the worst case within a warp or wavefront. For a pixel shader, this means groups of 32-64 pixels that are (usually) close together in screen space. What this means is that if you have an if statement where the condition evaluates false to 31 pixels but true for one pixel in the 32-thread warp, then they're all to execute what's inside the if statement. This can be especially bad if you have an else clause, since you can end up with your shader executing both the "if" as well as the "else" part of your branch!

 
So each of the 32 pixels will execute both the if/else cases?
But the pixel will still only contain the result of the "correct" branch I suppose? So no pixels will end up being shaded wrongly due to branching.


Yes, that's right. The results will look correct, since GPU's are able to mask certain threads based on the branch result. However you will pay the cost of executing both sides of the branch, unless all threads in the warp/wavefront take the same path.

Share this post


Link to post
Share on other sites

This topic is 675 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this