Le jeu 22/11/12 21:15, "Jack" jack@rybn.org a écrit:
You can use the object
[GEMglBlendFunc]. yes, but i don't see any reason not to include it in the alpha object. Because it still exists in the [GEMglBlendFunc] :)
most Gem object could be replaced by GEMgl* stuff...
Seriously, as Chris says it's better to use shaders now, it's more flexible.
i do not agree. using shader, how would you do : GL_ONE_MINUS_SRC_COLOR you need the source color. a readback is not an option.
moreover, it's lot's easier to try sending diferent number in the alpha object to see the result, than to write a shader.
and if you don't need this functionality, you don't have to use it...
So,i think it would be nice to have this small modification included in Gem.
cheers c
++
Jack
cheers c
++
Jack
GEM-dev mailing list
GEM-dev@iem.at
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at
Le 23/11/2012 11:55, ch@chnry.net a écrit :
Le jeu 22/11/12 21:15, "Jack" jack@rybn.org a écrit:
You can use the object
[GEMglBlendFunc]. yes, but i don't see any reason not to include it in the alpha object. Because it still exists in the [GEMglBlendFunc] :)
most Gem object could be replaced by GEMgl* stuff...
Yep, and thanx to Gem to simplify the use of OpenGL.
Seriously, as Chris says it's better to use shaders now, it's more flexible.
i do not agree. using shader, how would you do : GL_ONE_MINUS_SRC_COLOR you need the source color. a readback is not an option.
In my mind i was thinking about textures operations with the use of two framebuffers if you need to capture the scene. With this solution, you can determine the source and destination in your fragment shader (as glBlendFunc) then operate on destination something equivalent to GL_ONE_MINUS_SRC_COLOR, or i miss something and i am wrong ? If this solution is OK, you needn't readback...
moreover, it's lot's easier to try sending diferent number in the alpha object to see the result, than to write a shader.
Yes, i agree it is easier to use directly Gem objects (objects different than [GEMgl*])...
and if you don't need this functionality, you don't have to use it...
So,i think it would be nice to have this small modification included in Gem.
Sure. ++
Jack
cheers c
++
Jack
cheers c
++
Jack
GEM-dev mailing list
GEM-dev@iem.at
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at
Le 24/11/2012 13:52, Jack a écrit :
Le 23/11/2012 11:55, ch@chnry.net a écrit :
Le jeu 22/11/12 21:15, "Jack" jack@rybn.org a écrit:
You can use the object
[GEMglBlendFunc]. yes, but i don't see any reason not to include it in the alpha object. Because it still exists in the [GEMglBlendFunc] :)
most Gem object could be replaced by GEMgl* stuff...
Yep, and thanx to Gem to simplify the use of OpenGL.
Seriously, as Chris says it's better to use shaders now, it's more flexible.
i do not agree. using shader, how would you do : GL_ONE_MINUS_SRC_COLOR you need the source color. a readback is not an option.
In my mind i was thinking about textures operations with the use of two framebuffers if you need to capture the scene. With this solution, you can determine the source and destination in your fragment shader (as glBlendFunc) then operate on destination something equivalent to GL_ONE_MINUS_SRC_COLOR, or i miss something and i am wrong ? If this solution is OK, you needn't readback...
yes, you're right, you don't need readback if you use framebuffer. but it would still be lot's more complex do to something like :
gemhead alpha repeat 100 separator color 1 1 1 0.1 translate (few random) square
cheers c
moreover, it's lot's easier to try sending diferent number in the alpha object to see the result, than to write a shader.
Yes, i agree it is easier to use directly Gem objects (objects different than [GEMgl*])...
and if you don't need this functionality, you don't have to use it...
So,i think it would be nice to have this small modification included in Gem.
Sure. ++
Jack
cheers c
++
Jack
cheers c
++
Jack
GEM-dev mailing list
GEM-dev@iem.at
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at
On Sat, Nov 24, 2012 at 7:52 AM, Jack jack@rybn.org wrote:
Seriously, as Chris says it's better to use shaders now, it's more flexible.
i do not agree. using shader, how would you do : GL_ONE_MINUS_SRC_COLOR you need the source color. a readback is not an option.
In my mind i was thinking about textures operations with the use of two framebuffers if you need to capture the scene. With this solution, you can determine the source and destination in your fragment shader (as glBlendFunc) then operate on destination something equivalent to GL_ONE_MINUS_SRC_COLOR, or i miss something and i am wrong ? If this solution is OK, you needn't readback...
That is essentially what recent GPUs do internally for blending anyway. There hasn't been a fixed function hardware pixel pipeline for some time now. It is more complicated to do for simple geometry in a GEM patch, as Cyrille points out so it's good to have the 'old' way for that.
-
ch＠chnry.net -
chris clepper -
Cyrille Henry
-
Jack