Hello,
Le 31/08/2013 14:22, Antoine Villeret a écrit :
2013/8/30 Jack <jack@rybn.org mailto:jack@rybn.org>
Hello Nicolas,
Le 30/08/2013 10:48, Nicolas Montgermont a écrit :
Hello jack,
yes it can be very useful and powerful.
Yep.
On the abstraction you send I have differents remarks:
- it is not compatible with [pix_chroma_key] and I think this is
very important. The main usage of that kind of abstractions is to have an easy and faster replacement for existing objects.
Not totally compatible, yes. I think, it is more simpler to use a
range value as float which determine the distance between the target color to remove (and other color in a circle of radius equal to that range). There is many way to make a chroma_key... But you are right, the aim of this abstractions is to be like pix_ object (when it is possible). What other people think about it ?
I think it's better to have drop-in replacement of pix_* object, but it could be difficult to manage for example a strict equivalent to pix_chroma_key should handle a no argument initialisation, is this possible with glsl_chroma_key ?
It should be possible to make a global counter to assign that value as texunit, But, if you have ever assigned it somewhere in your patch... disaster ! Idem if you have ever pass the value to a [glsl_program] localised somewhere else in your patch. So, I think it is more simple to assign the texunit as argument in all glsl_ abstractions. Or I am wrong ?
- I see no reasons to have a default size to 256x256, or even to
have a size as an argument, texture size of the first texture will be really easier as default, and dimen can be used to change that.
256x256 is the default size of the texture generate by [gemframebuffer]. If you have a texture1 at 800x800 tx and a second at 400x400 tx and
need a texture at 200x200 tx as output, it is possible.
If you start to change the dimen of the texture1 with [pix_resize],
it is too slow...
Of course, you can use the message [dimen( on the abstraction to
change the size of the texture generate.
yes and pix_chroma_key doesn't handle non equal texture, so this is good but, I think we can make it more silently By scaling texcoord according to texture size But maybe i m wrong...
Yes, it could be possible with something like [glsl_texcoordchange]. See attached for instance (at the bottom of the patch). ++
Jack
- I think it's good if the provided example of the usage is easily
transposable, beginners tends to copy directly from the help patch. I think here for example the main gemhead could be to default and the gemhead before the gemframebuffer to 49
I let the user (beginner) to manage it with the 'main' gemhead. It
is why the gemhead is outside from the abstraction. With that, you can chain glsl_ abstractions and choose the render order.
- for the help line : "inlet 1 all messages accepted by
gemframebuffer", I think it's good to have a subpatch [pd framebuffer_messages] with a listing that can be tested. You may then copy it inside the other help patchs.
Yes, good idea.
- maybe the object can print a specific error message when it
doesn't know the input:
glsl_chroma_key : no method for 'toto' instead of: gemframebuffer: no method for 'toto'
Yes, good idea too. I will add a gem_state in [route]. ++
Jack
best, n
Le 30/08/13 01:51, Antoine Villeret a écrit :
good job ! could be very useful ! I have some too (to replace pix_movement for example) what is your working repo ?
a
-- do it yourself http://antoine.villeret.free.fr
2013/8/28 Jack <jack@rybn.org mailto:jack@rybn.org
<mailto:jack@rybn.org mailto:jack@rybn.org>>
Le 26/07/2013 14:03, IOhannes m zmölnig a écrit :
On 07/26/13 11:44, Jack wrote:
Hello,
I would like to create GLSL abstractions in the help directory,
which
would replace pix_ objects when possible. The name would start with glsl_ instead of pix_.
sound good.
Is there any objection against this ?
no.
If not, i would like to have acces to the git repository with write access. Is that possible ?
wouldn't it be easier if you just forked the repository, and made a pull-request via github? i really love the decentralized aspect of git.
mgfd.gasda IOhannes
GEM-dev mailing list GEM-dev@iem.at mailto:GEM-dev@iem.at <mailto:GEM-dev@iem.at
I started to make seven abstractions glsl_*. I would like to be sure, with the example attached, if i am on the
right path.
Comments are welcome. ++
Jack
_______________________________________________ GEM-dev mailing list GEM-dev@iem.at <mailto:GEM-dev@iem.at> <mailto:GEM-dev@iem.athttp://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at mailto:GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at mailto:GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at mailto:GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev