Jump to content
  • Advertisement
Sign in to follow this  

Light Accumulation & Materials

This topic is 2557 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'm having a few problems understanding how accumulation interacts with diffuse and specular terms of the material.

I've got an FP16 render target set up accumulating lighting information by additively blending in each light.

Right now it's being done like so..

accumulation += float4(light.rgb * nl,nh);

This is akin to how the prepass renderer I'm familiar with does it.

Once the FP16 is filled up with all my lights I go ahead and calculate the average log luminance by recursively downsampling.. to 1x1

My question is ... how the hell does this make sense as the accumulation only occurs on the light data itself. And the luminance is only calculated off the diffuse term of just the light hitting the surface.

Shouldn't accumulation happen with the final pixel color for each light interaction???

More like whenever a light pixel is drawn into the accumulation buffer you sample the albedo and specular of the material... evaluate the whole lighting equation there... and output that to be accumulated???

Can someone clear this up for me and maybe give me a trip down their render pipe upto the point of what gets accumulated...

Thanks in advance!

Share this post

Link to post
Share on other sites
This doesn't make sense.

* nh isn't a specular term by itself - it needs to be raised to a power, have it's energy distribution normalized, and multiplied with the light color/intensity.
* both diffuse and specular terms need to interact with the surface (e.g. multiplied with albedo) before you can do a radiance downsample.
* diffuse and specular terms need to be added together before you can do a radiance downsample.

What kind of renderer are you implementing -- forward, deferred shaded, deferred lit (aka light-pre-pass)?

The LPP method of accumulating diffuse in RGB and non-coloured specular in A is a huge hack (approximation) to begin with, you can't (accurately) accumulate them separately like that... but yes, if you want to do a luminance downsample, you'll have to take the materials into account first -- e.g. in LPP you'd do your "material pass" where you render your geometry and multiply it's albedo with the light-buffer, etc...

Share this post

Link to post
Share on other sites
That makes sense... so you accumulate the light hitting the EYE... so it has to be after the lighting equation is applied...

I'm used to the light prepass "hack" so I've got a lot of my pipe set up that way right now and I'm trying to go hdr with it for the first time.
But I've seperated it all out again for now so I have a bunch of render targets sitting around with all the data I need to try different combinations.

What I'm doing now is I have the following sitting in render targets when I go to accumulate the lighting.

albedo, normal, specular map (intensity not power), depth

I clear my render target (FP16) to ZERO and go ahead to start rendering out lights one at a time with additive blending. ( So I guess this is where my thinking has to change from light prepass)

So instead of the hack of storing float4(light.rgb * nl,pow(nh,50.0f));

I guess I will have to switch up my thinking and eval it all there for each light to output the rgb into the accumulation buffer.

diffuse = albedo * (nl * light rgb);
specular = pow(nh,50) * specularmap * light.rgb;
output = diffuse + specular;

Something like this... so that the whole lighting equation is calculated before accumulation for that pixel... seems to only make sense this way but it's my first day trying to grasp the hdr aspect.

Share this post

Link to post
Share on other sites
The main reason the LPP stores [font="'Courier New"][diffuse.r, diffuse.g, diffuse.b, spec][/font] is because it calculates the lighting before the surface albedo is known.

If you've already got the material properties in a g-buffer, then yes, you can calculate lighting properly, and accumulate the (combined) results.

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!