Thread: [PyOpenGL-Users] Shader Function Problems
Brought to you by:
mcfletch
From: Ian M. <geo...@gm...> - 2009-04-19 20:34:05
|
Hi, I finally got some sort of error checking working for ATI cards. The errors are weird. glGetShaderInfoLog(...) for each part of the program spits out: Vertex shader was successfully compiled to run on hardware. Fragment shader was successfully compiled to run on hardware. But strangely, glGetInfoLogARB(...) spits out: Fragment shader(s) failed to link, vertex shader(s) linked. Fragment Shader not supported by HW Needless to say, it crashes later on glUseProgramObjectARB(...) with an 'invalid operation'. These problems occur when certain functions are called in my program. Here's a function that causes such an error: float diffuse_coefficient(int lightnum) { vec3 l = normalize(gl_LightSource[lightnum].position.xyz-vVertex); return max(dot(normal,l),0.0); } My ideas: vVertex is a varying vec3. Could this be the problem? is max(dot(normal,l),0.0) too much for one line? I saw something about ALU limits. I don't know if this qualifies. Any other ideas? What's going on here? How can I make this work? Ian |
From: Mike C. F. <mcf...@vr...> - 2009-04-20 04:09:12
|
Ian Mallett wrote: ... > But strangely, glGetInfoLogARB(...) spits out: > > > > Fragment shader(s) failed to link, vertex shader(s) linked. > Fragment Shader not supported by HW > > Needless to say, it crashes later on glUseProgramObjectARB(...) with an 'invalid operation'. Yeah, saw the same with my ATI Radeon 3650, I wound up using both glGetInfoLog and glGetProgramInfoLog and found that with both I'd normally get some description of a failure, but that the shaders would pass validation (i.e. the first programmatic indication of the error was on the invalid operation error). For OpenGLContext's shader support I wound up doing a try:except around the glUseProgram call and if there's a GL error raised I print all of the logs for all of the linked components as well as the program's logs. > These problems occur when certain functions are called in my program. Here's a function that causes such an error: > > > > float diffuse_coefficient(int lightnum) { > vec3 l = normalize(gl_LightSource[lightnum].position.xyz-vVertex); > return max(dot(normal,l),0.0); > } > > My ideas: > vVertex is a varying vec3. Could this be the problem? Doesn't look like a problem to me, I seem to recall using varying vectors in such ways many times. > is max(dot(normal,l),0.0) too much for one line? I saw something > about ALU limits. I don't know if this qualifies. I'd be surprised if that went over any limit, I've certainly written more complex calculations. Sorry I don't have more help to offer here. Might want to check that lightnum is the proper value? Also, stupid question, where'd you get "normal" there? I don't see it in my handy GLSL quickref. Is it from some outer scope (or an attribute/uniform)? HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Ian M. <geo...@gm...> - 2009-04-20 04:12:41
|
Yea, normal is custom defined. I'm working on a fix which works, I think. The problem was with sending variable ints to gl_LightSource[n]. |