Hey all,
Now that I have Gem actually compiling again on my linux machine I wonder if my dream of a realtime blur could be a reality with pixelshaders. :) Anyhow know of some extreme blurring I can apply as a pixelshader to a texture loaded in gem?
Thanks Johannes for the help with the Gem compile. I remember why I needed to recompile it, to test the v4l2 support. I'll do that today and report back.
.b.
On Feb 16, 2006, at 11:07 AM, B. Bogart wrote:
Now that I have Gem actually compiling again on my linux machine I wonder if my dream of a realtime blur could be a reality with pixelshaders. :) Anyhow know of some extreme blurring I can apply as a pixelshader to a texture loaded in gem?
...sure, this should be trivial, but then why not use [pix_convolve]? A gaussian blur is just a certain kind of kernal:
http://homepages.inf.ed.ac.uk/rbf/HIPR2/gsmooth.htm http://www.ozone3d.net/tutorials/image_filtering.php
...as this last page shows, a simple gaussian blur is: #define KERNEL_SIZE 9
// Gaussian kernel // 1 2 1 // 2 4 2 // 1 2 1 const float kernel[KERNEL_SIZE] = { 1.0/16.0, 2.0/16.0, 1.0/16.0, 2.0/16.0, 4.0/16.0, 2.0/16.0, 1.0/16.0, 2.0/16.0, 1.0/16.0 };
...and you can easily do this with [pix_convolve], which is altivec accelerated on osx (tho it has edge problems...)
jamie
On Thu, 16 Feb 2006, james tittle wrote:
...as this last page shows, a simple gaussian blur is: #define KERNEL_SIZE 9 // Gaussian kernel // 1 2 1 // 2 4 2 // 1 2 1 const float kernel[KERNEL_SIZE] = { 1.0/16.0, 2.0/16.0,
At that level of detail (3 by 3) there isn't much to distinguish a gaussian blur from many other kinds of blur. Fortunately, the more you compose any blur with any blur, the closer you get to a gaussian blur. That's like, the biggest theorem in probability theory, which could as well be called "theory of blurred values".
i just mean that i wouldn't call the above "gaussian" but it can be close enough. Note that the above is the result of doing twice a 2x2 blur with the kernel 1 1 1 1.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Not tested in GEM but this is working GLSL code from ATI for a type of Gaussian effect:
vertex shader:
varying vec2 texCoordM; varying vec2 texCoordB0; varying vec2 texCoordF0; varying vec2 texCoordB1; varying vec2 texCoordF1; varying vec2 texCoordB2; varying vec2 texCoordF2;
void main(){ gl_Position = gl_Vertex; vec2 texCoord = gl_MultiTexCoord0.xy;
vec2 invSize = vec2 (0.99);
texCoordM = texCoord; texCoordB0 = texCoord - invSize; texCoordF0 = texCoord + invSize; texCoordB1 = texCoord - invSize * 2.0; texCoordF1 = texCoord + invSize * 2.0; texCoordB2 = texCoord - invSize * 3.0; texCoordF2 = texCoord + invSize * 3.0; }
fragment shader:
uniform sampler2D Image;
varying vec2 texCoordM; varying vec2 texCoordB0; varying vec2 texCoordF0; varying vec2 texCoordB1; varying vec2 texCoordF1; varying vec2 texCoordB2; varying vec2 texCoordF2;
void main(){ vec4 sampleM = texture2D(Image, texCoordM); vec4 sampleB0 = texture2D(Image, texCoordB0); vec4 sampleF0 = texture2D(Image, texCoordF0); vec4 sampleB1 = texture2D(Image, texCoordB1); vec4 sampleF1 = texture2D(Image, texCoordF1); vec4 sampleB2 = texture2D(Image, texCoordB2); vec4 sampleF2 = texture2D(Image, texCoordF2);
gl_FragColor = 0.1752 * sampleM + 0.1658 * (sampleB0 + sampleF0) + 0.1403 * (sampleB1 + sampleF1) + 0.1063 * (sampleB2 + sampleF2); }
Post back a working patch if you get one going. Good luck!
cgc
On 2/16/06, B. Bogart ben@ekran.org wrote:
Hey all,
Now that I have Gem actually compiling again on my linux machine I wonder if my dream of a realtime blur could be a reality with pixelshaders. :) Anyhow know of some extreme blurring I can apply as a pixelshader to a texture loaded in gem?
Thanks Johannes for the help with the Gem compile. I remember why I needed to recompile it, to test the v4l2 support. I'll do that today and report back.
.b.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On 2/16/06, chris clepper cgc@humboldtblvd.com wrote:
Not tested in GEM but this is working GLSL code from ATI for a type of Gaussian effect:
I can't get this working using the current CVS glsl objects, but it works fine in Shader Builder.
[glsl_fragment]: Loaded file: /Users/schwartz/Desktop/shaders/glsl_gauss.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
Nothing visible happens to the texture fragment though.
cgc
On Feb 16, 2006, at 2:34 PM, chris clepper wrote:
On 2/16/06, chris clepper cgc@humboldtblvd.com wrote:
Not tested in GEM but this is working GLSL code from ATI for a type of Gaussian effect:
I can't get this working using the current CVS glsl objects, but it works fine in Shader Builder.
[glsl_fragment]: Loaded file: /Users/schwartz/Desktop/shaders/ glsl_gauss.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
Nothing visible happens to the texture fragment though.
...same thing here: seems like it's real hit-or-miss as far as which glsl shaders work in gem...I have no problem with simple/trivial ones, but anything more complex than assigning a color don't always work :-( Still can't get the mandlebrot stuff going either...
...just as a thought, I wonder if uploading YUV textures is a problem? I wonder how that actually appears on the card? Does the driver convert it to RGB after upload? Also, I assume you are using power of 2 textures, cuz other with you'd have to change the shader to sampler2DRect and such...
...Lotsa debugging left to-do, as usual...
jamie
On Feb 16, 2006, at 1:09 PM, chris clepper wrote:
Post back a working patch if you get one going. Good luck!
hey all,
...I went ahead and looked at the glsl stuff again, the attached patch works fine for me: one thing to remember with shaders is that they must use different "samplers" for different texture dimensions...in the attached example, the shader expects a square texture (texture2D), so try movies of 256x256, 512x512, etc...in order to do 320x240/640x480/etc, the shader would have to have certain commands changed (ie. "sampler2D" becomes "sampler2DRect", same with texture2D)...there's probably a simple way of telling one shader which path to use, but I haven't gotten there yet...
enjoy, jamie
ps: also remember that by default, osx loads pix_texture with "mode 1"/rectangle_textures, so you need to make sure it's switched to "mode 0"
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.
[glsl_program]: vertex shader running in hardware [glsl_program]: fragment shader running in hardware
There's no ouput in the gemwin at all.
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).
cgc
On 2/17/06, james tittle tigital@mac.com wrote:
On Feb 16, 2006, at 1:09 PM, chris clepper wrote:
Post back a working patch if you get one going. Good luck!
hey all,
...I went ahead and looked at the glsl stuff again, the attached patch works fine for me: one thing to remember with shaders is that they must use different "samplers" for different texture dimensions...in the attached example, the shader expects a square texture (texture2D), so try movies of 256x256, 512x512, etc...in order to do 320x240/640x480/etc, the shader would have to have certain commands changed (ie. "sampler2D" becomes "sampler2DRect", same with texture2D)...there's probably a simple way of telling one shader which path to use, but I haven't gotten there yet...
enjoy, jamie
ps: also remember that by default, osx loads pix_texture with "mode 1"/rectangle_textures, so you need to make sure it's switched to "mode 0"
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.
[glsl_program]: vertex shader running in hardware [glsl_program]: fragment shader running in hardware
There's no ouput in the gemwin at all.
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).
cgc
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.
cgc
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.
[glsl_program]: vertex shader running in hardware [glsl_program]: fragment shader running in hardware
There's no ouput in the gemwin at all.
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).
cgc
Yet another update! That shader runs in software on a Dual Core G5 with NV 6600. It's about 1/10th the speed of using the pix_convolve equivalent.
cgc
On Feb 17, 2006, at 1:31 PM, chris clepper wrote:
Yet another update! That shader runs in software on a Dual Core G5 with NV 6600. It's about 1/10th the speed of using the pix_convolve equivalent.
...hmm, find it hard to believe that it runs in software there, because it's running in hardware on my radeon mobility 9700...of course, it could be yet another example of the vast difference between vendors views of shader support, or apple's ability/desire to keep a level driver field...? I had always assumed that ATI was more finicky about what it would run in hardware...but then that shader is from an ATI sample code, and I know that I've had tons of problems running seemingly simple nvidia sample code on ATI hardware...
jamie
james tittle wrote:
On Feb 17, 2006, at 1:31 PM, chris clepper wrote:
Yet another update! That shader runs in software on a Dual Core G5 with NV 6600. It's about 1/10th the speed of using the pix_convolve equivalent.
i can confirm that the shader is a lot slower than [pix_convolve]. on my system (linux, AthlonXP 2000+, NV31 (FX 5800)) it takes about 0.04ms to render a frame (including decompression of anim-1.mov and texturing) with the glsl-shader and 0.02ms with pix_convolve.
...hmm, find it hard to believe that it runs in software there, because it's running in hardware on my radeon mobility 9700...of course, it could be yet another example of the vast difference between vendors views of shader support, or apple's ability/desire to keep a level driver field...?
since it runs on linux i guess it is more a vendor view of shader support.
mfg.a IOhannes
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
chris clepper 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):
hmm, this seems to be a bug. glsl_fragment is a child of glsl_vertex, among others it inherits the 2nd outlet. and then overwrites this one with a 3rd outlet.
i'll commit a fix.
mfg.asdr IOhannes
-
B. Bogart -
chris clepper -
chris clepper -
IOhannes m zmoelnig -
james tittle -
Mathieu Bouchard