[GEM-dev] help with glsl abstractions

Sun Sep 1 11:40:43 CEST 2013

Le 01/09/2013 11:31, Jack a écrit :
> 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.
wow.
there is a long time i haven't work with shader!

since hardware limitation increase, we can forget about this problem and keep things simple.

cheers
c

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