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@rybn.org mailto:jack@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@rybn.org mailto:jack@rybn.org
<mailto:jack@rybn.org mailto:jack@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
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 listGEM-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
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