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