[GEM-dev] help with glsl abstractions

Jack jack at rybn.org
Sun Sep 1 11:31:07 CEST 2013 

hello Cyrille,

Le 31/08/2013 18:46, Cyrille Henry a écrit :
>
>
> 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.
number of texunit available is return by
GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS.
Here on Intel HD 4000, GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS is 32.
And on NVidia GTX660M is 160.
Then, i think, today, it is enough to work on glsl_ abstractions and to
combine them using texunit. But if there is a way to use less texunit,
it would be great ! For instance, it should be possible to create a big
texture with several pictures and change the texcoord to get the picture
wanted ? Of course, this method will depend on the hardware too.
++

Jack


>
> 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