Parentheses in HLSL cause light attenuation function to not work correctly?

Phillip Clark · 2012-09-16T14:59:16

I have a diffuse+specular equation in my pixel shader, and it works pretty well except for this one issue: When I change this: float attenuation = 1.0f / d*d; To this: float attenuation = 1.0f / ( d*d ); My model is no longer lit, and is instead the color of my ambient intensity. I find this extremely strange. The reason I want parentheses is so I can use a different attenuation function such as ( 1 + 0.045*d + 0.0075*d*d ). It also messes up if I try this: float denominator = d*d; float attenuation = 1.0f / denominator; Here is my entire pixel shader. The reason for all of the "tmp_stuff" variables is to make everything "politically correct" since I have no choice but to input them as float4 due to constant buffer alignment properties. I would rather convert everything to temporary float3 rather than risk the chance of something not working right because of float4. Anyways, it shouldn't have anything to do with my current problem. I've doubled, tripled, and quad-checked my lighting equations with four different books, and I'm just baffled with this problem. void ps( in v2p input, out float4 final_color : SV_TARGET ) { float3 ambient_intensity = float3( 0.1f, 0.1f, 0.1f ); float3 diffuse_color = float3( 0.8f, 0.8f, 0.8f); float3 specular_color = float3( 1.0f, 1.0f , 1.0f ); float3 tmp_light; tmp_light.x = light_vector.x; tmp_light.y = light_vector.y; tmp_light.z = light_vector.z; float3 norm_light = normalize( tmp_light ); float3 tmp_pos; tmp_pos.x = input.pos.x; tmp_pos.y = input.pos.y; tmp_pos.z = input.pos.z; float3 tmp_norm; tmp_norm.x = input.norm.x; tmp_norm.y = input.norm.y; tmp_norm.z = input.norm.z; float3 tmp_cam = float3( 0.0f, 0.0f, -20.0f ); // fixed view camera position // light intensity float d = distance( tmp_pos, tmp_light ); float attenuation = 1.0f/d*d; // HERE IS THE PROBLEM AREA float3 pointlight = attenuation*float3( light_color.x, light_color.y, light_color.z ); // diffuse lighting float diffuse = max( dot( tmp_norm, norm_light) , 0.0f ); float3 diffuse_final = diffuse_color*ambient_intensity + diffuse_color*pointlight*diffuse; // specular lighting float3 reflect_vect = 2*dot( tmp_norm, norm_light )*tmp_norm - norm_light; float ref_max = max( dot( reflect_vect, normalize(tmp_cam) ), 0.0f ); float spec_exponent = pow ( ref_max, 50.0f ); float3 spec_final; if( dot( tmp_norm, norm_light ) <= 0 ) { spec_final = float3( 0.0f, 0.0f, 0.0f ); } if( dot( tmp_norm, norm_light ) > 0 ) { spec_final = specular_color*pointlight*spec_exponent; } final_color = float4( diffuse_final + spec_final, 1.0f ); } Without parentheses: With parentheses:

Graphics and GPU Programming Programming

Started by PhillipClark September 13, 2012 09:10 PM

13 comments, last by Bacterius 11 years, 7 months ago

Tsus

1,191

September 14, 2012 07:33 PM

Hi again!

First of all, thank you very, very much for the model!

Sorry, if we have lost you on the way with all the units (not all of them were explained). Photometrically correct lighting is sometimes a little overwhelming, when you’re not working with it every day.

I glanced a little longer at your code and noticed that you should probably normalize the normal in your pixel shader. Even if the normals are normalized in the vertex shader, the interpolated normal may not be normalized, when it arrives in the pixel shader. Despite from that it looks all fine. What happens if you move the light closer? Any chance to get it brighter?
Perhaps a squared fall-off isn’t a good idea if you only have one bounce of light. Would it work better in your scene, if you’d use a linear fall-off?

To answer your other question, the ambient light A can be a color (float3). It is used to model the indirect light that bounced between surfaces. If you’re in a room with many red walls, the ambient light would mostly be red.

The reflection model of your book looks almost like standard phong, except for the ambient part. But it is okay, to model it that way. The fixed function pipelines did it a little different, but that’s a matter of taste. Often games change the tone of the lighting or add additional terms, to achieve a certain look and feel, though it might not be “correct” in any way. A nice example is in John Edwards' talk on the sand rendering in Journey (second last section of that page).
Probably it’s best not to worry too much about the lighting, as long as it looks good.

Best regards!

Tsus

1,191

September 14, 2012 09:38 PM

There she is.

Nice model, thanks again!

Bacterius

13,181

September 16, 2012 01:07 AM

I couldn't resist and passed this great model through my path tracer (took forever though). Thanks again for the .obj, I will keep it as a reference model.

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”

Tsus

1,191

September 16, 2012 11:19 AM

Nice! I should put in area lights. It looks so much better.

Btw, I’ve used stochastic progressive photon mapping for the image above, implemented on the GPU using stochastic spatial hashing. So, a consistent rendering, too.

Bacterius

13,181

September 16, 2012 02:59 PM

Nice! I should put in area lights. It looks so much better.
Btw, I’ve used stochastic progressive photon mapping for the image above, implemented on the GPU using stochastic spatial hashing. So, a consistent rendering, too.

Haha, very nice, mine is just basic path tracing with an area light, a "wet plastic" material for the clothes and everything else is perfectly matte. I need to get working on ray tracing again but I have so much stuff to do... sigh perhaps one day I'll find time to implement my pipe dream, a fast physically correct raytracer (preferably on the GPU)