# Light Accumulation & Materials

## Recommended Posts

REF_Cracker    966
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...

##### Share on other sites
Hodgman    51226
This [i]doesn't [/i]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 ([i]approximation[/i]) to begin with, you can't ([i]accurately[/i]) 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 on other sites
REF_Cracker    966
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 on other sites
Hodgman    51226
The main reason the LPP stores [font="'Courier New"][diffuse.r, diffuse.g, diffuse.b, spec][/font] is because it calculates the lighting [i]before[/i] 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 ([i]combined[/i]) results.