[GEM-dev] help with glsl abstractions

Jack jack at rybn.org
Fri Aug 30 18:55:11 CEST 2013


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 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.
> - 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 at rybn.org <mailto:jack at 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 at iem.at <mailto:GEM-dev at iem.at>
> > http://lists.puredata.info/listinfo/gem-dev
>
>
> 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 at iem.at <mailto:GEM-dev at iem.at>
>>     http://lists.puredata.info/listinfo/gem-dev
>>
>>
>>
>>
>> _______________________________________________
>> GEM-dev mailing list
>> GEM-dev at iem.at
>> http://lists.puredata.info/listinfo/gem-dev
>
> --
> http://www.nimon.org
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20130830/85575721/attachment-0001.htm>


More information about the GEM-dev mailing list