<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hello,<br>
<br>
Le 31/08/2013 14:22, Antoine Villeret a écrit :<br>
</div>
<blockquote
cite="mid:CAGn5wNf1kBowSep4k9+55HDwoEZgq-0odGt1yhf70rWaup4mbw@mail.gmail.com"
type="cite">
<p dir="ltr">2013/8/30 Jack <<a moz-do-not-send="true"
href="mailto:jack@rybn.org">jack@rybn.org</a>></p>
<p dir="ltr">> Hello Nicolas,<br>
><br>
> Le 30/08/2013 10:48, Nicolas Montgermont a écrit :<br>
><br>
> > Hello jack,<br>
> ><br>
> > yes it can be very useful and powerful.<br>
> Yep.<br>
><br>
> > On the abstraction you send I have differents remarks:<br>
> > - 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.<br>
> 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 ?<br>
</p>
<p dir="ltr">I think it's better to have drop-in replacement of
pix_* object, but it could be difficult to manage<br>
for example a strict equivalent to pix_chroma_key should handle
a no argument initialisation, is this possible with
glsl_chroma_key ?<br>
</p>
</blockquote>
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.<br>
So, I think it is more simple to assign the texunit as argument in
all glsl_ abstractions. Or I am wrong ?<br>
<blockquote
cite="mid:CAGn5wNf1kBowSep4k9+55HDwoEZgq-0odGt1yhf70rWaup4mbw@mail.gmail.com"
type="cite">
<p dir="ltr"> ><br>
><br>
> > - 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.<br>
> 256x256 is the default size of the texture generate by
[gemframebuffer].<br>
> 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.<br>
> If you start to change the dimen of the texture1 with
[pix_resize], it is too slow...<br>
> Of course, you can use the message [dimen( on the
abstraction to change the size of the texture generate.<br>
</p>
<p dir="ltr">yes and pix_chroma_key doesn't handle non equal
texture, so this is good but, I think we can make it more
silently<br>
By scaling texcoord according to texture size<br>
But maybe i m wrong...<br>
</p>
</blockquote>
Yes, it could be possible with something like [glsl_texcoordchange].<br>
See attached for instance (at the bottom of the patch).<br>
++<br>
<br>
Jack<br>
<br>
<br>
<blockquote
cite="mid:CAGn5wNf1kBowSep4k9+55HDwoEZgq-0odGt1yhf70rWaup4mbw@mail.gmail.com"
type="cite">
<p dir="ltr"> ><br>
><br>
> > - 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<br>
> 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.<br>
><br>
> > - 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.<br>
> Yes, good idea.<br>
><br>
> > - maybe the object can print a specific error message
when it doesn't know the input:<br>
> > glsl_chroma_key : no method for 'toto'<br>
> > instead of:<br>
> > gemframebuffer: no method for 'toto'<br>
> Yes, good idea too. I will add a gem_state in [route].<br>
> ++<br>
><br>
> Jack<br>
><br>
><br>
> ><br>
> > best,<br>
> > n<br>
> ><br>
> ><br>
> > Le 30/08/13 01:51, Antoine Villeret a écrit :<br>
> >> good job !<br>
> >> could be very useful !<br>
> >> I have some too (to replace pix_movement for
example)<br>
> >> what is your working repo ?<br>
> >><br>
> >> +<br>
> >> a<br>
> >><br>
> >> --<br>
> >> do it yourself <br>
> >> <a moz-do-not-send="true"
href="http://antoine.villeret.free.fr">http://antoine.villeret.free.fr</a><br>
> >><br>
> >><br>
> >> 2013/8/28 Jack <<a moz-do-not-send="true"
href="mailto:jack@rybn.org">jack@rybn.org</a> <mailto:<a
moz-do-not-send="true" href="mailto:jack@rybn.org">jack@rybn.org</a>>><br>
> >><br>
> >><br>
>><br>
>> Le 26/07/2013 14:03, IOhannes m zmölnig a écrit :<br>
>> > On 07/26/13 11:44, Jack wrote:<br>
>> >> Hello,<br>
>><br>
>> >> I would like to create GLSL abstractions in
the help directory, which<br>
>> >> would replace pix_ objects when possible. The
name would start with<br>
>> >> glsl_ instead of pix_.<br>
>><br>
>> > sound good.<br>
>><br>
>> >> Is there any objection against this ?<br>
>><br>
>> > no.<br>
>><br>
>> >> If not, i would like to have acces to the git
repository with write<br>
>> >> access. Is that possible ?<br>
>><br>
>> > wouldn't it be easier if you just forked the
repository, and made a<br>
>> > pull-request via github?<br>
>> > i really love the decentralized aspect of git.<br>
>><br>
>><br>
>> > mgfd.gasda<br>
>> > IOhannes<br>
>><br>
>><br>
>><br>
>><br>
>> > _______________________________________________<br>
>> > GEM-dev mailing list<br>
>> > <a moz-do-not-send="true"
href="mailto:GEM-dev@iem.at">GEM-dev@iem.at</a> <mailto:<a
moz-do-not-send="true" href="mailto:GEM-dev@iem.at">GEM-dev@iem.at</a>><br>
>><br>
>> > <a moz-do-not-send="true"
href="http://lists.puredata.info/listinfo/gem-dev">http://lists.puredata.info/listinfo/gem-dev</a><br>
>><br>
>><br>
>> I started to make seven abstractions glsl_*.<br>
>> I would like to be sure, with the example attached, if
i am on the right path.<br>
>> Comments are welcome.<br>
>> ++<br>
>><br>
>> Jack<br>
>><br>
>><br>
> >><br>
> >><br>
> >>
_______________________________________________<br>
> >> GEM-dev mailing list<br>
> >> <a moz-do-not-send="true"
href="mailto:GEM-dev@iem.at">GEM-dev@iem.at</a> <mailto:<a
moz-do-not-send="true" href="mailto:GEM-dev@iem.at">GEM-dev@iem.at</a>><br>
><br>
> >> <a moz-do-not-send="true"
href="http://lists.puredata.info/listinfo/gem-dev">http://lists.puredata.info/listinfo/gem-dev</a><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> GEM-dev mailing list<br>
> >> <a moz-do-not-send="true"
href="mailto:GEM-dev@iem.at">GEM-dev@iem.at</a><br>
> >> <a moz-do-not-send="true"
href="http://lists.puredata.info/listinfo/gem-dev">http://lists.puredata.info/listinfo/gem-dev</a><br>
> ><br>
> > -- <br>
> > <a moz-do-not-send="true" href="http://www.nimon.org">http://www.nimon.org</a><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > GEM-dev mailing list<br>
> > <a moz-do-not-send="true"
href="mailto:GEM-dev@iem.at">GEM-dev@iem.at</a><br>
> > <a moz-do-not-send="true"
href="http://lists.puredata.info/listinfo/gem-dev">http://lists.puredata.info/listinfo/gem-dev</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> GEM-dev mailing list<br>
> <a moz-do-not-send="true" href="mailto:GEM-dev@iem.at">GEM-dev@iem.at</a><br>
> <a moz-do-not-send="true"
href="http://lists.puredata.info/listinfo/gem-dev">http://lists.puredata.info/listinfo/gem-dev</a><br>
></p>
</blockquote>
<br>
</body>
</html>