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
|