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