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 <j...@rybn.org <mailto:j...@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 <j...@rybn.org <mailto:j...@rybn.org> >>> <mailto:j...@rybn.org <mailto:j...@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@iem.at <mailto:GEM-dev@iem.at> <mailto:GEM-dev@iem.at >>> <mailto:GEM-dev@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@iem.at <mailto:GEM-dev@iem.at> <mailto:GEM-dev@iem.at >>> <mailto:GEM-dev@iem.at>> >>> > >>> > >> http://lists.puredata.info/listinfo/gem-dev >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> _______________________________________________ >>> > >> GEM-dev mailing list >>> > >> GEM-dev@iem.at <mailto:GEM-dev@iem.at> >>> > >> http://lists.puredata.info/listinfo/gem-dev >>> > > >>> > > -- >>> > > http://www.nimon.org >>> > > >>> > > >>> > > _______________________________________________ >>> > > GEM-dev mailing list >>> > > GEM-dev@iem.at <mailto:GEM-dev@iem.at> >>> > > http://lists.puredata.info/listinfo/gem-dev >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > GEM-dev mailing list >>> > GEM-dev@iem.at <mailto:GEM-dev@iem.at> >>> > http://lists.puredata.info/listinfo/gem-dev >>> > >>> >> >> >> >> _______________________________________________ >> GEM-dev mailing list >> GEM-dev@iem.at >> http://lists.puredata.info/listinfo/gem-dev >> _______________________________________________ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev