Horde3D http://horde3d.org/forums/ |
|
A couple issues with the new shader system http://horde3d.org/forums/viewtopic.php?f=3&t=669 |
Page 1 of 1 |
Author: | ecksp [ 18.03.2009, 03:58 ] |
Post subject: | A couple issues with the new shader system |
I've bumped into a couple problems with the new shader system. First is having a [ in a comment in the glsl code causes the engine to stop reading code. I assume it sees the [ and think it's the start of a new section. Example code: Code: uniform vec4 color; void main(void) { // a [ comment gl_FragColor = color; } When using EngineOptions::DumpFailedShaders the dumped shader stops at the 'a' in the comment. I imagine the same thing will happen when using arrays in code although I haven't tested that. Second issue is that the uniform declared in the FX section always overrides whatever is set in the material. For instance if you put <Uniform name="color" a="1.0" b="0.0 c="0.0" d="1.0" /> in the material and <Uniform id="color" a="0.0" b="0.0" c="1.0" d="1.0" /> in the shaders FX section the color used will be blue. From the documents it sounds like the values set in the shader should only be used when it hasn't previously been set in the material. Finally, and this is really just a nitpick rather than a bug, it would probably make sense to have uniforms set in the material use an 'id' attribute rather than 'name' to name the variable since everywhere else a name is needed it's with an 'id' attribute. I think this would make things a little more... uhm... uniform |
Author: | marciano [ 19.03.2009, 23:26 ] |
Post subject: | Re: A couple issues with the new shader system |
Thanks for your feedback! The [ in comments is easy to fix: egShader.cpp, line 577: while( *pData != '\0' && !(*pData == '[' && *(pData+1) == '[') ) ++pData; The engine would still see a new section start in that case: // comment [[ comment But I think that is ok since a section start is just defined as [[ and does not require the [[ to be after a line break. I tried to set hdrParams in postHDR.shader to some values and set different values in postHDR.material.xml and everything seems to work fine. If you don't specify any values in the shader, they are automatically initialized with zero, so according to your statement setting the material uniforms should never work which is not the case. Are you sure that there is some bug? Concerning the id/name issue: Actually I was thinking about using id instead of name. But usually I use id when a new variable is declared which is the case in the shader. In the material that declared variable is just referenced, that's why name is used here. Does that make sense to anyone else than me? |
Author: | ecksp [ 20.03.2009, 04:47 ] |
Post subject: | Re: A couple issues with the new shader system |
marciano wrote: The [ in comments is easy to fix: Yeah, I figured it would be a quick fix. I was mainly concerned about the effect it would have when using arrays. I only mentioned it in relation to comments because that's where the problem popped up for me. 3 cheers for EngineOptions::DumpFailedShaders marciano wrote: Are you sure that there is some bug? Take the following material and shader as an example. Code: <Material> <Shader source="shaders/plain.shader" /> <Uniform name="color" a="1.0" b="1.0" c="1.0" d="1.0" /> </Material> Code: [[FX]] <Uniform id="color" a="0.0" b="1.0" c="0.0" d="1.0" /> <Context id="AMBIENT"> <Shaders vertex="VS_general" fragment="FS_ambient"/> </Context> [[VS_general]] #include "shaders/utilityLib/vertCommon.glsl" void main(void) { gl_Position = gl_ModelViewProjectionMatrix * calcWorldPos(gl_Vertex); } [[FS_ambient]] uniform vec4 color; void main(void) { gl_FragColor = color; } When I use this the color applied to the object is green as set in the shader rather than white as set in the material. If I instead just use the defaults in the shader (<Uniform id="color" />) then the object is black. marciano wrote: Concerning the id/name issue: Actually I was thinking about using id instead of name. But usually I use id when a new variable is declared which is the case in the shader. In the material that declared variable is just referenced, that's why name is used here. Does that make sense to anyone else than me? Well, that makes sense but personally I still would have used id in the material |
Page 1 of 1 | All times are UTC + 1 hour |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |