Jump to content

  • Log In with Google      Sign In   
  • Create Account

eowdaoc

Member Since 24 May 2011
Offline Last Active Dec 19 2012 11:10 PM

Posts I've Made

In Topic: Pulling my hair out over D3D11 lighting bug

09 December 2012 - 01:08 PM

Gotcha, so I guess that should explain why the light does not appear to be on the z-axis like it should be, it is instead a bit to the left.

When you say to send the world position to the pixel shader, do you mean in place of the one I'm already sending, or as an extra?

EDIT: Just updated my code and all of a sudden everything works like a charm! Thanks, dude, and thanks to the guy who first mentioned it, I was just too thick-headed to think about passing another position to the pixel buffer. I've definitely learnt my lesson about mixing world/view/proj spaces Posted Image That being said, is there a more elegant way to handle this instead of passing two positions?

In Topic: Pulling my hair out over D3D11 lighting bug

09 December 2012 - 12:28 PM

Thanks for the suggestions, especially the tip about using input.norm.xyz, I feel ignorant now. So, letting HLSL align the buffer automatically should be okay? My old code was float3 for the vertex shader input, but I got paranoid and switched to float4 Posted Image

Is it okay for the input position to be float3, since it can only be passed to the pixel shader as a float4? Should I always set the w-component to zero when I don't need it?

In Topic: Pulling my hair out over D3D11 lighting bug

08 December 2012 - 09:38 PM

I actually just discovered that if I move my light source a ridiculous distance away (z value of -5000.0) then it works properly. I'm cool with this, but I'm really curious as to why it would not work at a distance that should have given the object enough room, and of course I would like to be able to set my light position to normal values without having to multiply by 5000.

In Topic: Pulling my hair out over D3D11 lighting bug

08 December 2012 - 08:26 PM

I just added the two things you said in your first post, to make sure the normal is truly normalized at all steps. Unfortunately, it did not fix the bug. Could you further explain your last post concerning world space light position vs surface? In the simple lighting examples I've seen on the internet they have made no distinction between the different view spaces when doing lighting in the pixel shader, yet their lighting was displayed correctly.

Updated normal transform in vertex shader:
float4 tmp_norm = float4( input.norm.x, input.norm.y, input.norm.z, 0.0 );
output.norm = mul( tmp_norm , world_matrix );
output.norm = normalize( output.norm );

Updated normal declaration in pixel shader:
float4 norm_norm = normalize( input.norm );
float3 tmp_norm = float3( norm_norm.x, norm_norm.y, norm_norm.z );

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

14 September 2012 - 11:10 AM

Wow, those posts are way over my head Posted Image


Hi again,

To get back to your problem, in what spaces are light_vector and input.pos? Are they both in world space? The values you reported to see anything at all are indeed a little extreme. Posted Image
And yes, in theory the attentuation won't fall down to zero. In practice, however, you just cut it off somewhere.


inpus.pos is in world space (transformed in vertex shader), but the light_vector is just raw input, no transformations. Is that correct?

Here are the lighting equations I'm using, from the book "Mathematics for 3D Game Programming and Computer Graphics":



D = diffuse reflection color
A = ambient intensity (should this be a float or a float3?)
C = light attenuation * light_color
N = surface normal
L = normalized light vector



S = specular reflection color
C = light attenuation * light_color
R = 2*( N dot L )*N - L
V = camera vector
m = specular exponent
N = surface normal
L = normalized light vector

Here is the dropbox link to the model: https://www.dropbox....pl6jls/kit2.obj

PARTNERS