8 replies to this topic

[Believe82]

Hey guys, I just recently started developing my game that i had put on the side for a lengthy time due to school.


I am currently working on lighting. For my lighting model, i have a animated polygon that I use as my "space ship". The goal of this model to have a light be positioned
at the "center" of my ship, so whenever i moved around my terrain, it would light up a small area around my ship. I had implemented point lights, and i thought this would
be as easy as making the position of the light the position of my ship.

(Some information about my lighting model)
- I have a camera implemented that is positioned behind my ship to give my game a "3rd person view"
- The camera's position is used as the position of the "eye"
- The camera's eye and position are used to make the view matrix, that computes the world matrix, as well as the world view projection matrix *********** This ones important

When i implemented this lighting model, at first i observed some strange effects, whenever i moved my ship (later i found out it was the camera) the light would move in
unusual ways. Such as when i would turn my camera the light would begin exponentially increasing in distance. Also the light would eventually out run my ship (light would be positioned further in front of my ship) or behind depending on the direction of my ship when i move a certain distance.

After a bit of debugging i learned that my camera's view matrix was affecting my point lights. For example at initialization i made the position of the point light equal to the position of my ship, i would never update the position of the point light. But as i moved my ship the point light would follow my ship around EXACTLY how i wanted it to begin with. This i guess "technically" is a solution to my problem, and works but i don't think in an actual game lights would be implemented in this way, and I would like to know a better or "THE" solution to my problem. Well I dont want to be given a solution rather if someone can point me in the right direction.

I was hoping someone could point me in the right direction as to how I should go about implementing my point lights so that my camera's view matrix that calculates the world matrix and world view projection matrix do not affect my point lighting system, and the light position will always be the position of my ship instead of being skewed whenever i moved my camera.

If you would like additional information or code or screen shots let me know, I'll be glad to post them. I would spend more time working on this, but I have a lot of other priorities at the moment such as assignments, finals coming up and interviews so i apologize if i'm not trying hard enough.

Thanks for any help!

[MJP]

Are you using shaders to implement your lighting?

[Believe82]

Hi, thanks for the response

Yes i am using HLSL to implement my lighting, I only specifiy the position of the light outside of the shader.
Here is the shader function that computes the pointlight color

float3 PointLight( SurfaceInfo sInfo, Light light, float3 eyePos )
{
	float3 lightColor = (0.0f, 0.0f, 0.0f );

	//vector from surface to the light
	float3 lightVector = light.pos - sInfo.pos;

	//distance from surface to the light
	float distance = length( lightVector );

	if( distance > light.range )
		return float3( 0.0f, 0.0f, 0.0f );

	//normalize the light vector, i used /= here because it is the same as normalizing it without calling normalize(lightVector)
	lightVector /= distance;

	//add the ambient light term
	lightColor += sInfo.diff * light.amb;

	//add diffuse and specular terms provided the surface is in the line of sight of the light
	float diffuseFactor = dot( lightVector, sInfo.normal );
	[branch]

	if( diffuseFactor > 0 )
	{
		float specularPower = max( sInfo.spec.a, 1.0f );
		float3 toEye = normalize( eyePos - sInfo.pos );
		float3 R = reflect( -lightVector, sInfo.normal );
		float specFactor = pow( max( dot(R, toEye), 0.0f), specularPower );

		lightColor += diffuseFactor * sInfo.diff * light.diff;
		lightColor += specFactor * sInfo.spec * light.spec;
	}

	//attenuate
	return lightColor / dot( light.att, float3( 1.0f, distance, distance*distance ) );
}

eyePos is the world position of the camera
surface info is the information of the surface of the terrain
diff is diffuse term, amb is ambient term, spec is specular term

In my main code all i am doing is setting the position of the point light to the position of my ship

If you would like additional information / screenshots i'd be happy to provide

Thanks for the help!

[phil_t]

Hmm, I would think you could just make your point light position be equal to the ship's world position every frame.

[Believe82]

Hmm, I would think you could just make your point light position be equal to the ship's world position every frame.

I thought so too, and tried that before, but I think because my camera's view which is the eye position that calculates the view matrix, every time i move my camera it effects the position of the point light. I was just thinking about solutions where i could move the camera but not have it effect my lighting model.

One solution is to just set the light position to be the position of the ship at initialization then never touching it again. This actually works because my camera moves at the same speed as my ship in all directions, so the point light is always positioned at my ship. I just personally do not think this is a very good solution for bigger lighting models, so i was looking for more solutions, such as should I have a seperate view matrix or something.

Thank you for the replies!

[MJP]

It sounds like you're mixing up coordinate spaces somewhere. With lighting you need to make sure you're consistent, so if you're going to do lighting in world space you need to make sure the light position + surface position + normals + eye position are all in world space.

[Believe82]

It sounds like you're mixing up coordinate spaces somewhere. With lighting you need to make sure you're consistent, so if you're going to do lighting in world space you need to make sure the light position + surface position + normals + eye position are all in world space.

Thanks, this is what i was thinking towards, I'll look into it next time i code my game and post my solution when i find it.

[Believe82]

Hey,
I've solved my problem, and I came here to just post the solution. I originally had thought the problem lied in me mixing up my coordinate spaces and thanks to MJP I looked deeper into my coordinate spaces. After looking around I saw this piece of code,

m_fxWorldVar->SetMatrix( (float*) &m_WVP );

I was setting my world matrix to be identical to my world view projection matrix, which i set using

m_fxWVPVar->SetMatrix( (float*) &m_WVP);

So I figured when i was lighting up my terrain I was using the wrong coordinate system, so I set a separate coordinate system for my terrain, and used

 for( UINT p = 0; p < techDesc.Passes; p++ )
{
   	m_fxWorldVar->SetMatrix( (float*) &m_land );
   	... Apply the technique pass
   	... Draw

Then set my point light to be the position of my ship,

everything works great!

I have a few questions I was hoping someone could clarify for me though, any replies would be great!

I'm a little confused about the technique pass, so i use a EffectTechnique to obtain a technique from my shader, and the different passes are the different INPUT - OUTPUT such as position - World position, normal - World normal etc...
- Is the pixel shader involved in the technique pass? Or is just the vertex shader involved in the technique passing and through the vertex shader outputs the pixel shader can determine the correct color of my pixels

Or is the technique pass just to pass and compile the input through the vertex shader, geometry shader, and pixel shader?

Or am i just wrong altogether lol

[Endemoniada]

A technique can have both the vertex and pixel shader.

The techniques are just a way to keep things tidy, so instead of using four similar shaders you can put them all in one shader file and make four techniques. Don't confuse techniques with passes.

Take a look at some of the simpler nVidia HLSL shaders to see how they are structured, it's the best way to learn.