GLSL display and compilation problems
Hi there,
I'm having troubles with my shader. I took the code from the Point light per pixel lighting tutorial (lighthouse3d : http://www.lighthouse3d.com/opengl/glsl/index.php?pointlight), and I added a few simple things.
I added 1 uniform and 2 varyings in each program. -> Here no problem yet.
Then I added a simple line of code (float v = 0.5 * (1.0 + dot(normalize(vViewVec), vNormal));), these are the 2 varyings and v is not used in the program after this line. -> And here the problems begin :
- on my nvidia 7800GT card (with lastest drivers 93.71, anyway I don't think it would change anything) : it doesn't compile : error C5041: cannot locate suitable resource to bind parameter "dist"
- if I change the order of the varyings declaration, the "dist" is another variable name !
- on my ati 9600 pro card : it does compile but it does change the color of everything ! That's really weird since the 'v' variable is not used at all ...
Here are screenshots without and with the problematic code line :
http://reverse-thegame.com/system/files/images/shader-ok.png
http://reverse-thegame.com/system/files/images/shader-bug.png
And finaly here is the code :
- vertex program : http://rafb.net/p/IJk7qX84.html
- fragment program : http://rafb.net/p/rD8if871.html
If you want to test you just need to create the corresponding resources for the uniforms : a vec4 named view_position and a 2D texture named Tex.
I'm really stuck with this. Do you think I have too many varyings ? I don't think so. But anyway on 2 different cards it's causing problems :/
Thank you for your help !
I piped both of your shaders through GLSL Validator ( available here ) and they both pass ok, so it appears to be valid code.
You do have a lot of varying vars though - you might want to check glGet(GL_MAX_VARYING_FLOATS_ARB). However IIRC the minimum for this value is 32, and you've got the equivilent of 28 floats so it should be ok.
However vec3 vars are likely to result in unaligned data, so if they're internally being rounded up to vec4 instead, then you've actually got 33 varyings. I'm guessing this is what the nvidia drivers are doing. IMHO that behaviour would be a bug, but for a temporary workaround you could try packing 'dist' as the alpha of your normal or something equally hideous.
I have no idea what the ati driver is actually doing, but I wouldn't be surprised if it was also going over the varying limit.
You do have a lot of varying vars though - you might want to check glGet(GL_MAX_VARYING_FLOATS_ARB). However IIRC the minimum for this value is 32, and you've got the equivilent of 28 floats so it should be ok.
However vec3 vars are likely to result in unaligned data, so if they're internally being rounded up to vec4 instead, then you've actually got 33 varyings. I'm guessing this is what the nvidia drivers are doing. IMHO that behaviour would be a bug, but for a temporary workaround you could try packing 'dist' as the alpha of your normal or something equally hideous.
I have no idea what the ati driver is actually doing, but I wouldn't be surprised if it was also going over the varying limit.
Thanks, it's working by reducing the number of varyings.
I thought we could pass more than 32 float but ... :/
I thought we could pass more than 32 float but ... :/
beware inbuilt varyings eg gl_TexCoord[0] count as 4 varying floats
perhaps use
varying vec2 tc = gl_MultiTexCoord0.xy;
+ could reduce the light vars from 4 to 3 numbers as u dont need alpha, also u could perhaps cobine some eg ambient + ambientglobal
perhaps use
varying vec2 tc = gl_MultiTexCoord0.xy;
+ could reduce the light vars from 4 to 3 numbers as u dont need alpha, also u could perhaps cobine some eg ambient + ambientglobal
I've had this problem myself and just want to add what I found out:
The GLSL compiler can pack, floats and vec2s/vec3s into vec4s, but with old drivers / cards a single float might use a full vec4 interpolator. (e.g. doing the packing yourself might be safer)
gl_Position does not count against the varying limit.
gl_FrontColor and gl_BackColor _usually_ don't count against the varying limit, atleast on GF6+ and "some"(?) ATI cards (can't test it), so you can actually pass more than 32 varying floats if you use those, even if that's not what the GLSL specs say.
The GLSL compiler can pack, floats and vec2s/vec3s into vec4s, but with old drivers / cards a single float might use a full vec4 interpolator. (e.g. doing the packing yourself might be safer)
gl_Position does not count against the varying limit.
gl_FrontColor and gl_BackColor _usually_ don't count against the varying limit, atleast on GF6+ and "some"(?) ATI cards (can't test it), so you can actually pass more than 32 varying floats if you use those, even if that's not what the GLSL specs say.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement