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