Hello,
Here a GLSL version of [pix_scanline] with its help patch. Can be integrated everywhere if needed. It could be interesting to have, in the help directory, abstractions with GLSL version of pixes, no ? ++
Jack
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_. Is there any objection against this ? If not, i would like to have acces to the git repository with write access. Is that possible ? Thanx. ++
Jack
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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 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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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 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
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSHfd8AAoJEOuluecjw8GUNhIH/1pvebiP2CRZNArDCS3anJO0 9U34Wc2ENOsEGyivRF/aAIT6RAoJmZgAor8xj7Ny1hTk7cKlnRT+yEh/5KBaUg0g gPd6ZjQygqinkg6kPXZ7AsgLpv6BDn33vMnQbW/d1aMmTiC3KRNtwSc9T3awoPNq iMW+yV+Ir+WjXLO8hsSV96rW5hEUGioN3iRjbat6++mw4hqC9T6yCQngWSPR7+xB 46+3VXrXpjHiZblUxYYWHvAypXlOqvYfwd4+92mFojardK6imfYsw3ZyJ45Bf0m2 +o68hovxFYP961YwPtvF729ZyRGYryQGnLDXTc4nDDaBdOmW/zCatpLHBWmu+PE= =E+az -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Hello jack,
yes it can be very useful and powerful. 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. - 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. - 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 - 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. - 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'
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>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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> > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSHfd8AAoJEOuluecjw8GUNhIH/1pvebiP2CRZNArDCS3anJO0 9U34Wc2ENOsEGyivRF/aAIT6RAoJmZgAor8xj7Ny1hTk7cKlnRT+yEh/5KBaUg0g gPd6ZjQygqinkg6kPXZ7AsgLpv6BDn33vMnQbW/d1aMmTiC3KRNtwSc9T3awoPNq iMW+yV+Ir+WjXLO8hsSV96rW5hEUGioN3iRjbat6++mw4hqC9T6yCQngWSPR7+xB 46+3VXrXpjHiZblUxYYWHvAypXlOqvYfwd4+92mFojardK6imfYsw3ZyJ45Bf0m2 +o68hovxFYP961YwPtvF729ZyRGYryQGnLDXTc4nDDaBdOmW/zCatpLHBWmu+PE= =E+az -----END PGP SIGNATURE----- _______________________________________________ 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
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 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.
- 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>
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 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> 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
2013/8/30 Jack 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 ?
- 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...
- 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>
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
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>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
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 ?
- 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 list GEM-dev@iem.at <mailto:GEM-dev@iem.at> <mailto:GEM-dev@iem.athttp://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
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.
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 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 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
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
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@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.
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@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
> 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
> 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
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Le 01/09/13 11:31, Jack a écrit :
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.
Mmmm, here creating [GLdefine GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS] and banging it gives: 35661... did I miss something obvious? osx10.6.8 nvidia geforce 320m
Thanks, n
Le 02/09/2013 12:41, Nicolas Montgermont a écrit :
Le 01/09/13 11:31, Jack a écrit :
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.
Mmmm, here creating [GLdefine GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS] and banging it gives: 35661... did I miss something obvious? osx10.6.8 nvidia geforce 320m
Thanks, n
Hello Nico,
Use the message [print( on [glsl_vertex] to get the appropriate number. ++
Jack
Le 02/09/13 13:56, Jack a écrit :
Hello Nico,
Use the message [print( on [glsl_vertex] to get the appropriate number. ++
thanks: 16 the output of GLDefine is not converted? best, n
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-09-02 12:41, Nicolas Montgermont wrote:
Le 01/09/13 11:31, Jack a écrit :
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.
Mmmm, here creating [GLdefine GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS] and banging it gives: 35661... did I miss something obvious?
yes.
GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS is a label, that can be used to query the maximum number of combined texture image units. it is not the number itself. you have to use it with glGet() in order to query the result.
[gemhead] | [GEMglGetIntegerv GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS] | [ \
btw, this gives 20 on my old and trusted GeForce 7800 GTX.
fgamsdr IOhannes
Le 01/09/2013 11:31, Jack a écrit :
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.
do we have the possibility to ask for the next free texture Id? so we could have objects that automatically deal with texture Id.
cheers c
Le 02/09/2013 12:58, Cyrille Henry a écrit :
Le 01/09/2013 11:31, Jack a écrit :
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.
do we have the possibility to ask for the next free texture Id? so we could have objects that automatically deal with texture Id.
cheers c
Hello Cyrille,
I don't know if it is possible to ask for the next free texture ID.
But : - what happen if you decide to erase a 'glsl_abstraction' ? Other 'glsl_abstraction' should keep their own 'texture ID'. I think, it is very important if you pass a uniform sampler variable to [glsl_program] somewhere else in your patch ? - we need to keep informed about the 'texture ID' choosen if we want to use it somewhere else for a uniform sampler variable (should be easy with GOP and number box) ? - what happen, if you don't want to assign a specific value as texture ID because you already store a uniform sampler variable to [glsl_program] somewhere else (this aspect is not very complex to solve, we just need to change the value of the variable send to [glsl_program]) ?
Maybe there are other questions ? ++
Jack
Colet Patrice
----- Mail original -----
De: "Jack" jack@rybn.org À: "Cyrille Henry" ch@chnry.net Cc: "gem-dev" gem-dev@iem.at Envoyé: Lundi 2 Septembre 2013 14:26:46 Objet: Re: [GEM-dev] help with glsl abstractions
Le 02/09/2013 12:58, Cyrille Henry a écrit :
Le 01/09/2013 11:31, Jack a écrit :
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.
do we have the possibility to ask for the next free texture Id? so we could have objects that automatically deal with texture Id.
cheers c
Hello Cyrille,
I don't know if it is possible to ask for the next free texture ID.
Hello, I think this could be done with usual pd objects, by prepending a sender name to texunit, this name would be set in abstraction's arguments, then a receiver name for shaders that needs to process texunit would retrieve the right number anytime
But :
- what happen if you decide to erase a 'glsl_abstraction' ? Other
'glsl_abstraction' should keep their own 'texture ID'. I think, it is very important if you pass a uniform sampler variable to [glsl_program] somewhere else in your patch ?
- we need to keep informed about the 'texture ID' choosen if we want
to use it somewhere else for a uniform sampler variable (should be easy with GOP and number box) ?
- what happen, if you don't want to assign a specific value as
texture ID because you already store a uniform sampler variable to [glsl_program] somewhere else (this aspect is not very complex to solve, we just need to change the value of the variable send to [glsl_program]) ?
Maybe there are other questions ? ++
Jack
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Le 02/09/2013 16:05, Patrice Colet a écrit :
Colet Patrice
----- Mail original -----
De: "Jack" jack@rybn.org À: "Cyrille Henry" ch@chnry.net Cc: "gem-dev" gem-dev@iem.at Envoyé: Lundi 2 Septembre 2013 14:26:46 Objet: Re: [GEM-dev] help with glsl abstractions
Le 02/09/2013 12:58, Cyrille Henry a écrit :
Le 01/09/2013 11:31, Jack a écrit :
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.
do we have the possibility to ask for the next free texture Id? so we could have objects that automatically deal with texture Id.
cheers c
Hello Cyrille,
I don't know if it is possible to ask for the next free texture ID.
Hello, I think this could be done with usual pd objects, by prepending a sender name to texunit, this name would be set in abstraction's arguments, then a receiver name for shaders that needs to process texunit would retrieve the right number anytime
If we try to avoid argument in abstraction (to have similar pix_* object and glsl_* (or an other name) abstractions), maybe an external could help... ++
Jack
But :
- what happen if you decide to erase a 'glsl_abstraction' ? Other
'glsl_abstraction' should keep their own 'texture ID'. I think, it is very important if you pass a uniform sampler variable to [glsl_program] somewhere else in your patch ?
- we need to keep informed about the 'texture ID' choosen if we want
to use it somewhere else for a uniform sampler variable (should be easy with GOP and number box) ?
- what happen, if you don't want to assign a specific value as
texture ID because you already store a uniform sampler variable to [glsl_program] somewhere else (this aspect is not very complex to solve, we just need to change the value of the variable send to [glsl_program]) ?
Maybe there are other questions ? ++
Jack
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hey there,
here's the glsl_contrast i was talking about earlier. i made a help patch for it and wrapped it all up a bit. have not done all the message passing to gemframebuffer though. seems to me that part of this logic would apply to all the glsl_* so maybe wrap it in sub-abstraction?
cheers, ub
Hello Cyrille,
I don't know if it is possible to ask for the next free texture ID.
Hello, I think this could be done with usual pd objects, by prepending a sender name to texunit, this name would be set in abstraction's arguments, then a receiver name for shaders that needs to process texunit would retrieve the right number anytime
If we try to avoid argument in abstraction (to have similar pix_* object and glsl_* (or an other name) abstractions), maybe an external could help... ++
Le 06/09/2013 17:19, ub a écrit :
hey there,
here's the glsl_contrast i was talking about earlier. i made a help patch for it and wrapped it all up a bit. have not done all the message passing to gemframebuffer though. seems to me that part of this logic would apply to all the glsl_* so maybe wrap it in sub-abstraction?
cheers, ub
Hello Cyrille,
I don't know if it is possible to ask for the next free texture ID.
Hello, I think this could be done with usual pd objects, by prepending a sender name to texunit, this name would be set in abstraction's arguments, then a receiver name for shaders that needs to process texunit would retrieve the right number anytime
If we try to avoid argument in abstraction (to have similar pix_* object and glsl_* (or an other name) abstractions), maybe an external could help... ++
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Hello ub, Thanx, I add the files in the github. ++
Jack
Le 02/09/2013 14:26, Jack a écrit :
Le 02/09/2013 12:58, Cyrille Henry a écrit :
Le 01/09/2013 11:31, Jack a écrit :
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.
do we have the possibility to ask for the next free texture Id? so we could have objects that automatically deal with texture Id.
cheers c
Hello Cyrille,
I don't know if it is possible to ask for the next free texture ID.
But :
- what happen if you decide to erase a 'glsl_abstraction' ? Other
'glsl_abstraction' should keep their own 'texture ID'. I think, it is very important if you pass a uniform sampler variable to [glsl_program] somewhere else in your patch ?
- we need to keep informed about the 'texture ID' choosen if we want to
use it somewhere else for a uniform sampler variable (should be easy with GOP and number box) ?
- what happen, if you don't want to assign a specific value as texture
ID because you already store a uniform sampler variable to [glsl_program] somewhere else (this aspect is not very complex to solve, we just need to change the value of the variable send to [glsl_program]) ?
Maybe there are other questions ?
i don't see any problem. if we could automatically find a free texture Id, then we can make abstraction that automatically deal with all of this. it's not very hard to imagine somthing flexible enouth to get the Id, or to force a specific Id, or whatever else you may wish. the only problem imo is getting a free Id.
c
++
Jack
Le 02/09/2013 22:33, Cyrille Henry a écrit :
Le 02/09/2013 14:26, Jack a écrit :
Le 02/09/2013 12:58, Cyrille Henry a écrit :
Le 01/09/2013 11:31, Jack a écrit :
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.
do we have the possibility to ask for the next free texture Id? so we could have objects that automatically deal with texture Id.
cheers c
Hello Cyrille,
I don't know if it is possible to ask for the next free texture ID.
But :
- what happen if you decide to erase a 'glsl_abstraction' ? Other
'glsl_abstraction' should keep their own 'texture ID'. I think, it is very important if you pass a uniform sampler variable to [glsl_program] somewhere else in your patch ?
- we need to keep informed about the 'texture ID' choosen if we want to
use it somewhere else for a uniform sampler variable (should be easy with GOP and number box) ?
- what happen, if you don't want to assign a specific value as texture
ID because you already store a uniform sampler variable to [glsl_program] somewhere else (this aspect is not very complex to solve, we just need to change the value of the variable send to [glsl_program]) ?
Maybe there are other questions ?
i don't see any problem. if we could automatically find a free texture Id, then we can make abstraction that automatically deal with all of this. it's not very hard to imagine somthing flexible enouth to get the Id, or to force a specific Id, or whatever else you may wish. the only problem imo is getting a free Id.
I don't see any problem too :) It was just a warning on the behavior when you remove an abstraction, close the patch and re-open it, you need to keep the texture ID as before. If it is OK with that behavior and to get a free texture ID, then it should work. The second and third point are easy to add/correct in the patch 'domain'. ++
Jack
c
++
Jack
Le 30/08/2013 01:51, Antoine Villeret a écrit :
good job !
Thanx.
could be very useful !
Yes, I hope.
I have some too (to replace pix_movement for example)
Cool, everybody is welcome ;)
what is your working repo ?
Hello Antoine,
It is not ready yet. I am totaly beginner in git/repository. IOhannes tell me to fork the Gem repo and to make a pull-request via Github. I don't know how to do that for now, so I will do it soon... ++
Jack
a
-- do it yourself http://antoine.villeret.free.fr
2013/8/28 Jack <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 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> http://lists.puredata.info/listinfo/gem-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-08-30 18:14, Jack wrote:
I am totaly beginner in git/repository.
aye, git has a somewhat steep learning curve. for a programmer i think it is worth it.
IOhannes tell me to fork the Gem repo and to make a pull-request via Github. I don't know how to do that for now, so I will do it soon...
- - go to http://github.com/ and get yourself an account (e.g. "rybn"), then log in. - - go to http://github.com/umlaeute/Gem, and click on the "Fork" button in the upper-right corner. - - this will fork the repository into http://github.com/rybn/Gem, go there and follow the instructions to clone the repository to your local machine. - - do work (add new abstractions/,...) and commit them to your local copy - - push them to github - - go back to http://github.com/rybn/Gem and click on "Pull Request" and follow the instructions there. - - i will get a notification that i should merge in your changes and can do so (after reviewing them)
fgmasdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 02/09/2013 18:45, IOhannes m zmoelnig a écrit :
On 2013-08-30 18:14, Jack wrote:
I am totaly beginner in git/repository.
aye, git has a somewhat steep learning curve. for a programmer i think it is worth it.
IOhannes tell me to fork the Gem repo and to make a pull-request via Github. I don't know how to do that for now, so I will do it soon...
- go to http://github.com/ and get yourself an account (e.g. "rybn"),
then log in.
- go to http://github.com/umlaeute/Gem, and click on the "Fork" button
in the upper-right corner.
- this will fork the repository into http://github.com/rybn/Gem, go
there and follow the instructions to clone the repository to your local machine.
- do work (add new abstractions/,...) and commit them to your local copy
- push them to github
- go back to http://github.com/rybn/Gem and click on "Pull Request"
and follow the instructions there.
- i will get a notification that i should merge in your changes and
can do so (after reviewing them)
fgmasdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
OK, i will follow your instructions because i don't know if what i have done is good : http://github.com/Jackovic/Gem (i didn't know http://github.com/umlaeute/Gem) ++
Jack
Le 30/08/2013 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>
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 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
So I create an account on Github where I fork Gem. I don't know if i do it according to the rules. Tell me if I have to change something. git://github.com/Jackovic/Gem.git I put a 'glsl_abstractions' directory in the 'help' and don't know if it is the best place for that. ++
Jack
Le 01/09/2013 11:40, Jack a écrit :
Le 30/08/2013 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>
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 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
So I create an account on Github where I fork Gem. I don't know if i do it according to the rules. Tell me if I have to change something. git://github.com/Jackovic/Gem.git I put a 'glsl_abstractions' directory in the 'help' and don't know if it is the best place for that.
i think there is 2 options : -consider them as Gem object : putting them on the abstraction folder, making specific help file and changing makefile in order to install them pro : would be like any other Gem object con : need to be maintain
-create a examples/14.pix_glsl folder and put everything inside pro : less work con : harder to find
i'll vote for option 2 : there is already directory 11.obj_exporter and 12.multi_screen_projection that are in the same situation.
cheers c
++
Jack
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
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.
I was wondering, isn't a name connected to pix could be better suited? for example pix_alpha -> pix_alpha_sl instead of pix_alpha -> glsl_alpha Cause it's here to replace pixes, no? And we can imagine having glsl abstraction not working specially in the field of texture... This way the help directory will be alphabetically directly ordered... and one can imagine new pixes effect without any need for a corresponding pix_* object best, n
On 02.09.2013 12:32, Nicolas Montgermont wrote:
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.
I was wondering, isn't a name connected to pix could be better suited? for example pix_alpha -> pix_alpha_sl instead of pix_alpha -> glsl_alpha Cause it's here to replace pixes, no?
not quite, regarding the need for indexed textures and possibly other side effects caused by the buffer-projection. so i think the prefix notation is just perfect, for pointing out the difference as well as the similarity to pix_objects.
however, i would suggest to put the actual shader code in a shader/ subfolder. what do you think?
cheers, ub
And we can imagine having glsl abstraction not working specially in the field of texture... This way the help directory will be alphabetically directly ordered... and one can imagine new pixes effect without any need for a corresponding pix_* object best, n
Le 02/09/2013 12:32, Nicolas Montgermont a écrit :
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.
I was wondering, isn't a name connected to pix could be better suited? for example pix_alpha -> pix_alpha_sl instead of pix_alpha -> glsl_alpha Cause it's here to replace pixes, no? And we can imagine having glsl abstraction not working specially in the field of texture... This way the help directory will be alphabetically directly ordered... and one can imagine new pixes effect without any need for a corresponding pix_* object
yes, we can imaging extending this objects collection for vertex, or with function that is not yet possible with pix_ object. so having pix_ prefix on this objects is not a good idea imo.
texture_alpha / texture_add / ... vertex_random / ... ???
so that one can use this objects without having heard about shaders / glsl or sl.
cheers c
best, n
Le 02/09/13 12:55, Cyrille Henry a écrit :
yes, we can imaging extending this objects collection for vertex, or with function that is not yet possible with pix_ object. so having pix_ prefix on this objects is not a good idea imo.
What I had in mind is : [pix_*_sl] ONLY for glsl abstraction that replace a corresponding [pix_*] object and for example [vertex_*_sl for shader dealing with vertex. This way the abstractions are classed by fonctionnality instead of method (glsl).
But I get your point and it's surely easier your way. Nevertheless, one can ask is [glsl_alpha] a replacement for [alpha] or [pix_alpha]? Best, n
texture_alpha / texture_add / ... vertex_random / ...
Le 02/09/2013 13:17, Nicolas Montgermont a écrit :
Le 02/09/13 12:55, Cyrille Henry a écrit :
yes, we can imaging extending this objects collection for vertex, or with function that is not yet possible with pix_ object. so having pix_ prefix on this objects is not a good idea imo.
What I had in mind is : [pix_*_sl] ONLY for glsl abstraction that replace a corresponding [pix_*] object and for example [vertex_*_sl for shader dealing with vertex. This way the abstractions are classed by fonctionnality instead of method (glsl).
But I get your point and it's surely easier your way. Nevertheless, one can ask is [glsl_alpha] a replacement for [alpha] or [pix_alpha]?
yes, that's why I prefere texture_alpha.
cheers c
Best, n
texture_alpha / texture_add / ... vertex_random / ...
Le 02/09/2013 12:32, Nicolas Montgermont a écrit :
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.
I was wondering, isn't a name connected to pix could be better suited? for example pix_alpha -> pix_alpha_sl instead of pix_alpha -> glsl_alpha Cause it's here to replace pixes, no? And we can imagine having glsl abstraction not working specially in the field of texture... This way the help directory will be alphabetically directly ordered... and one can imagine new pixes effect without any need for a corresponding pix_* object best, n
This aspect is important. Problem : often pix_* objects are for pixes using CPU. With shaders in GLSL we deal with textures on GPU (to replace pixes). So here, a list of possibilities to replace, for example, [pix_2grey] : [glsl_2grey] (easy to find equivalent of [pix_2grey]) [tex_2grey] (also easy to find equivalent of [pix_2grey]) [glsl_tex_2grey] (quite easy to find equivalent of [pix_2grey])
Now if we need to work on vertex/fragment in the future, it would be possible to use a specific name with glsl_ and not with tex_ (which is for texture), for example if we need to change z position of vertices according to the color of a texture : [glsl_vertex_displacement]
So, I think we should always start names with [glsl_]. Then, distinguish the work on texture, vertex, fragment and geometry. Then maybe something starting with : glsl_tex_* glsl_vertex_* glsl_fragment_* glsl_geometry_*
++
Jack
Le 02/09/2013 14:09, Jack a écrit :
Le 02/09/2013 12:32, Nicolas Montgermont a écrit :
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.
I was wondering, isn't a name connected to pix could be better suited? for example pix_alpha -> pix_alpha_sl instead of pix_alpha -> glsl_alpha Cause it's here to replace pixes, no? And we can imagine having glsl abstraction not working specially in the field of texture... This way the help directory will be alphabetically directly ordered... and one can imagine new pixes effect without any need for a corresponding pix_* object best, n
This aspect is important. Problem : often pix_* objects are for pixes using CPU. With shaders in GLSL we deal with textures on GPU (to replace pixes). So here, a list of possibilities to replace, for example, [pix_2grey] : [glsl_2grey] (easy to find equivalent of [pix_2grey]) [tex_2grey] (also easy to find equivalent of [pix_2grey]) [glsl_tex_2grey] (quite easy to find equivalent of [pix_2grey])
Now if we need to work on vertex/fragment in the future, it would be possible to use a specific name with glsl_ and not with tex_ (which is for texture), for example if we need to change z position of vertices according to the color of a texture : [glsl_vertex_displacement]
So, I think we should always start names with [glsl_]. Then, distinguish the work on texture, vertex, fragment and geometry. Then maybe something starting with : glsl_tex_* glsl_vertex_* glsl_fragment_* glsl_geometry_*
this name releft the technical stuf insite the abstraction. i wouls prefere name that mean something for someone who did not know what glsl is.
c
++
Jack
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Le 02/09/2013 22:27, Cyrille Henry a écrit :
Le 02/09/2013 14:09, Jack a écrit :
Le 02/09/2013 12:32, Nicolas Montgermont a écrit :
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.
I was wondering, isn't a name connected to pix could be better suited? for example pix_alpha -> pix_alpha_sl instead of pix_alpha -> glsl_alpha Cause it's here to replace pixes, no? And we can imagine having glsl abstraction not working specially in the field of texture... This way the help directory will be alphabetically directly ordered... and one can imagine new pixes effect without any need for a corresponding pix_* object best, n
This aspect is important. Problem : often pix_* objects are for pixes using CPU. With shaders in GLSL we deal with textures on GPU (to replace pixes). So here, a list of possibilities to replace, for example, [pix_2grey] : [glsl_2grey] (easy to find equivalent of [pix_2grey]) [tex_2grey] (also easy to find equivalent of [pix_2grey]) [glsl_tex_2grey] (quite easy to find equivalent of [pix_2grey])
Now if we need to work on vertex/fragment in the future, it would be possible to use a specific name with glsl_ and not with tex_ (which is for texture), for example if we need to change z position of vertices according to the color of a texture : [glsl_vertex_displacement]
So, I think we should always start names with [glsl_]. Then, distinguish the work on texture, vertex, fragment and geometry. Then maybe something starting with : glsl_tex_* glsl_vertex_* glsl_fragment_* glsl_geometry_*
this name releft the technical stuf insite the abstraction. i wouls prefere name that mean something for someone who did not know what glsl is.
Yep, you are right, i am OK with that. Maybe, for people in Paris, we can organize a meeting tomorrow or wednesday to talk about that ? ++
Jack
c
++
Jack
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-
Antoine Villeret -
Cyrille Henry -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jack -
Nicolas Montgermont -
Patrice Colet -
ub