[GEM-dev] help with glsl abstractions

Cyrille Henry ch at chnry.net
Sat Aug 31 18:46:56 CEST 2013



Le 31/08/2013 17:40, Jack a écrit :
> 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 ?

the nmber of available textunit is usually small (8 i think on my hardware).
this can be a problem if every glsl_pix object is using 1 or 2.

i think we need to find a way to reuse the same texunit Id without having to load the texture again.
well, i don't know if it's possible.
it's a long time i haven't work with shaders...

cheers
c



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



More information about the GEM-dev mailing list