[GEM-dev] help with glsl abstractions

Jack jack at rybn.org
Sat Aug 31 17:40:52 CEST 2013 

Hello,

Le 31/08/2013 14:22, Antoine Villeret a écrit :
>
> 2013/8/30 Jack <jack at rybn.org <mailto:jack at 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 at rybn.org <mailto:jack at rybn.org>
> <mailto: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> <mailto: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> <mailto: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 <mailto: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 <mailto:GEM-dev at iem.at>
> > > http://lists.puredata.info/listinfo/gem-dev
> >
> >
> >
> >
> > _______________________________________________
> > GEM-dev mailing list
> > GEM-dev at iem.at <mailto: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/20130831/269c2898/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flip_and_size.zip
Type: application/zip
Size: 2456 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20130831/269c2898/attachment-0001.zip>

More information about the GEM-dev mailing list