Hey thanks,
the problem here is that I need to "downsample" in real time. The
framebuffer size is calculated on the amout of blur applied so that
the more you blur, the faster is the effect. You can imagine what
happens when I change the size for five or more [gemframebuffer] at
once, the console gets literally flooded.
There are two more issues:
1. When linking multiple [gemframebuffer] and [pix_texture] with the
texture id, the quality mode changes from the default GL_LINEAR to
GL_NEAREST. Is this a bug? See this example patch, the right side stay
completely harsh until you send a quality message -> http://www.mediafire.com/?qfe1q7d9vo84zlf
2. This is kind of hard to explain: the border of the framebuffer
seems to get blended with the background when using GL_LINEAR on a
following [pix_texture]. See the image -> http://img835.imageshack.us/img835/9083/gemborder.jpg
Thanks in advance.
Best,
Guido
Il giorno 20/ott/11, alle ore 17:25, cyrille henry ha scritto:
hello,
welcome,
You should create multiple framebuffer during initialisation. one
for each size.
I think the main problem with changing framebuffer size is not only
the message in the console, but also poor performances.
cheers
Cyrille
Le 20/10/2011 11:03, Guido Tamino a écrit :
Hello everybody, I'm new to the list.
I'm working on a multipass glsl blur for Gem which needs
downsampling for each pass. I managed to do that easily with a
dimen message. It works fine, but [gemframebuffer] is flooding the
console with "init" messages for every dimen change.
[gemframebuffer]: using rectmode 1:GL_TEXTURE_RECTANGLE
[gemframebuffer]: using type: BYTE
[gemframebuffer]: using color: RGB
[gemframebuffer]: using texunit: 0
Is there a way to silence [gemframebuffer]? Am I supposed to take a
different approach? I'm not an expert but I guess this is not an
isolated case, downsampling seems to be a common technique when
working with textures for glsl use.
Best,
Guido
_______________________________________________
GEM-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/gem-dev
_______________________________________________
GEM-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/gem-dev
