像素着色器奇怪的编译错误
我正在使用着色器，但我不断收到这个奇怪的编译错误，这让我发疯！
以下像素着色器代码片段：
DirectionVector = normalize(f3LightPosition[i] - PixelPos);
LightVec = PixelNormal - DirectionVector;
// Get the light strenght factor
LightStrFactor = float(abs((LightVec.x + LightVec.y + LightVec.z) / 3.0f));
// TEST!!!
LightStrFactor = 1.0f;
// Add this light to the total light on this pixel
LightVal += f4Light[i] * LightStrFactor;
工作完美，但是一旦我删除“LightStrFactor = 1.0f;”行，即让 'LightStrFactor ' 值作为上面计算的结果，它无法编译着色器。
LightStrFactor 是一个浮点数 光值f4Light[i] 是 float4 其余的都是float3。
我的问题是，除了为什么它不能编译之外，DX编译器为什么关心浮点数的值？即使我的值不正确，它不应该是运行时吗？ 着色器编译代码是这样的：
/* Compile the bitch */
if (FAILED(D3DXCompileShaderFromFile(fileName, NULL, NULL, "PS_MAIN", "ps_2_0", 0, &this->m_pCode, NULL, &this->m_constantTable)))
GraphicException("Failed to compile pixel shader!"); // <-- gets here :(
if (FAILED(g_D3dDevice->CreatePixelShader( (DWORD*)this->m_pCode->GetBufferPointer(), &this->m_hPixelShader )))
GraphicException("Failed to create pixel shader!");
this->m_fLoaded = true;
任何帮助表示赞赏 谢谢！！！ :]
I'm experiencing with shaders a bit and I keep getting this weird compilation error that's driving me crazy!
the following pixel shader code snippet:
DirectionVector = normalize(f3LightPosition[i] - PixelPos);
LightVec = PixelNormal - DirectionVector;
// Get the light strenght factor
LightStrFactor = float(abs((LightVec.x + LightVec.y + LightVec.z) / 3.0f));
// TEST!!!
LightStrFactor = 1.0f;
// Add this light to the total light on this pixel
LightVal += f4Light[i] * LightStrFactor;
works perfectly, but as soon as i remove the "LightStrFactor = 1.0f;" line, i.e. letting 'LightStrFactor ' value be the result of the calculation above, it fails to compile the shader.
LightStrFactor is a float
LightVal & f4Light[i] are float4
All the rest are float3.
my question is, besides why it doesn't compile, is how come DX compiler cares about the value of a float? even if my values are incorrect, shouldn't it be run-time?
the shader compilation code is this:
/* Compile the bitch */
if (FAILED(D3DXCompileShaderFromFile(fileName, NULL, NULL, "PS_MAIN", "ps_2_0", 0, &this->m_pCode, NULL, &this->m_constantTable)))
GraphicException("Failed to compile pixel shader!"); // <-- gets here :(
if (FAILED(g_D3dDevice->CreatePixelShader( (DWORD*)this->m_pCode->GetBufferPointer(), &this->m_hPixelShader )))
GraphicException("Failed to create pixel shader!");
this->m_fLoaded = true;
any help is appreciated
thanks!!! :]
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不要忘记着色器在编译时会进行很多优化。这可能就是为什么当您对值进行硬编码时它不会失败的原因。
当您在为一个值分配一个方程后立即对其进行硬编码时，整个方程会得到优化，并且您只留下最终的分配。
Don't forget that shaders get optimized a lot when they are being compiled. This might be why it doesn't fail when you hardcode the value.
When you hardcode a value right after assigning it an equation, the whole equation gets optimized out and you are left out only with the final assignation.
像素着色器不支持 C++ 风格的转换——示例中的
float(...)。由于它完全多余，您可以删除它，但如果您想要强制转换，请像 C 中那样使用(float)Pixel shaders don't support C++-style casts -- the
float(...)in youre example. Since its completely redundant, you can just get rid of it, but if you want a cast, use(float)as in C从您的着色器片段来看，您似乎正在迭代许多灯光，累积它们的贡献。
我的猜测是，当编译器使用实际的光着色计算展开循环时，编译的着色器使用的算术指令槽多于 ps_2_0 配置文件支持的算术指令槽（最多 64 条指令）。
当您用 LightStrFactor=1 替换计算时，编译器会完全优化掉其前面的三行代码，这会导致您的测试着色器显着缩短，从而适合分配的 64 条指令。
如果您的应用程序硬件目标可能，只需更改着色器配置文件版本即可让您的着色器使用更多指令槽，并且编译时不会出现错误。 ps_3_0 / ps_2_a / ps_2_b 中的任何一个都应该能够编译您的着色器。 （2_a/b 配置文件有点混蛋，但受到官方支持，是基本 2_0 配置文件的 NV/ATI 扩展）
（正如另一个回复中提到的，花时间捕获和打印编译错误将是非常值得的。）
From your shader snippet, it looks like you're iterating through a number of lights, accumulating their contribution.
My guess would be that when the compiler unrolls the loop with your actual light shading calculations, the compiled shader uses more arithmetic instruction slots than the ps_2_0 profile supports (max 64 instructions).
When you replace the calculations with LightStrFactor=1, the compiler completely optimizes away the three code lines preceding it, which results in your test shader being significantly shorter, and hence fitting inside the allotted 64 instructions.
If possible for your application hardware target, simply bumping the shader profile version will allow your shader to use more instruction slots, and compile without errors. Any of ps_3_0 / ps_2_a / ps_2_b should be able to compile your shader. (The 2_a/b profiles being sorta bastard, but officially supported, NV/ATI extensions to the base 2_0 profile)
(As mentioned in another reply, taking the time to capture and print the compilation errors will be well worth your while.)