Jump to content
  • Advertisement
Sign in to follow this  
fries

Simple Alternative to Clustered Shading for Thousands of Lights

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

Advertisement

Nice! I do something similar per-mesh on the CPU in my engine: compute light intensity at mesh's position and then sort by decreasing intensity, submitting the first N lights to the mesh's shader. Your technique is per-pixel though...

Share this post


Link to post
Share on other sites

Nice! I do something similar per-mesh on the CPU in my engine: compute light intensity at mesh's position and then sort by decreasing intensity, submitting the first N lights to the mesh's shader. Your technique is per-pixel though...

I think that's how I was doing it a while ago. But BVH Accelerated Shading has the added bonus of not having to switch state between objects, so you can potentially batch a lot of objects together in one draw call.

 

Also, if you already have a hierarchy of lights, implementing BVH Accelerated Shading shouldn't take very long ;)

Edited by fries

Share this post


Link to post
Share on other sites

Glad you guys like it.

 

I'm going to be working on a clustering comparrison demo with code. It should be available in the next few days.

Share this post


Link to post
Share on other sites

Very interesting and good work smile.png

 

When taking a look at your technique, you would need to sample the memory quite often, compared to a clustered/cell deferred rendering pipeline, where the lights are stored as uniforms/parameters. So, my question is, how much bandwidth is your approach using ? How does it perform on a low-bandwidth system ? How much time does it take to rebuild the bhv and upload it per frame (dynamic light sources) ? How does it scale with number of lights ? How does it scale with the size of the render buffer ?

 

That is works with deferred and forward and a mix of it makes it really interesting, especially for the notoriously hard to implement lit particles and transparent surfaces in a deferred shader.

Share this post


Link to post
Share on other sites

When taking a look at your technique, you would need to sample the memory quite often, compared to a clustered/cell deferred rendering pipeline, where the lights are stored as uniforms/parameters.

In my experience with clustered, you store all the lights in the buffer in a very similar manner, except each cluster has a linear section of the buffer.
e.g. pseudo-shader:

struct ClusterLightRange { int start, size; };
struct LightInfo { float3 position; etc };

Buffer<ClusterLightRange> clusters;
Buffer<Lights> lights;

ClusterLightRange c = clusters[ClusterIdxFromPixelPosition(pixelPosition)];
for( int i=c.start, end=c.start+c.size; i!=end; ++i )
{
  Light l = lights[i];
  DoLight(l);
}

So the main additional cost is doing a bounding sphere test per light that you visit, and iterating through the light array as a linked-list rather than a simpler linear array traversal. On modern hardware, it should do pretty well. Worse than clustered, but probably not by much -- especially if the "DoLight" funciton above is expensive.

It would be interesting to do some comparisons between the two using (A) a simple Lambert lighting model, and (B) a very complex Cook-Torrence/GGX/Smith/etc fancy new lighting model.

 

Also, you could merge this technique with clustered shading:

A) CPU creates the BVH as described, and uploads into a GPU buffer.

B) A GPU compute shader traverses the BVH for each cluster, and generates the 'Lights' buffer in my pseudo example above.

C) Lighting is performed as in clustered shading (as in my pseudo example above).

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!