I am currently working on a renderer that involves deferred shading. In a previous iteration of my project, I was able to draw point lights as full screen quads. As an optimization, I am now drawing spheres to represent the light volumes. The only major change between my current version and the previous version is the vertex shader. The previous shader did nothing, it just passed through a pre-transformed quad to the pixel shader. The current version takes a unit sphere model, transforms, and projects it to the screen. I have confirmed that the screen space texture coordinates are being generated correctly. I have also confirmed that the samplers being used work correctly in other pixel shaders. The render target is valid, and it compiles properly. However, for some reason the tex2D function fails in my pixel shader now. This has me thoroughly confused: the inputs are identical (I've checked thoroughly). What would cause the behavior of tex2D to be inconsistent based on changing the vertex shader, if the outputs are identical? If anyone has a clue as to what is going wrong, please tell me! This is unbearably strange. Here is the vertex shader/pixel shader in offense: struct PS_INPUT_LIGHT { float3 vTex0 : TEXCOORD0; }; struct VS_OUTPUT_LIGHT { float4 vPos : POSITION0; float3 vTex0 : TEXCOORD0; }; VS_OUTPUT_LIGHT vsLighting(float4 pos : POSITION0) { VS_OUTPUT_LIGHT o; // scale the unit sphere out by the radius float4 newPos = float4(pos.xyz * lightRange, 1.0); // transform the position into world space newPos += float4(vLightPos.xyz, 0.0); // view/project newPos = mul(newPos, mViewProjection); o.vPos = newPos; // this offset is needed to correct DirectX's texture calculation // note - not currently in use: subject to further testing const float3 offset = float3(0.5/1024.0, 0.5/768.0, 0); // figure out texture coords from screen position // this is multiplied through by W // the division takes place AFTER interpolation o.vTex0 = float3((newPos.x+newPos.w)/2.0, (newPos.w-newPos.y)/2.0, newPos.w); return o; }; // psLighting() // uses data from textures (previous render targets) float4 psLighting(PS_INPUT_LIGHT i) : COLOR0 { // perform the homogeneous divide on the coords float2 texCoords = i.vTex0.xy/i.vTex0.z; // extract the position float w = tex2D(SceneDepthSampler, texCoords).r; float zp = (vPlanes.x*w + vPlanes.y); float2 screenPos = float2(texCoords.x*2.0-1.0, (texCoords.y*-2.0)+1.0); float4 projPos = float4(screenPos, zp,w); float4 worldPos = mul(projPos, mViewProjectionInverse); // find the light vector float4 pTol = vLightPos - worldPos; float distance = length(pTol); pTol = normalize(pTol); // extract the normal float3 vWorldNrm = tex2D(SceneNormalSampler, texCoords); // calculate lighting intensity float atten = 1.0-(distance)/lightRange; float dp = dot(pTol, vWorldNrm) * atten; float vDiffuseIntensity = saturate(dp); // write to the lighting accumulation buffer return vDiffuseIntensity * vLightDiffuse; }; technique lightAccumulation { pass p0 { VertexShader = compile vs_2_0 vsLighting(); PixelShader = compile ps_2_0 psLighting(); AlphaBlendEnable = True; SrcBlend = One; DestBlend = One; ZENABLE = false; ZWRITEENABLE = false; CULLMODE = none; } };

What do you mean that tex2D fails? Do you mean the shader doesn't compile? Is there an error during runtime? Does it run properly but outputs the wrong result?

Without knowing more details, the main thing to try is to run your applicaiton through PIX. This will allow you to verify all inputs/outputs to your shaders and let you step through them line by line.

Also, make sure you're running with the Debug Runtime enabled and check your debug spew to see if there are any errors or warnings related to this.

If all of that fails, try running your app with the reference rasterizer and see if you get the same results.

neneboricua

When I say that it fails, I mean that it compiles and runs, but the output of the tex2D function call is always black. I've definitely confirmed with PIX that the inputs to this function are valid. However, regardless of the input, it always returns float4(0,0,0,0)

As I said before, I made no change to the sampler or the inputs. I'm thinking that there is some external conflict that I'm not aware of. The only change from my working version is using a different vertex program. The output of this vertex program is identical to the original (confirmed visually and in PIX).

The pixel shader is capable of performing arithmetic operations and writing colors to the render target. The only thing that is wrong is the output from my call to tex2D.

Is there some dark corner of the API that I've seemed to wander into? Or perhaps a HLSL compiler bug?

Your shader isn't all that complicated so I doubt this is a shader compiler bug.

Make sure that the texture you're sampling contains the data you think it does. PIX lets you see the texture coordinates getting used. Look at those texture coordinates, then go to the view where your texture sampler is and find the exact texture coordinates and look at the color stored there. Make sure your texture coordinates are what you expect them to be. Perhaps the texture coordinates are outside the range of [0..1] and your texture addressing mode is set to border color or clamp. If the border color is set to black or the edge of the texture happens to be black, that would explain your results.

neneboricua