Le 24/11/2012 13:52, Jack a écrit :
Le 23/11/2012 11:55, [email protected] a écrit :
Le jeu 22/11/12 21:15, "Jack" [email protected] 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
[email protected]
http://lists.puredata.info/listinfo/gem-dev
_______________________________________________
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
_______________________________________________
GEM-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/gem-dev
