On Feb 17, 2006, at 1:17 PM, chris clepper wrote:
Got it. The uniform was not being set properly in my patch. Now I get the blur, but linking is not always working the first time through.
...cool! The way the patch is set-up, the user must hit the link button once the shaders are loaded; and another caveat is that the shader ID's will only be sent to [glsl_program] after a render cycle...then and only then will you get a properly linked shade program...
On 2/17/06, chris clepper cgclepper@gmail.com wrote:
Some more info:
There are three outlets for glsl_fragment and in these patches the middle one is connected to the shader number message for glsl_program. That middle outlet never changes but the right one does. I connected that up and now get varying output from the shader (although it still doesn't work):
link 2 progs attach object 0 attach object 1 getting 722 chars for infolog GEM: [glsl_program]: Info_log: ERROR: Fragment shader reads varying 'texCoord0' which is not written since there is no vertex shader. ERROR: Fragment shader reads varying 'texCoord1' which is not written since there is no vertex shader. ERROR: Fragment shader reads varying 'texCoord2' which is not written since there is no vertex shader. ERROR: Fragment shader reads varying 'texCoord3' which is not written since there is no vertex shader. ERROR: Fragment shader reads varying 'texCoord4' which is not written since there is no vertex shader. ERROR: Fragment shader reads varying 'texCoord5' which is not written since there is no vertex shader. ERROR: Fragment shader reads varying 'texCoord6' which is not written since there is no vertex shader.
GEM: [glsl_program]: Link failed!
After that I load the shaders again and get this:
[glsl_vertex]: Loaded file: /Users/schwartz/Desktop/gaussBlurGLSL/ gaussBlur.vert [glsl_fragment]: Loaded file: /Users/schwartz/Desktop/gaussBlurGLSL/gaussBlur.frag link 2 progs attach object 0 attach object 1 getting 0 chars for infolog [glsl_program]: vertex shader running in hardware [glsl_program]: fragment shader running in hardware
I have a 256x256 file and pix_texture in mode 0. Any ideas?
cgc
On 2/17/06, chris clepper cgclepper@gmail.com wrote:
No joy here. It looks like the fragment shader is not loading properly:
[glsl_fragment]: Loaded file: /Users/schwartz/Desktop/gaussBlurGLSL/gaussBlur.frag link 2 progs attach object 0 attach object 1 getting 722 chars for infolog GEM: [glsl_program]: Info_log: WARNING: Vertex shader writes varying 'texCoord0' which is not read since there is no fragment shader. WARNING: Vertex shader writes varying 'texCoord1' which is not read since there is no fragment shader. WARNING: Vertex shader writes varying 'texCoord2' which is not read since there is no fragment shader. WARNING: Vertex shader writes varying 'texCoord3' which is not read since there is no fragment shader. WARNING: Vertex shader writes varying 'texCoord4' which is not read since there is no fragment shader. WARNING: Vertex shader writes varying 'texCoord5' which is not read since there is no fragment shader. WARNING: Vertex shader writes varying 'texCoord6' which is not read since there is no fragment shader.
...what this is telling us is that there is no fragment shader loaded: actually, you may have loaded a shader, but [glsl_program] isn't receiving the correct shaderObject ID...last night I fixed a bug in [glsl_fragment] which caused multiple outlet's to be produced, and only one of them actually output the correct ID: this is fixed in cvs...
[glsl_program]: vertex shader running in hardware [glsl_program]: fragment shader running in hardware
There's no ouput in the gemwin at all.
...well, because you don't have a valid fragment shader to match your vertex shader, I wouldn't imagine anything would be output...but then, make sure you are just using square movies (256x256 or the like), and make sure that [pix_texture] is operating in [mode 0<
The interface for GLSL in GEM is not exactly user friendly either. I wouldn't expect very many people to figure this out and get a shader working in their own patches (myself included apparently).
...yeh, right now it's a little too close to the metal...but I have had some thoughts about how to ease it up, perhaps thru using an abstraction that just takes one name and auto loads/creates/links the .vert and .frag, and then auto creates a message for whatever uniform variables...
...just haven't gotten there, yet...
jamie