# [DX9] Issues with lighting

This topic is 2654 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello everyone

At the moment im using an approach to light my terrain using normals independent of what is around every pixel. Over all this gives nice results but i face a problem when my sun is below the horizon. As the normals of hills still give a positive dot product they are still lit even if the sun has no chance to reach them.

See this image:
http://imagr.eu/up/4d78e0bc1e3b70_Light.jpg

Are there methods to prevent that? And if so which could be applied to my situation where the terrain is rendered by small patches?

Its the first time i make any lighting inside one of my projects so dont even know where to start looking at

Greetings and thanks
Plerion

##### Share on other sites
You're basically talking about shadowing I'm afraid! It's not exactly straightforward to implement but there is quite a lot of information out there. Two popular techniques are shadow mapping and stencil shadows.

I'd start with the DX sample ShadowMap and see if you can figure it out from there.

##### Share on other sites
If you're looking for a very simple implementation, you can check the light direction before you render. If the sun has "set," disable lighting from that source. E.g., if the Y-axis is "up," and lightDirection.y > 0 (pointing in the "up" direction), disable lighting. Alternatively, if you're using a shader, you can set a boolean useLight (true or false) depending on your direction test.

##### Share on other sites
Is stencil shadows comparable to shadow volumes? I was thinking about shadows already but thought it may give not the desired results but after being outside a bit and observing what the sun does ive come to the conclusion that shadows may be what i need! Ive already used shadows volumes but im not sure if thats the best thing to use here. If so thats what i would do:

1. Generate the shadow volumes using the common algorithm

2. Use the resulting screen shadow as a resource in the shader in the final draw call

3. Sample for every pixel a quad of data (to avoid hard borders) of shadows and apply that

May there be easier solutions for that?

##### Share on other sites

Is stencil shadows comparable to shadow volumes? I was thinking about shadows already but thought it may give not the desired results but after being outside a bit and observing what the sun does ive come to the conclusion that shadows may be what i need! Ive already used shadows volumes but im not sure if thats the best thing to use here. If so thats what i would do:

1. Generate the shadow volumes using the common algorithm

2. Use the resulting screen shadow as a resource in the shader in the final draw call

3. Sample for every pixel a quad of data (to avoid hard borders) of shadows and apply that

May there be easier solutions for that?

Stencil shadows is just another name for shadow volumes. You could certainly use them in the way you propose, but a lot of people avoid them because they tend not to scale very well with geometric complexity and can use a ton of fillrate for certain scenes, light directions, and camera angles. But I'm sure you'd be fine if you just want to implement it and then re-evaluate the situation later on.

##### Share on other sites
Hm, ok, thats a good point. I dug a bit into shadow volumes but im now facing either a problem of comprehension or a real problem in my situation. Lets say my sun is at a position and my camera looks in an angle 90° relative to the sun direction. Now looking the scene from the suns position is yields a completely different view frustum then watching the scene from my camera. So to get the depth data for all pixels that are rendered in my actual scene but also taking all the objects into calculation that may throw a shadow onto my scene should i render from the suns point of view into my shadow map the union of both view frustums?

##### Share on other sites
Ok, i was able to "reduce" my problems to the question how wide and high i have to make my orthogonal matrix for the sun light. It should basically cover all the regions the camera sees at the moment. Is there a way to determine the correct width and height of the orthogonal matrix from my perspective projection and view matrix of the cameras matrix?

##### Share on other sites

Ok, i was able to "reduce" my problems to the question how wide and high i have to make my orthogonal matrix for the sun light. It should basically cover all the regions the camera sees at the moment. Is there a way to determine the correct width and height of the orthogonal matrix from my perspective projection and view matrix of the cameras matrix?

I'm not 100% sure if this would help your situation, but the frustum dictacted by the view matrix(google extracting clipping planes from a view matrix) CAN be used to get points of it's 5(or 8) corner vertices, which could be transformed into the appropriate space to get a height and width from.

I'd personally wait until someone else weighs in before running wild with this....

##### Share on other sites
Thats a good point! Calculating the frustum corners is easy and using the lights view matrix i can move them to light space which will let me determine the size!

Ive started implementing it but im facing a problem with depth rendering. I use the following HLSL code:
 PixelInputShadow TerrainVSShadow(float4 PositionIn : POSITION) { PixelInputShadow ret = (PixelInputShadow)0; ret.Position = mul(PositionIn, worldViewProj); ret.Position2D = ret.Position.zw; return ret; } float4 TerrainPSShadow(float4 Position : POSITION, float2 Position2D : TEXCOORD0) : COLOR0 { return (Position2D.x / Position2D.y); } 

According to what i think i know z / w should yield a value between 0 and 1 depending on the distance from the point to the two clipping planes. Well, when i render that i cannot see anything like that, the full scene is completely white even points that are on opposite clipping planes have the same white color. Did i misunderstand something?

##### Share on other sites

Thats a good point! Calculating the frustum corners is easy and using the lights view matrix i can move them to light space which will let me determine the size!

Ive started implementing it but im facing a problem with depth rendering. I use the following HLSL code:
 PixelInputShadow TerrainVSShadow(float4 PositionIn : POSITION) { PixelInputShadow ret = (PixelInputShadow)0; ret.Position = mul(PositionIn, worldViewProj); ret.Position2D = ret.Position.zw; return ret; } float4 TerrainPSShadow(float4 Position : POSITION, float2 Position2D : TEXCOORD0) : COLOR0 { return (Position2D.x / Position2D.y); } 

According to what i think i know z / w should yield a value between 0 and 1 depending on the distance from the point to the two clipping planes. Well, when i render that i cannot see anything like that, the full scene is completely white even points that are on opposite clipping planes have the same white color. Did i misunderstand something?

Whats the format of the render target your rendering the depth into?

• 35
• 12
• 10
• 9
• 9
• ### Forum Statistics

• Total Topics
631358
• Total Posts
2999530
×