hi, I can't get gemframebuffer working with 2 shaders. see my files here: http://www.parasitaere-kapazitaeten.net/files/2tex+gemframe.zip I would like to take the output of a shader with 2 textures and use it in another pix_texture. but I don't find the right way to do this... anybody with help? thanks over'n out (no more mail today) marius.
hello,
i change few things in your patch : remove the glsl_vertex (as only the fragment was used), remove the separator (did not understand why it was there) clean initaliation
none of this change made a diference. so i finally switch to rectangulare texturing mode, and then everything work as expected.
here is the corrected patch.
cyrille
marius schebella a écrit :
hi, I can't get gemframebuffer working with 2 shaders. see my files here: http://www.parasitaere-kapazitaeten.net/files/2tex+gemframe.zip I would like to take the output of a shader with 2 textures and use it in another pix_texture. but I don't find the right way to do this... anybody with help? thanks over'n out (no more mail today) marius.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Hi Cyrille, the patch was a part of a bigger project, so I still had vertex shader and separator in it. Later I want to trigger the first texture (now using a separate gemhead 10) and the gemchein with the shader from the same gemhead (t a a a) to make sure it is rendered before, and then I need the separator (although I also could use separate gemheads and send bang).
the problem is, that the shader now does not load on my machine.
[glsl_fragment]: m_shader: 0 35632 [glsl_program]: Info_log: [glsl_program]: ERROR: fragment shader reads varying 'texcoord0' which is not written. ERROR: fragment shader reads varying 'texcoord1' which is not written.
[glsl_program]: Link failed! [glsl_program]: vertex shader running in hardware [glsl_program]: fragment shader running in hardware
but, from your patch I see that you are using gemframebuffer behind the pix_texture. gemframebuffer always surprises me! I think that might be the solution. thanks for looking into this. marius.
cyrille henry wrote:
hello,
i change few things in your patch : remove the glsl_vertex (as only the fragment was used), remove the separator (did not understand why it was there) clean initaliation
none of this change made a diference. so i finally switch to rectangulare texturing mode, and then everything work as expected.
here is the corrected patch.
cyrille
marius schebella a écrit :
hi, I can't get gemframebuffer working with 2 shaders. see my files here: http://www.parasitaere-kapazitaeten.net/files/2tex+gemframe.zip I would like to take the output of a shader with 2 textures and use it in another pix_texture. but I don't find the right way to do this... anybody with help? thanks over'n out (no more mail today) marius.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hello,
marius schebella a écrit :
Hi Cyrille, the patch was a part of a bigger project, so I still had vertex shader and separator in it. Later I want to trigger the first texture (now using a separate gemhead 10) and the gemchein with the shader from the same gemhead (t a a a) to make sure it is rendered before, and then I need the separator (although I also could use separate gemheads and send bang).
ok.
the problem is, that the shader now does not load on my machine.
[glsl_fragment]: m_shader: 0 35632 [glsl_program]: Info_log: [glsl_program]: ERROR: fragment shader reads varying 'texcoord0' which is not written. ERROR: fragment shader reads varying 'texcoord1' which is not written.
this is a strange error : could you try to add again the vertex shader?
[glsl_program]: Link failed! [glsl_program]: vertex shader running in hardware [glsl_program]: fragment shader running in hardware
but, from your patch I see that you are using gemframebuffer behind the pix_texture. gemframebuffer always surprises me! I think that might be the solution.
hum, i don't think so. i usually put gemframebuffer before the primitive i want to draw in the framebuffer, but it should also work where you put it.
cyrille
thanks for looking into this. marius.
cyrille henry wrote:
hello,
i change few things in your patch : remove the glsl_vertex (as only the fragment was used), remove the separator (did not understand why it was there) clean initaliation
none of this change made a diference. so i finally switch to rectangulare texturing mode, and then everything work as expected.
here is the corrected patch.
cyrille
marius schebella a écrit :
hi, I can't get gemframebuffer working with 2 shaders. see my files here: http://www.parasitaere-kapazitaeten.net/files/2tex+gemframe.zip I would like to take the output of a shader with 2 textures and use it in another pix_texture. but I don't find the right way to do this... anybody with help? thanks over'n out (no more mail today) marius.
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
hi, when I add the vertex shader it works. and you are also right, that I could put the gemframebuffer anywhere. the real difference was that to get gemframebuffer working correctly I had to use Sampler2DRect.
there remains one more problem:
[gemhead] | [shader..] [from_another_frambuffer] | / [pix_texture]
that does not work, because pix_texture does not read the dimensions correctly. if I connect a pix_info to pix_texture I always get -1 -1 for width and height. I would expect that the width and height are passed from the other framebuffer. I think this is a bug. maybe the same one why I can't use gl_MultiTexCoord>0. marius.
cyrille henry wrote:
hello,
marius schebella a écrit :
Hi Cyrille, the patch was a part of a bigger project, so I still had vertex shader and separator in it. Later I want to trigger the first texture (now using a separate gemhead 10) and the gemchein with the shader from the same gemhead (t a a a) to make sure it is rendered before, and then I need the separator (although I also could use separate gemheads and send bang).
ok.
the problem is, that the shader now does not load on my machine.
[glsl_fragment]: m_shader: 0 35632 [glsl_program]: Info_log: [glsl_program]: ERROR: fragment shader reads varying 'texcoord0' which is not written. ERROR: fragment shader reads varying 'texcoord1' which is not written.
this is a strange error : could you try to add again the vertex shader?
[glsl_program]: Link failed! [glsl_program]: vertex shader running in hardware [glsl_program]: fragment shader running in hardware
but, from your patch I see that you are using gemframebuffer behind the pix_texture. gemframebuffer always surprises me! I think that might be the solution.
hum, i don't think so. i usually put gemframebuffer before the primitive i want to draw in the framebuffer, but it should also work where you put it.
cyrille
thanks for looking into this. marius.
cyrille henry wrote:
hello,
i change few things in your patch : remove the glsl_vertex (as only the fragment was used), remove the separator (did not understand why it was there) clean initaliation
none of this change made a diference. so i finally switch to rectangulare texturing mode, and then everything work as expected.
here is the corrected patch.
cyrille
marius schebella a écrit :
hi, I can't get gemframebuffer working with 2 shaders. see my files here: http://www.parasitaere-kapazitaeten.net/files/2tex+gemframe.zip I would like to take the output of a shader with 2 textures and use it in another pix_texture. but I don't find the right way to do this... anybody with help? thanks over'n out (no more mail today) marius.
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
marius schebella a écrit :
hi, when I add the vertex shader it works.
cool
and you are also right, that I could put the gemframebuffer anywhere. the real difference was that to get gemframebuffer working correctly I had to use Sampler2DRect.
there remains one more problem:
[gemhead] | [shader..] [from_another_frambuffer] | / [pix_texture]
that does not work, because pix_texture does not read the dimensions correctly. if I connect a pix_info to pix_texture I always get -1 -1 for width and height. I would expect that the width and height are passed from the other framebuffer. I think this is a bug. maybe the same one why I can't use gl_MultiTexCoord>0.
a workaround is to use a dummy image :
[gemhead] | [shader..] | [pix_image] [from_another_frambuffer] | / [pix_texture]
you'll then use the texture coordinate of the image you load, but this image is replaced by the the one from the framebuffer.
cyrille
marius.
cyrille henry wrote:
hello,
marius schebella a écrit :
Hi Cyrille, the patch was a part of a bigger project, so I still had vertex shader and separator in it. Later I want to trigger the first texture (now using a separate gemhead 10) and the gemchein with the shader from the same gemhead (t a a a) to make sure it is rendered before, and then I need the separator (although I also could use separate gemheads and send bang).
ok.
the problem is, that the shader now does not load on my machine.
[glsl_fragment]: m_shader: 0 35632 [glsl_program]: Info_log: [glsl_program]: ERROR: fragment shader reads varying 'texcoord0' which is not written. ERROR: fragment shader reads varying 'texcoord1' which is not written.
this is a strange error : could you try to add again the vertex shader?
[glsl_program]: Link failed! [glsl_program]: vertex shader running in hardware [glsl_program]: fragment shader running in hardware
but, from your patch I see that you are using gemframebuffer behind the pix_texture. gemframebuffer always surprises me! I think that might be the solution.
hum, i don't think so. i usually put gemframebuffer before the primitive i want to draw in the framebuffer, but it should also work where you put it.
cyrille
thanks for looking into this. marius.
cyrille henry wrote:
hello,
i change few things in your patch : remove the glsl_vertex (as only the fragment was used), remove the separator (did not understand why it was there) clean initaliation
none of this change made a diference. so i finally switch to rectangulare texturing mode, and then everything work as expected.
here is the corrected patch.
cyrille
marius schebella a écrit :
hi, I can't get gemframebuffer working with 2 shaders. see my files here: http://www.parasitaere-kapazitaeten.net/files/2tex+gemframe.zip I would like to take the output of a shader with 2 textures and use it in another pix_texture. but I don't find the right way to do this... anybody with help? thanks over'n out (no more mail today) marius.
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
cyrille henry wrote:
a workaround is to use a dummy image : [gemhead] | [shader..] | [pix_image] [from_another_frambuffer] | / [pix_texture]
you'll then use the texture coordinate of the image you load, but this image is replaced by the the one from the framebuffer.
thanks, I am not sure if I understand this. where exactly do I have to put the pix_image? I tried [gemhead] | [shader..] | [pix_image] [from_another_framebuffer] | / [pix_texture]
but that way, the pix_texture is always using the dummy image and not the framebuffer. marius.
marius schebella a écrit :
cyrille henry wrote:
a workaround is to use a dummy image : [gemhead] | [shader..] | [pix_image] [from_another_frambuffer] | / [pix_texture]
you'll then use the texture coordinate of the image you load, but this image is replaced by the the one from the framebuffer.
thanks, I am not sure if I understand this. where exactly do I have to put the pix_image? I tried [gemhead] | [shader..] | [pix_image] [from_another_framebuffer] | / [pix_texture]
but that way, the pix_texture is always using the dummy image and not the framebuffer.
oups, yes. your right. solution is more complex than that.
look at example 06 in 10.glsl gem example folder.
(a patch is better than any explanation...)
cyrille
marius.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
marius schebella a écrit :
cyrille henry wrote:
look at example 06 in 10.glsl gem example folder.
(a patch is better than any explanation...)
this patch still uses one texture that comes directly from an image (gemhead 17...). In my case I wanted to use both inputs from a gemframebuffer.
that's not a problem. just remove the part that load texture 2, and replace it by a copy of the part that use a glsl / framebuffer (changing texunit 3 to texunit 2).
here is the result. (shader are not relevant, but it work here) moreover, this patch is more complex than what you need, as shader output is used for next frame as shader input to create a feedback loop, but it's easy to remove this.
if you still have problem, i certainly have to create a 07 example...
cyrille
marius.
actually, the 06. patch might be more complex, but it is not doing what I need. I really need two textures, both coming from other framebuffers. and all my attempts with dummy images failed. can you have a look at my patch? I hope the zip does not get caught in the spam. thank you! marius.
cyrille henry wrote:
marius schebella a écrit :
cyrille henry wrote:
look at example 06 in 10.glsl gem example folder.
(a patch is better than any explanation...)
this patch still uses one texture that comes directly from an image (gemhead 17...). In my case I wanted to use both inputs from a gemframebuffer.
that's not a problem. just remove the part that load texture 2, and replace it by a copy of the part that use a glsl / framebuffer (changing texunit 3 to texunit 2).
here is the result. (shader are not relevant, but it work here) moreover, this patch is more complex than what you need, as shader output is used for next frame as shader input to create a feedback loop, but it's easy to remove this.
if you still have problem, i certainly have to create a 07 example...
cyrille
marius.
marius schebella a écrit :
actually, the 06. patch might be more complex, but it is not doing what I need. I really need two textures, both coming from other framebuffers.
that's what i send you in my last mail.
and all my attempts with dummy images failed. can you have a look at my patch? I hope the zip does not get caught in the spam.
ok you should not send texunit to the texture you're using to texture in a square : the 1st texture (texunit 0) is used for the texturing, so sending texunit 1 will result in corrupted data in texunit 0. so, you have to get the texture Id out of the framebuffer, and send it to an other pix_texture. this 2nd pix_texture can then be used as texunit 1...
rendering order is very important. i don't understand why frambuffer should be render before anything else. this is certainly a small bug.
so, this patch work with image. with video, you'll may have 1 frame delay.
in fact, you're right, it's not trivial, i'll may have to clean this patch and commit it to cvs.
cyrille
thank you! marius.
cyrille henry wrote:
marius schebella a écrit :
cyrille henry wrote:
look at example 06 in 10.glsl gem example folder.
(a patch is better than any explanation...)
this patch still uses one texture that comes directly from an image (gemhead 17...). In my case I wanted to use both inputs from a gemframebuffer.
that's not a problem. just remove the part that load texture 2, and replace it by a copy of the part that use a glsl / framebuffer (changing texunit 3 to texunit 2).
here is the result. (shader are not relevant, but it work here) moreover, this patch is more complex than what you need, as shader output is used for next frame as shader input to create a feedback loop, but it's easy to remove this.
if you still have problem, i certainly have to create a 07 example...
cyrille
marius.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hey cyrille, thanks a lot! everything is working now! I also think it is strange that you have to render the last texture (23) before the shader (13). is there any possibility to influence the pix size other than loading images that have the same dimen as the gemframebuffer? marius.
cyrille henry wrote:
marius schebella a écrit :
actually, the 06. patch might be more complex, but it is not doing what I need. I really need two textures, both coming from other framebuffers.
that's what i send you in my last mail.
and all my attempts with dummy images failed. can you have a look at my patch? I hope the zip does not get caught in the spam.
ok you should not send texunit to the texture you're using to texture in a square : the 1st texture (texunit 0) is used for the texturing, so sending texunit 1 will result in corrupted data in texunit 0. so, you have to get the texture Id out of the framebuffer, and send it to an other pix_texture. this 2nd pix_texture can then be used as texunit 1...
rendering order is very important. i don't understand why frambuffer should be render before anything else. this is certainly a small bug.
so, this patch work with image. with video, you'll may have 1 frame delay.
in fact, you're right, it's not trivial, i'll may have to clean this patch and commit it to cvs.
cyrille
thank you! marius.
cyrille henry wrote:
marius schebella a écrit :
cyrille henry wrote:
look at example 06 in 10.glsl gem example folder.
(a patch is better than any explanation...)
this patch still uses one texture that comes directly from an image (gemhead 17...). In my case I wanted to use both inputs from a gemframebuffer.
that's not a problem. just remove the part that load texture 2, and replace it by a copy of the part that use a glsl / framebuffer (changing texunit 3 to texunit 2).
here is the result. (shader are not relevant, but it work here) moreover, this patch is more complex than what you need, as shader output is used for next frame as shader input to create a feedback loop, but it's easy to remove this.
if you still have problem, i certainly have to create a 07 example...
cyrille
marius.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
marius schebella a écrit :
hey cyrille, thanks a lot! everything is working now!
cool
I also think it is strange that you have to render the last texture (23) before the shader (13).
23 is rendered after 13. what i think is strange is that the last framebuffer can not be computed after rendering to texunit 1 and 2 (gemhead 21 and 22)
is there any possibility to influence the pix size other than loading images that have the same dimen as the gemframebuffer?
yes, you can. in your shader, just use texcoord0 * size_frambuffer.xy / size_dummy_image.xy
cyrille
marius.
cyrille henry wrote:
marius schebella a écrit :
actually, the 06. patch might be more complex, but it is not doing what I need. I really need two textures, both coming from other framebuffers.
that's what i send you in my last mail.
and all my attempts with dummy images failed. can you have a look at my patch? I hope the zip does not get caught in the spam.
ok you should not send texunit to the texture you're using to texture in a square : the 1st texture (texunit 0) is used for the texturing, so sending texunit 1 will result in corrupted data in texunit 0. so, you have to get the texture Id out of the framebuffer, and send it to an other pix_texture. this 2nd pix_texture can then be used as texunit 1...
rendering order is very important. i don't understand why frambuffer should be render before anything else. this is certainly a small bug.
so, this patch work with image. with video, you'll may have 1 frame delay.
in fact, you're right, it's not trivial, i'll may have to clean this patch and commit it to cvs.
cyrille
thank you! marius.
cyrille henry wrote:
marius schebella a écrit :
cyrille henry wrote:
look at example 06 in 10.glsl gem example folder.
(a patch is better than any explanation...)
this patch still uses one texture that comes directly from an image (gemhead 17...). In my case I wanted to use both inputs from a gemframebuffer.
that's not a problem. just remove the part that load texture 2, and replace it by a copy of the part that use a glsl / framebuffer (changing texunit 3 to texunit 2).
here is the result. (shader are not relevant, but it work here) moreover, this patch is more complex than what you need, as shader output is used for next frame as shader input to create a feedback loop, but it's easy to remove this.
if you still have problem, i certainly have to create a 07 example...
cyrille
marius.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
cyrille henry wrote:
marius schebella a écrit :
hey cyrille, thanks a lot! everything is working now!
cool
I also think it is strange that you have to render the last texture (23) before the shader (13).
23 is rendered after 13. what i think is strange is that the last framebuffer can not be computed after rendering to texunit 1 and 2 (gemhead 21 and 22)
it is difficult to tell, whether a frame is delayed by 1, but change 13 to 24, and it still works.
is there any possibility to influence the pix size other than loading images that have the same dimen as the gemframebuffer?
yes, you can. in your shader, just use texcoord0 * size_frambuffer.xy / size_dummy_image.xy
naa, I don't want to send additional parameters to the shader, rather use a set of images with predefined sizes and swap them. I guess gemframebuffer dimen will be one of 256*256 or 320*240 or 512*512 or 1024*1024 or maybe some more. this is really a problem on the Pd side, and I would like to keep all the hacks and workarounds inside Pd, then it will work with standard shaders. marius.
marius schebella a écrit :
cyrille henry wrote:
marius schebella a écrit :
hey cyrille, thanks a lot! everything is working now!
cool
I also think it is strange that you have to render the last texture (23) before the shader (13).
23 is rendered after 13. what i think is strange is that the last framebuffer can not be computed after rendering to texunit 1 and 2 (gemhead 21 and 22)
it is difficult to tell, whether a frame is delayed by 1, but change 13 to 24, and it still works.
yes, your're right. but then, changing the 23 to 25 does not work.
is there any possibility to influence the pix size other than loading images that have the same dimen as the gemframebuffer?
yes, you can. in your shader, just use texcoord0 * size_frambuffer.xy / size_dummy_image.xy
naa, I don't want to send additional parameters to the shader, rather use a set of images with predefined sizes and swap them.
or use a pix_resize, or any object that can change/ create the size of create a dummy image
cyrille
I guess gemframebuffer dimen will be one of 256*256 or 320*240 or 512*512 or 1024*1024 or maybe some more. this is really a problem on the Pd side, and I would like to keep all the hacks and workarounds inside Pd, then it will work with standard shaders. marius.
cyrille henry a écrit :
...
in fact, you're right, it's not trivial, i'll may have to clean this patch and commit it to cvs.
done. i just commited a 07 example for multi pass rendering with shader.
now, i'd like to know why the attached example does not work: gemhead sould be in the correct order.
Cyrille
cyrille henry wrote:
cyrille henry a écrit :
...
in fact, you're right, it's not trivial, i'll may have to clean this patch and commit it to cvs.
done. i just commited a 07 example for multi pass rendering with shader.
now, i'd like to know why the attached example does not work: gemhead sould be in the correct order.
could you please send the entire patch (including the shaders). it's simpler for me to make it running then ;-)
Cyrille
I have changed messages |open multitexture_rect.vert( and |open multitexture_rect.frag( by |open multitexture.vert( and |open multitexture.frag(. And have changed [pix_image img3.jpg] by [pix_set 512 512]. I have put all in the directory : 10.glsl.
I get this error : [glsl_program]: Info_log: [glsl_program]: WARNING: Vertex shader writes varying 'texcoord2' which is not read by fragment shader. Is the problem come from the multitexture.frag and multitexture.vert ? Do you have 'multitexture_rect.vert' and multitexture_rect.frag to test ? ++
Jack
Le 31 mars 08 à 18:58, cyrille henry a écrit :
cyrille henry a écrit : ...
in fact, you're right, it's not trivial, i'll may have to clean this patch and commit it to cvs.
done. i just commited a 07 example for multi pass rendering with shader.
now, i'd like to know why the attached example does not work: gemhead sould be in the correct order.
Cyrille<07_multi_pass_rendering_normal_order_but_not_working.pd>______ _________________________________________ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hello, the problem is only a warning, so it should work anyway. but yes, there is a diference between multitexture and multitexture_rect : you can't swap them.
everything should be on the cvs.
i send a zip to this list, as an answer to Iohannes mail, but did never received it. i'll send it agin. (i'm affraid the zip file is to big).
cyrille
Jack a écrit :
I have changed messages |open multitexture_rect.vert( and |open multitexture_rect.frag( by |open multitexture.vert( and |open multitexture.frag(. And have changed [pix_image img3.jpg] by [pix_set 512 512]. I have put all in the directory : 10.glsl.
I get this error : [glsl_program]: Info_log: [glsl_program]: WARNING: Vertex shader writes varying 'texcoord2' which is not read by fragment shader. Is the problem come from the multitexture.frag and multitexture.vert ? Do you have 'multitexture_rect.vert' and multitexture_rect.frag to test ? ++
Jack
Le 31 mars 08 à 18:58, cyrille henry a écrit :
cyrille henry a écrit : ...
in fact, you're right, it's not trivial, i'll may have to clean this patch and commit it to cvs.
done. i just commited a 07 example for multi pass rendering with shader.
now, i'd like to know why the attached example does not work: gemhead sould be in the correct order.
Cyrille<07_multi_pass_rendering_normal_order_but_not_working.pd>______ _________________________________________ 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
You are right, it seems too big (because i had never received it) ! Can you send only the .vert and the .frag, then i put them in the 10.glsl directory ? ++
Jack
Le 1 avr. 08 à 18:23, cyrille henry a écrit :
hello, the problem is only a warning, so it should work anyway. but yes, there is a diference between multitexture and multitexture_rect : you can't swap them.
everything should be on the cvs.
i send a zip to this list, as an answer to Iohannes mail, but did never received it. i'll send it agin. (i'm affraid the zip file is to big).
cyrille
Jack a écrit :
I have changed messages |open multitexture_rect.vert( and |open multitexture_rect.frag( by |open multitexture.vert( and |open multitexture.frag(. And have changed [pix_image img3.jpg] by [pix_set 512 512]. I have put all in the directory : 10.glsl. I get this error : [glsl_program]: Info_log: [glsl_program]: WARNING: Vertex shader writes varying 'texcoord2' which is not read by fragment shader. Is the problem come from the multitexture.frag and multitexture.vert ? Do you have 'multitexture_rect.vert' and multitexture_rect.frag to test ? ++ Jack Le 31 mars 08 à 18:58, cyrille henry a écrit :
cyrille henry a écrit : ...
in fact, you're right, it's not trivial, i'll may have to clean this patch and commit it to cvs.
done. i just commited a 07 example for multi pass rendering with shader.
now, i'd like to know why the attached example does not work: gemhead sould be in the correct order.
Cyrille<07_multi_pass_rendering_normal_order_but_not_working.pd>____ __ _________________________________________ 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
ok. here is a tar version (without the image). i hope it will be ok. cyrille
Jack a écrit :
You are right, it seems too big (because i had never received it) ! Can you send only the .vert and the .frag, then i put them in the 10.glsl directory ? ++
Jack
Le 1 avr. 08 à 18:23, cyrille henry a écrit :
hello, the problem is only a warning, so it should work anyway. but yes, there is a diference between multitexture and multitexture_rect : you can't swap them.
everything should be on the cvs.
i send a zip to this list, as an answer to Iohannes mail, but did never received it. i'll send it agin. (i'm affraid the zip file is to big).
cyrille
Jack a écrit :
I have changed messages |open multitexture_rect.vert( and |open multitexture_rect.frag( by |open multitexture.vert( and |open multitexture.frag(. And have changed [pix_image img3.jpg] by [pix_set 512 512]. I have put all in the directory : 10.glsl. I get this error : [glsl_program]: Info_log: [glsl_program]: WARNING: Vertex shader writes varying 'texcoord2' which is not read by fragment shader. Is the problem come from the multitexture.frag and multitexture.vert ? Do you have 'multitexture_rect.vert' and multitexture_rect.frag to test ? ++ Jack Le 31 mars 08 à 18:58, cyrille henry a écrit :
cyrille henry a écrit : ...
in fact, you're right, it's not trivial, i'll may have to clean this patch and commit it to cvs.
done. i just commited a 07 example for multi pass rendering with shader.
now, i'd like to know why the attached example does not work: gemhead sould be in the correct order.
Cyrille<07_multi_pass_rendering_normal_order_but_not_working.pd>______ _________________________________________ 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
cyrille henry wrote:
ok. here is a tar version (without the image).
i have checked your original version (with the images; which i received in your direct mail; the mail to the list got stuck because of the size...). how obvious are the differences? i cannot really see a difference between the 2 results in 320x240; there are however very subtle differences when i rescale the image to 640x480.
is that's how it is meant to be?
mcg.adsr IOhannes
hello, well, difference is quite obvious, as the "not working" patch generate only a black windows.
so, i just update and recompile gem, and i've got diferent result now. in fact, everything work!
sorry, i should have tested with latest build.
so, i'll update the Gem example, in order to have the logic gemwin order.
cyrille
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
ok. here is a tar version (without the image).
i have checked your original version (with the images; which i received in your direct mail; the mail to the list got stuck because of the size...). how obvious are the differences? i cannot really see a difference between the 2 results in 320x240; there are however very subtle differences when i rescale the image to 640x480.
is that's how it is meant to be?
mcg.adsr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Hi Cyrille, I am using a gem version from some days ago. were there any changes lately? the patch you sent is only working for me, if I explicitely set the pix_texture for shader1 and shader2 to mode 0, which I had to add to the patch. for a help patch this should be included. (loadbang mode0). I am using os x and ATI X1600 and this maybe defaults to rect mode?? I am not sure what you mean with "everything working now". do you mean you can have 11->12, 21->22, 31->32, or is it still 11->21, 12->22, 33->32. (I think you know what I mean...). because the first version (which I would think is correct) still does not work for me. marius.
cyrille henry wrote:
hello, well, difference is quite obvious, as the "not working" patch generate only a black windows.
so, i just update and recompile gem, and i've got diferent result now. in fact, everything work!
sorry, i should have tested with latest build.
so, i'll update the Gem example, in order to have the logic gemwin order.
cyrille
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
ok. here is a tar version (without the image).
i have checked your original version (with the images; which i received in your direct mail; the mail to the list got stuck because of the size...). how obvious are the differences? i cannot really see a difference between the 2 results in 320x240; there are however very subtle differences when i rescale the image to 640x480.
is that's how it is meant to be?
mcg.adsr IOhannes
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
marius schebella a écrit :
Hi Cyrille, I am using a gem version from some days ago. were there any changes lately?
i was using a 1 month old Gem, and recompiling it today does change things.
the patch you sent is only working for me, if I explicitely set the pix_texture for shader1 and shader2 to mode 0, which I had to add to the patch. for a help patch this should be included. (loadbang mode0).
ok. mode 0 is the default here. i just add this loadbang to the CVS example.
I am using os x and ATI X1600 and this maybe defaults to rect mode?? I am not sure what you mean with "everything working now". do you mean you can have 11->12, 21->22, 31->32, or is it still 11->21, 12->22, 33->32. (I think you know what I mean...).
yes, i can have 11-12 21-22 etc.
because the first version (which I would think is correct) still does not work for me.
could you please test the cvs version (of Gem and of the example) and tell me if it work?
cyrille
marius.
cyrille henry wrote:
hello, well, difference is quite obvious, as the "not working" patch generate only a black windows.
so, i just update and recompile gem, and i've got diferent result now. in fact, everything work!
sorry, i should have tested with latest build.
so, i'll update the Gem example, in order to have the logic gemwin order.
cyrille
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
ok. here is a tar version (without the image).
i have checked your original version (with the images; which i received in your direct mail; the mail to the list got stuck because of the size...). how obvious are the differences? i cannot really see a difference between the 2 results in 320x240; there are however very subtle differences when i rescale the image to 640x480.
is that's how it is meant to be?
mcg.adsr IOhannes
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
ok, I tested now with the current gemversion. and it is working. did you add any additional changes to gem to get this working? I attach a screenshot to make sure (19kb)..., the flip problem is a different story... marius.
cyrille henry wrote:
marius schebella a écrit :
Hi Cyrille, I am using a gem version from some days ago. were there any changes lately?
i was using a 1 month old Gem, and recompiling it today does change things.
the patch you sent is only working for me, if I explicitely set the pix_texture for shader1 and shader2 to mode 0, which I had to add to the patch. for a help patch this should be included. (loadbang mode0).
ok. mode 0 is the default here. i just add this loadbang to the CVS example.
I am using os x and ATI X1600 and this maybe defaults to rect mode?? I am not sure what you mean with "everything working now". do you mean you can have 11->12, 21->22, 31->32, or is it still 11->21, 12->22, 33->32. (I think you know what I mean...).
yes, i can have 11-12 21-22 etc.
because the first version (which I would think is correct) still does not work for me.
could you please test the cvs version (of Gem and of the example) and tell me if it work?
cyrille
marius.
cyrille henry wrote:
hello, well, difference is quite obvious, as the "not working" patch generate only a black windows.
so, i just update and recompile gem, and i've got diferent result now. in fact, everything work!
sorry, i should have tested with latest build.
so, i'll update the Gem example, in order to have the logic gemwin order.
cyrille
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
ok. here is a tar version (without the image).
i have checked your original version (with the images; which i received in your direct mail; the mail to the list got stuck because of the size...). how obvious are the differences? i cannot really see a difference between the 2 results in 320x240; there are however very subtle differences when i rescale the image to 640x480.
is that's how it is meant to be?
mcg.adsr IOhannes
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
marius schebella a écrit :
ok, I tested now with the current gemversion. and it is working.
perfect!
did you add any additional changes to gem to get this working?
no, i did not. but someone certainly did!
I attach a screenshot to make sure (19kb)..., the flip problem is a different story...
i don't have this flip, otherwise it's ok.
cyrille
marius.
cyrille henry wrote:
marius schebella a écrit :
Hi Cyrille, I am using a gem version from some days ago. were there any changes lately?
i was using a 1 month old Gem, and recompiling it today does change things.
the patch you sent is only working for me, if I explicitely set the pix_texture for shader1 and shader2 to mode 0, which I had to add to the patch. for a help patch this should be included. (loadbang mode0).
ok. mode 0 is the default here. i just add this loadbang to the CVS example.
I am using os x and ATI X1600 and this maybe defaults to rect mode?? I am not sure what you mean with "everything working now". do you mean you can have 11->12, 21->22, 31->32, or is it still 11->21, 12->22, 33->32. (I think you know what I mean...).
yes, i can have 11-12 21-22 etc.
because the first version (which I would think is correct) still does not work for me.
could you please test the cvs version (of Gem and of the example) and tell me if it work?
cyrille
marius.
cyrille henry wrote:
hello, well, difference is quite obvious, as the "not working" patch generate only a black windows.
so, i just update and recompile gem, and i've got diferent result now. in fact, everything work!
sorry, i should have tested with latest build.
so, i'll update the Gem example, in order to have the logic gemwin order.
cyrille
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
ok. here is a tar version (without the image).
i have checked your original version (with the images; which i received in your direct mail; the mail to the list got stuck because of the size...). how obvious are the differences? i cannot really see a difference between the 2 results in 320x240; there are however very subtle differences when i rescale the image to 640x480.
is that's how it is meant to be?
mcg.adsr IOhannes
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
cyrille henry wrote:
marius schebella a écrit :
ok, I tested now with the current gemversion. and it is working.
perfect!
did you add any additional changes to gem to get this working?
no, i did not. but someone certainly did!
well, on monday i fixed the bugs reported and added the "texunit" message you proposed to [gemframebuffer].
so no need for the additional pix_texture cludge anymore.
anyhow, i am glad it works now.
apart from that i would invite everyone to use "rectangle" instead of "mode" (for [gemframebuffer] and [pix_texture]) and "dimen" instead of "dim" (for [gemframebuffer]) from now on.
fgm,adfr IOhannes
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
marius schebella a écrit :
ok, I tested now with the current gemversion. and it is working.
perfect!
did you add any additional changes to gem to get this working?
no, i did not. but someone certainly did!
well, on monday i fixed the bugs reported
thanks
and added the "texunit" message you proposed to [gemframebuffer].
wow, thanks a lot for this.
so no need for the additional pix_texture cludge anymore.
yes, it's great!
anyhow, i am glad it works now.
it even work better now. i just commit a new (simple) version of this exemple : i removed the additional pix_texture, and pix_set (marius suggestion). i also change mode to rectangle.
please, test again!
(i should also make change to the example 06... later)
cyrille
apart from that i would invite everyone to use "rectangle" instead of "mode" (for [gemframebuffer] and [pix_texture]) and "dimen" instead of "dim" (for [gemframebuffer]) from now on.
fgm,adfr IOhannes
thanks very much iohannes! what do you think about texunit in general? in theory it should be possible to use up to 8 textures for each shader. in pd practice I only can use 8 textures total... for the messages, are you using rectangle somewhere else? maybe also accept "rect", because shorter? dim instead of dimen was ok, too, actually. marius.
IOhannes m zmoelnig wrote:
cyrille henry wrote:
marius schebella a écrit :
ok, I tested now with the current gemversion. and it is working.
perfect!
did you add any additional changes to gem to get this working?
no, i did not. but someone certainly did!
well, on monday i fixed the bugs reported and added the "texunit" message you proposed to [gemframebuffer].
so no need for the additional pix_texture cludge anymore.
anyhow, i am glad it works now.
apart from that i would invite everyone to use "rectangle" instead of "mode" (for [gemframebuffer] and [pix_texture]) and "dimen" instead of "dim" (for [gemframebuffer]) from now on.
fgm,adfr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
marius schebella a écrit :
thanks very much iohannes! what do you think about texunit in general? in theory it should be possible to use up to 8 textures for each shader. in pd practice I only can use 8 textures total...
i did not try, but what happend if you have : gemhead 11 -> create a texture in texunit 1 gemhead 12 -> texunit 2 gemhead 13 -> texunit 3 ...
gemhead 20 -> using texunit 1,2 & 3 and then : gemhead 21 -> overwriting texunit 1 gemhead 22 -> " texunit 2 gemhead 23 -> " texunit 3
gemhead 30 should be able to use the new texunit (?)
for the messages, are you using rectangle somewhere else? maybe also accept "rect", because shorter? dim instead of dimen was ok, too, actually.
if you want something standard for all gem object, then gemwin should also accept dim (and not only dimen)
cyrille
marius.
IOhannes m zmoelnig wrote:
cyrille henry wrote:
marius schebella a écrit :
ok, I tested now with the current gemversion. and it is working.
perfect!
did you add any additional changes to gem to get this working?
no, i did not. but someone certainly did!
well, on monday i fixed the bugs reported and added the "texunit" message you proposed to [gemframebuffer].
so no need for the additional pix_texture cludge anymore.
anyhow, i am glad it works now.
apart from that i would invite everyone to use "rectangle" instead of "mode" (for [gemframebuffer] and [pix_texture]) and "dimen" instead of "dim" (for [gemframebuffer]) from now on.
fgm,adfr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
marius schebella wrote:
ok, I tested now with the current gemversion. and it is working. did you add any additional changes to gem to get this working? I attach a screenshot to make sure (19kb)..., the flip problem is a different story... marius.
just on short note on flipping images, an easy way to flip images is a negative value to the geo object like [square -4]. marius.
with the latest gemversion I also don't need pix_set anymore. I can now feed the right output of gemframebuffer into the right inlet of pix_texture and it will pass the correct size to the shader. and that also allows for dynamic changing. marius.
cyrille henry wrote:
marius schebella a écrit :
Hi Cyrille, I am using a gem version from some days ago. were there any changes lately?
i was using a 1 month old Gem, and recompiling it today does change things.
the patch you sent is only working for me, if I explicitely set the pix_texture for shader1 and shader2 to mode 0, which I had to add to the patch. for a help patch this should be included. (loadbang mode0).
ok. mode 0 is the default here. i just add this loadbang to the CVS example.
I am using os x and ATI X1600 and this maybe defaults to rect mode?? I am not sure what you mean with "everything working now". do you mean you can have 11->12, 21->22, 31->32, or is it still 11->21, 12->22, 33->32. (I think you know what I mean...).
yes, i can have 11-12 21-22 etc.
because the first version (which I would think is correct) still does not work for me.
could you please test the cvs version (of Gem and of the example) and tell me if it work?
cyrille
marius.
cyrille henry wrote:
hello, well, difference is quite obvious, as the "not working" patch generate only a black windows.
so, i just update and recompile gem, and i've got diferent result now. in fact, everything work!
sorry, i should have tested with latest build.
so, i'll update the Gem example, in order to have the logic gemwin order.
cyrille
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
ok. here is a tar version (without the image).
i have checked your original version (with the images; which i received in your direct mail; the mail to the list got stuck because of the size...). how obvious are the differences? i cannot really see a difference between the 2 results in 320x240; there are however very subtle differences when i rescale the image to 640x480.
is that's how it is meant to be?
mcg.adsr IOhannes
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
Ouf ! thx Marius and Cyrille ! '07_multi_pass_rendering_working_but_strange_gemhead_order.pd' work with mode 0 on the pix_texture for shader1 and shader2 on OSX.4.11 and GeForce FX 5200. ++
Jack
Le 1 avr. 08 à 20:47, marius schebella a écrit :
Hi Cyrille, I am using a gem version from some days ago. were there any changes lately? the patch you sent is only working for me, if I explicitely set the pix_texture for shader1 and shader2 to mode 0, which I had to add to the patch. for a help patch this should be included. (loadbang mode0). I am using os x and ATI X1600 and this maybe defaults to rect mode?? I am not sure what you mean with "everything working now". do you mean you can have 11->12, 21->22, 31->32, or is it still 11->21, 12->22, 33->32. (I think you know what I mean...). because the first version (which I would think is correct) still does not work for me. marius.
cyrille henry wrote:
hello, well, difference is quite obvious, as the "not working" patch generate only a black windows.
so, i just update and recompile gem, and i've got diferent result now. in fact, everything work!
sorry, i should have tested with latest build.
so, i'll update the Gem example, in order to have the logic gemwin order.
cyrille
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
ok. here is a tar version (without the image).
i have checked your original version (with the images; which i received in your direct mail; the mail to the list got stuck because of the size...). how obvious are the differences? i cannot really see a difference between the 2 results in 320x240; there are however very subtle differences when i rescale the image to 640x480.
is that's how it is meant to be?
mcg.adsr IOhannes
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
hi
marius schebella wrote:
there remains one more problem:
[gemhead] | [shader..] [from_another_frambuffer] | / [pix_texture]
that does not work, because pix_texture does not read the dimensions correctly. if I connect a pix_info to pix_texture I always get -1 -1 for
this is because [pix_info] will output information on the "pix" (that is: image-data in main memory) in the gemchain. since you don't have a "pix" in the chain, you get invalid data.
anyhow, the information about width/height should be set correctly in the texture-message you send to the right inlet of [pix_texture].
iirc, there is indeed some bug in there with the framebuffer-objects (have to check again whether i tried to fix it...)
as a workaround you can use something like:
| [$1 <width> <height> $4 $5 $6( | [pix_texture]
(or the like, i don't remember the arguments of the texture-message by heart, just print them to see what you are doing)
fmgasd.r IOhannes
IOhannes m zmoelnig a écrit :
hi
marius schebella wrote:
there remains one more problem:
[gemhead] | [shader..] [from_another_frambuffer] | / [pix_texture]
that does not work, because pix_texture does not read the dimensions correctly. if I connect a pix_info to pix_texture I always get -1 -1 for
this is because [pix_info] will output information on the "pix" (that is: image-data in main memory) in the gemchain. since you don't have a "pix" in the chain, you get invalid data.
and it's the same information that are used by the shader coordinate. so shader does have invalid data...
anyhow, the information about width/height should be set correctly in the texture-message you send to the right inlet of [pix_texture].
iirc, there is indeed some bug in there with the framebuffer-objects (have to check again whether i tried to fix it...)
as a workaround you can use something like:
| [$1 <width> <height> $4 $5 $6( |[pix_texture]
(or the like, i don't remember the arguments of the texture-message by heart, just print them to see what you are doing)
the frambuffer output is correct, but it look like pix_texture does not use this infos.
see attachement.
cyrille
fmgasd.r IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
cyrille henry wrote:
this is because [pix_info] will output information on the "pix" (that is: image-data in main memory) in the gemchain. since you don't have a "pix" in the chain, you get invalid data.
and it's the same information that are used by the shader coordinate. so shader does have invalid data...
no, why should this information be used by the shader-coordinate? (i haven't had a look at all the patches in this thread yet; probably one of the patches _does_ use the output of [pix_info] to scale some parameter; but the shader-objects themselves do not know anything about the "pix" data (e.g. the width/height as read by [pix_info]) - instead they have this data available in a more abstract way (on the openGL side))
(or the like, i don't remember the arguments of the texture-message by heart, just print them to see what you are doing)
i just noticed that [gemframebuffer] does not output the full information for the pix_texture; this should be fixed, though it shouldn't be a problem here.
the frambuffer output is correct, but it look like pix_texture does not use this infos.
hmm, it seems like your patch is working fine here. (the tex-info of the framebuffer is ok, [pix_texture] seems to respect it)
probably i should have a look at a patch where the problem is really exposed.
(and i should add better aliases for the messages to [gemframebuffer]; like "dimen" instead of "dim", and "rectangle" instead of "mode" to make it in-line with other objects...)
gmart IOhannes
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
this is because [pix_info] will output information on the "pix" (that is: image-data in main memory) in the gemchain. since you don't have a "pix" in the chain, you get invalid data.
and it's the same information that are used by the shader coordinate. so shader does have invalid data...
no, why should this information be used by the shader-coordinate? (i haven't had a look at all the patches in this thread yet; probably one of the patches _does_ use the output of [pix_info] to scale some parameter; but the shader-objects themselves do not know anything about the "pix" data (e.g. the width/height as read by [pix_info]) - instead they have this data available in a more abstract way (on the openGL side))
ok. the only problem is that in this exemple, the "more abstract way" does not work.
(or the like, i don't remember the arguments of the texture-message by heart, just print them to see what you are doing)
i just noticed that [gemframebuffer] does not output the full information for the pix_texture; this should be fixed, though it shouldn't be a problem here.
the frambuffer output is correct, but it look like pix_texture does not use this infos.
hmm, it seems like your patch is working fine here. (the tex-info of the framebuffer is ok, [pix_texture] seems to respect it)
yes, the texture is correct, but pix_info does not get the texture size. if you add a shader in this chain, then it will not work.
probably i should have a look at a patch where the problem is really exposed.
ok. you can have a look at this file. on the right : i use a pix_image to set the texture coordinate, in order to use it in the shader. without loading this (unused) image, it does not work.
you can also have a look at the exemple 06 in 10.glsl gem exemple.
(and i should add better aliases for the messages to [gemframebuffer]; like "dimen" instead of "dim",
ok
and "rectangle" instead of "mode" to make it in-line with other objects...)
pix_texture use "mode 0" and "mode 1". what object does use rectangle?
i just add a feature request to add a texunit message to the gemframebuffer, this would be very usefull.
cyrille
gmart IOhannes
cyrille henry wrote:
probably i should have a look at a patch where the problem is really exposed.
ok. you can have a look at this file. on the right : i use a pix_image to set the texture coordinate, in order to use it in the shader. without loading this (unused) image, it does not work.
so what would be the preferred way of doing it?
the attached modification of your example works fine and uses the framebuffer itself as a dummy texture. is this what you head in mind?
(and i should add better aliases for the messages to [gemframebuffer]; like "dimen" instead of "dim",
ok
and "rectangle" instead of "mode" to make it in-line with other objects...)
pix_texture use "mode 0" and "mode 1". what object does use rectangle?
[pix_texture] :-) i added this alias because i kept forgetting what "mode" actually means - the rectangle-mode, the repeat-mode, the clientstorage-mode, the quality-mode or the texenv-mode.
i just add a feature request to add a texunit message to the gemframebuffer, this would be very usefull.
i have seen it and agree.
fmasd.r IOhannes
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
probably i should have a look at a patch where the problem is really exposed.
ok. you can have a look at this file. on the right : i use a pix_image to set the texture coordinate, in order to use it in the shader. without loading this (unused) image, it does not work.
so what would be the preferred way of doing it?
i don't know what is possible. but i think that using a dummy image is strange. it would be great if this patch could work without the dummy pix_image (and then use the real texture coordinate from the frambuffer, and not the one from an other image). curently, the dummy image size should be the same as the frambuffer size. if not, you have to make correction in the shader.
the attached modification of your example works fine and uses the framebuffer itself as a dummy texture. is this what you head in mind?
(and i should add better aliases for the messages to [gemframebuffer]; like "dimen" instead of "dim",
ok
and "rectangle" instead of "mode" to make it in-line with other objects...)
pix_texture use "mode 0" and "mode 1". what object does use rectangle?
[pix_texture] :-)
ok. i did not know that. what is the oposite of rectangular?
i added this alias because i kept forgetting what "mode" actually means
- the rectangle-mode, the repeat-mode, the clientstorage-mode, the
quality-mode or the texenv-mode.
yes, i understand. could you also update the help file?
cyrille
i just add a feature request to add a texunit message to the gemframebuffer, this would be very usefull.
i have seen it and agree.
fmasd.r IOhannes
cyrille henry wrote:
i don't know what is possible. but i think that using a dummy image is strange. it would be great if this patch could work without the dummy pix_image (and then use the real texture coordinate from the frambuffer, and not the one from an other image). curently, the dummy image size should be the same as the frambuffer size. if not, you have to make correction in the shader.
the attached modification of your example works fine and uses the framebuffer itself as a dummy texture. is this what you head in mind?
so is it this what you had in mind? (using the texture-info of [gemframebuffer] and a [pix_texture] to setup the texcoords correctly)
(and i should add better aliases for the messages to [gemframebuffer]; like "dimen" instead of "dim",
ok
and "rectangle" instead of "mode" to make it in-line with other objects...)
pix_texture use "mode 0" and "mode 1". what object does use rectangle?
[pix_texture] :-)
ok. i did not know that. what is the oposite of rectangular?
non-rectangle, or 2d :-)
the "rectangle" message is really just an other name for the "mode"-message, you use it identical: [rectangle 1( - turn on rectangle texturing (of supported) [rectangle 0( - turn off rectangle texturing.
could you also update the help file?
yes, once i found the time :-)
fgmasr. IOhannes
cyrille
i just add a feature request to add a texunit message to the gemframebuffer, this would be very usefull.
i have seen it and agree.
fmasd.r IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
IOhannes m zmoelnig wrote:
so is it this what you had in mind? (using the texture-info of [gemframebuffer] and a [pix_texture] to setup the texcoords correctly)
oops, i now see that i have forgotten the attachment...sorry
fmga,sdr IOhannes
#N canvas 35 0 1245 621 10; #X obj 29 611 gemwin; #N canvas 16 329 450 300 init 0; #X obj 81 183 outlet; #X obj 81 143 loadbang; #X msg 81 163 dimen 320 240; #X connect 1 0 2 0; #X connect 2 0 0 0; #X restore 47 588 pd init; #X msg 30 541 create , 1; #X floatatom 837 34 5 0 1 0 - - -; #X obj 39 307 square 4; #X obj 39 209 gemframebuffer; #X obj 39 229 translateXYZ 0 0 -4; #X obj 689 411 pix_texture; #X obj 689 438 square 4; #N canvas 58 90 407 295 init 0; #X obj 106 175 outlet; #X msg 125 89 type FLOAT; #X msg 211 147 mode 1; #X msg 146 109 dim 512 512; #X obj 124 68 loadbang; #X connect 1 0 0 0; #X connect 2 0 0 0; #X connect 3 0 0 0; #X connect 4 0 1 0; #X connect 4 0 3 0; #X connect 4 0 2 0; #X restore 48 188 pd init; #X text 456 158 second input; #X obj 668 123 gemframebuffer; #X obj 668 145 translateXYZ 0 0 -4; #X obj 668 259 pix_texture; #X obj 668 281 square 4; #X floatatom 741 282 5 0 0 0 - - -; #N canvas 58 22 589 635 shader 0; #X obj 94 500 glsl_program; #X obj 94 340 glsl_fragment; #X obj 94 160 glsl_vertex; #X obj 172 400 pack 0 0; #X obj 162 200 change; #X obj 182 375 change; #X msg 172 420 link $1 $2; #X obj 162 220 t b f; #X obj 176 444 print linking; #X obj 94 66 inlet; #X obj 94 530 outlet; #X obj 464 245 inlet; #X msg 247 135 open v001.co2R.vert; #X msg 291 160 open v001.co2.additiveR.frag; #X floatatom 182 179 0 0 0 0 - - -; #X floatatom 234 377 0 0 0 0 - - -; #X msg 56 472 print; #X obj 275 87 change -1; #X msg 279 66 1; #X obj 275 107 t b; #X obj 279 47 gemhead 1; #X connect 0 0 10 0; #X connect 1 0 0 0; #X connect 1 1 5 0; #X connect 1 1 15 0; #X connect 2 0 1 0; #X connect 2 1 4 0; #X connect 2 1 14 0; #X connect 3 0 6 0; #X connect 4 0 7 0; #X connect 5 0 3 0; #X connect 6 0 0 0; #X connect 6 0 8 0; #X connect 7 0 3 0; #X connect 7 1 3 1; #X connect 9 0 2 0; #X connect 11 0 0 0; #X connect 12 0 2 0; #X connect 13 0 1 0; #X connect 16 0 0 0; #X connect 17 0 19 0; #X connect 18 0 17 0; #X connect 19 0 12 0; #X connect 19 0 13 0; #X connect 20 0 18 0; #X restore 668 73 pd shader; #N canvas 157 111 316 255 init 0; #X msg 93 92 type FLOAT; #X obj 93 68 t b; #X msg 113 133 mode 1; #X obj 95 47 loadbang; #X msg 102 114 dim 512 512; #X obj 93 159 outlet; #X connect 0 0 5 0; #X connect 1 0 0 0; #X connect 1 0 4 0; #X connect 1 0 2 0; #X connect 2 0 5 0; #X connect 3 0 1 0; #X connect 4 0 5 0; #X restore 687 101 pd init; #X msg 837 55 amount $1 $1 $1 $1; #X obj 51 370 loadbang; #X text 765 -14 shader with 2 textures; #X obj 786 16 cnv 15 15 15 empty empty empty 20 12 0 14 -4034 -66577 0; #X obj 800 38 cnv 15 15 15 empty empty empty 20 12 0 14 -4034 -66577 0; #X obj 874 16 cnv 15 15 15 empty empty empty 20 12 0 14 -4034 -66577 0; #X msg 838 14 0.5; #X obj 39 256 pix_image; #X msg 46 563 destroy; #X obj 13 -11 openpanel; #X msg 13 -33 bang; #X msg 13 129 open $1; #X obj 13 -50 cnv 15 15 15 empty empty empty 20 12 0 14 -4034 -66577 0; #X obj 47 81 loadbang; #X obj 42 59 list trim; #X obj 13 15 t b a; #X obj 42 37 list prepend set symbol; #X obj 39 167 gemhead 10; #X obj 39 416 pix_texture; #X obj 450 317 square 4; #X obj 450 219 gemframebuffer; #X obj 450 239 translateXYZ 0 0 -4; #N canvas 58 90 407 295 init 0; #X obj 106 175 outlet; #X msg 125 89 type FLOAT; #X msg 211 147 mode 1; #X msg 146 109 dim 512 512; #X obj 124 68 loadbang; #X connect 1 0 0 0; #X connect 2 0 0 0; #X connect 3 0 0 0; #X connect 4 0 1 0; #X connect 4 0 3 0; #X connect 4 0 2 0; #X restore 459 198 pd init; #X obj 462 380 loadbang; #X obj 450 266 pix_image; #X obj 424 -1 openpanel; #X msg 424 -23 bang; #X msg 424 139 open $1; #X obj 424 -40 cnv 15 15 15 empty empty empty 20 12 0 14 -4034 -66577 0; #X obj 458 91 loadbang; #X obj 453 69 list trim; #X obj 424 25 t b a; #X obj 453 47 list prepend set symbol; #X obj 450 426 pix_texture; #X text 38 147 first input , render whatever in a frambuffer; #X text 472 451 do the same; #X obj 39 287 pix_texture; #X obj 450 297 pix_texture; #X obj 450 177 gemhead 12; #X obj 39 347 gemhead 21; #X obj 450 357 gemhead 22; #X msg 49 389 mode 1 , texunit 1; #X msg 460 400 mode 1 , texunit 2; #X msg 728 16 tex0 1; #X msg 740 37 tex1 2; #X text 15 440 send the framebuffer to a pix_texture to load it in an other texunit; #X text 145 491 !!! rendering order is very important !!!; #X obj 711 370 loadbang; #X msg 709 390 mode 1; #X text 575 491 i don't uderstand why gemhead 13 and 23 can not be replaced by gemhead 31 and 32; #X obj 668 -13 gemhead 24; #X obj 689 346 gemhead 23; #X msg 13 107 symbol img1.jpg; #X msg 424 117 symbol img2.jpg; #X text 752 208 dummy texture (used to get texture coordinate) derived from the gemframebuffer.; #X text 671 519 ???; #X connect 1 0 0 0; #X connect 2 0 0 0; #X connect 3 0 18 0; #X connect 5 0 6 0; #X connect 5 1 36 1; #X connect 6 0 25 0; #X connect 7 0 8 0; #X connect 9 0 5 0; #X connect 11 0 12 0; #X connect 11 1 7 1; #X connect 11 1 13 1; #X connect 12 0 13 0; #X connect 13 0 14 0; #X connect 13 1 15 0; #X connect 16 0 11 0; #X connect 17 0 11 0; #X connect 18 0 16 1; #X connect 19 0 59 0; #X connect 24 0 3 0; #X connect 25 0 54 0; #X connect 26 0 0 0; #X connect 27 0 33 0; #X connect 28 0 27 0; #X connect 29 0 25 0; #X connect 31 0 70 0; #X connect 32 0 70 0; #X connect 33 0 70 0; #X connect 33 1 34 0; #X connect 34 0 32 0; #X connect 35 0 5 0; #X connect 38 0 39 0; #X connect 38 1 51 1; #X connect 39 0 42 0; #X connect 40 0 38 0; #X connect 41 0 60 0; #X connect 42 0 55 0; #X connect 43 0 49 0; #X connect 44 0 43 0; #X connect 45 0 42 0; #X connect 47 0 71 0; #X connect 48 0 71 0; #X connect 49 0 71 0; #X connect 49 1 50 0; #X connect 50 0 48 0; #X connect 54 0 4 0; #X connect 55 0 37 0; #X connect 56 0 38 0; #X connect 57 0 36 0; #X connect 58 0 51 0; #X connect 59 0 36 0; #X connect 60 0 51 0; #X connect 61 0 16 1; #X connect 62 0 16 1; #X connect 65 0 66 0; #X connect 66 0 7 0; #X connect 68 0 16 0; #X connect 69 0 7 0; #X connect 70 0 29 0; #X connect 71 0 45 0;
IOhannes m zmoelnig a écrit :
IOhannes m zmoelnig wrote:
so is it this what you had in mind? (using the texture-info of [gemframebuffer] and a [pix_texture] to setup the texcoords correctly)
well. in fact, it should work without the connection from the gemframbuffer to the pix_texture. it does not, because of the multitexture bug. (see chris answer from 11/11/2007)
but yes, your solution is great. and work when the 3 gemframbuffer are the same size. unfortunatly, it's not possible to use thid for the exemple 06, as the last part of the rendering does not use frambuffer.
cyrille
oops, i now see that i have forgotten the attachment...sorry
fmga,sdr IOhannes
I don't know if i understand all, but why don't use [pix set 512 512] (with a gemframebuffer dim 512 512) instead of [pix_image] + [openpanel] + … ? if [pix_set] could accept a message like |dimen X Y(, it would be nice. See patch attach. But i agree, an automatic method would be great (without pix_image or pix_set). ++
Jack
Le 31 mars 08 à 13:45, cyrille henry a écrit :
IOhannes m zmoelnig a écrit :
IOhannes m zmoelnig wrote:
so is it this what you had in mind? (using the texture-info of [gemframebuffer] and a [pix_texture] to setup the texcoords correctly)
well. in fact, it should work without the connection from the gemframbuffer to the pix_texture. it does not, because of the multitexture bug. (see chris answer from 11/11/2007)
but yes, your solution is great. and work when the 3 gemframbuffer are the same size. unfortunatly, it's not possible to use thid for the exemple 06, as the last part of the rendering does not use frambuffer.
cyrille
oops, i now see that i have forgotten the attachment...sorry
fmga,sdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
yes, you're right, pix_set is better than pix_image + a dummy image. but pix_set dimention can not be changed. so pix_resize is maybe even better.
i just update the gem exemple in order to use pix_set.
cyrille
Jack a écrit :
I don't know if i understand all, but why don't use [pix set 512 512] (with a gemframebuffer dim 512 512) instead of [pix_image] + [openpanel]
- Â… ?
if [pix_set] could accept a message like |dimen X Y(, it would be nice. See patch attach. But i agree, an automatic method would be great (without pix_image or pix_set). ++
Jack
Le 31 mars 08 à 13:45, cyrille henry a écrit :
IOhannes m zmoelnig a écrit :
IOhannes m zmoelnig wrote:
so is it this what you had in mind? (using the texture-info of [gemframebuffer] and a [pix_texture] to setup the texcoords correctly)
well. in fact, it should work without the connection from the gemframbuffer to the pix_texture. it does not, because of the multitexture bug. (see chris answer from 11/11/2007)
but yes, your solution is great. and work when the 3 gemframbuffer are the same size. unfortunatly, it's not possible to use thid for the exemple 06, as the last part of the rendering does not use frambuffer.
cyrille
oops, i now see that i have forgotten the attachment...sorry
fmga,sdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
I think the way this *should* work is that you just refer two textures to to your shader and reference them by the information that is coming out of the right outlet of pix_texture or gemframebuffer. I think this information contains the size of the texturedata and the type (FLOAT,...). in fact it would be great if this was somehow exchangeable format with vertex data (where rgb <-> xyz). but I have to admit that I do not understand all the wonders of opengl, eg what pixtexcoords really are. but then, glsl should not need texunit at all, but be able to take any textures by the textureID list. maybe like this: "MyTex1 texID SLOTinGLSL", where MyTex1 is the name defined in the shader, texID is the output of pix_texture and slot_in_glsl one of the 8 available slots, although this might be assigned automatically, too. It is also possible that some of my mistakes in the past occurred because I did not realize that pix_texture sends out a list!... the only thing to worry about then is the rendering order. and there seems to be weird things happening right now. I spend almost the whole day yesterday to figure out the best way to chain two framebuffers together that can be used in a glsl shader. http://www.parasitaere-kapazitaeten.net/files/2tex_shader.zip. I use now the textureID (right output of gemframebuffer) to trigger the render chain because as in the patch cyrille posted with the 5 gemheads the rendering order is not intuitive... but still, when you chain them up like in the example patch, then it is different than using gemheads. (because you *can* trigger by one cord...). marius.
IOhannes m zmoelnig wrote:
cyrille henry wrote:
probably i should have a look at a patch where the problem is really exposed.
ok. you can have a look at this file. on the right : i use a pix_image to set the texture coordinate, in order to use it in the shader. without loading this (unused) image, it does not work.
so what would be the preferred way of doing it?
the attached modification of your example works fine and uses the framebuffer itself as a dummy texture. is this what you head in mind?
(and i should add better aliases for the messages to [gemframebuffer]; like "dimen" instead of "dim",
ok
and "rectangle" instead of "mode" to make it in-line with other objects...)
pix_texture use "mode 0" and "mode 1". what object does use rectangle?
[pix_texture] :-) i added this alias because i kept forgetting what "mode" actually means
- the rectangle-mode, the repeat-mode, the clientstorage-mode, the
quality-mode or the texenv-mode.
i just add a feature request to add a texunit message to the gemframebuffer, this would be very usefull.
i have seen it and agree.
fmasd.r IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
marius schebella a écrit :
I think the way this *should* work is that you just refer two textures to to your shader and reference them by the information that is coming out of the right outlet of pix_texture or gemframebuffer. I think this information contains the size of the texturedata and the type (FLOAT,...). in fact it would be great if this was somehow exchangeable format with vertex data (where rgb <-> xyz). but I have to admit that I do not understand all the wonders of opengl, eg what pixtexcoords really are. but then, glsl should not need texunit at all, but be able to take any textures by the textureID list. maybe like this: "MyTex1 texID SLOTinGLSL", where MyTex1 is the name defined in the shader, texID is the output of pix_texture and slot_in_glsl one of the 8 available slots, although this might be assigned automatically, too. It is also possible that some of my mistakes in the past occurred because I did not realize that pix_texture sends out a list!... the only thing to worry about then is the rendering order. and there seems to be weird things happening right now. I spend almost the whole day yesterday to figure out the best way to chain two framebuffers together that can be used in a glsl shader. http://www.parasitaere-kapazitaeten.net/files/2tex_shader.zip. I use now the textureID (right output of gemframebuffer) to trigger the render chain because as in the patch cyrille posted with the 5 gemheads the rendering order is not intuitive... but still, when you chain them up like in the example patch, then it is different than using gemheads. (because you *can* trigger by one cord...).
could you post this patch?
thx cyrille
marius.
IOhannes m zmoelnig wrote:
cyrille henry wrote:
probably i should have a look at a patch where the problem is really exposed.
ok. you can have a look at this file. on the right : i use a pix_image to set the texture coordinate, in order to use it in the shader. without loading this (unused) image, it does not work.
so what would be the preferred way of doing it?
the attached modification of your example works fine and uses the framebuffer itself as a dummy texture. is this what you head in mind?
(and i should add better aliases for the messages to [gemframebuffer]; like "dimen" instead of "dim",
ok
and "rectangle" instead of "mode" to make it in-line with other objects...)
pix_texture use "mode 0" and "mode 1". what object does use rectangle?
[pix_texture] :-) i added this alias because i kept forgetting what "mode" actually means
- the rectangle-mode, the repeat-mode, the clientstorage-mode, the
quality-mode or the texenv-mode.
i just add a feature request to add a texunit message to the gemframebuffer, this would be very usefull.
i have seen it and agree.
fmasd.r IOhannes
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
I did not want to attach it, so I only gave the link to it, but here it is. marius.
cyrille henry wrote:
marius schebella a écrit :
I think the way this *should* work is that you just refer two textures to to your shader and reference them by the information that is coming out of the right outlet of pix_texture or gemframebuffer. I think this information contains the size of the texturedata and the type (FLOAT,...). in fact it would be great if this was somehow exchangeable format with vertex data (where rgb <-> xyz). but I have to admit that I do not understand all the wonders of opengl, eg what pixtexcoords really are. but then, glsl should not need texunit at all, but be able to take any textures by the textureID list. maybe like this: "MyTex1 texID SLOTinGLSL", where MyTex1 is the name defined in the shader, texID is the output of pix_texture and slot_in_glsl one of the 8 available slots, although this might be assigned automatically, too. It is also possible that some of my mistakes in the past occurred because I did not realize that pix_texture sends out a list!... the only thing to worry about then is the rendering order. and there seems to be weird things happening right now. I spend almost the whole day yesterday to figure out the best way to chain two framebuffers together that can be used in a glsl shader. http://www.parasitaere-kapazitaeten.net/files/2tex_shader.zip. I use now the textureID (right output of gemframebuffer) to trigger the render chain because as in the patch cyrille posted with the 5 gemheads the rendering order is not intuitive... but still, when you chain them up like in the example patch, then it is different than using gemheads. (because you *can* trigger by one cord...).
could you post this patch?
thx cyrille
marius.
IOhannes m zmoelnig wrote:
cyrille henry wrote:
probably i should have a look at a patch where the problem is really exposed.
ok. you can have a look at this file. on the right : i use a pix_image to set the texture coordinate, in order to use it in the shader. without loading this (unused) image, it does not work.
so what would be the preferred way of doing it?
the attached modification of your example works fine and uses the framebuffer itself as a dummy texture. is this what you head in mind?
(and i should add better aliases for the messages to [gemframebuffer]; like "dimen" instead of "dim",
ok
and "rectangle" instead of "mode" to make it in-line with other objects...)
pix_texture use "mode 0" and "mode 1". what object does use rectangle?
[pix_texture] :-) i added this alias because i kept forgetting what "mode" actually means - the rectangle-mode, the repeat-mode, the clientstorage-mode, the quality-mode or the texenv-mode.
i just add a feature request to add a texunit message to the gemframebuffer, this would be very usefull.
i have seen it and agree.
fmasd.r IOhannes
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
sorry, I forgot the "dummy-image...". included now. (sorry again for the traffic. marius.
marius schebella wrote:
I did not want to attach it, so I only gave the link to it, but here it is. marius.
cyrille henry wrote:
marius schebella a écrit :
I think the way this *should* work is that you just refer two textures to to your shader and reference them by the information that is coming out of the right outlet of pix_texture or gemframebuffer. I think this information contains the size of the texturedata and the type (FLOAT,...). in fact it would be great if this was somehow exchangeable format with vertex data (where rgb <-> xyz). but I have to admit that I do not understand all the wonders of opengl, eg what pixtexcoords really are. but then, glsl should not need texunit at all, but be able to take any textures by the textureID list. maybe like this: "MyTex1 texID SLOTinGLSL", where MyTex1 is the name defined in the shader, texID is the output of pix_texture and slot_in_glsl one of the 8 available slots, although this might be assigned automatically, too. It is also possible that some of my mistakes in the past occurred because I did not realize that pix_texture sends out a list!... the only thing to worry about then is the rendering order. and there seems to be weird things happening right now. I spend almost the whole day yesterday to figure out the best way to chain two framebuffers together that can be used in a glsl shader. http://www.parasitaere-kapazitaeten.net/files/2tex_shader.zip. I use now the textureID (right output of gemframebuffer) to trigger the render chain because as in the patch cyrille posted with the 5 gemheads the rendering order is not intuitive... but still, when you chain them up like in the example patch, then it is different than using gemheads. (because you *can* trigger by one cord...).
could you post this patch?
thx cyrille
marius.
IOhannes m zmoelnig wrote:
cyrille henry wrote:
probably i should have a look at a patch where the problem is really exposed.
ok. you can have a look at this file. on the right : i use a pix_image to set the texture coordinate, in order to use it in the shader. without loading this (unused) image, it does not work.
so what would be the preferred way of doing it?
the attached modification of your example works fine and uses the framebuffer itself as a dummy texture. is this what you head in mind?
(and i should add better aliases for the messages to [gemframebuffer]; like "dimen" instead of "dim",
ok
and "rectangle" instead of "mode" to make it in-line with other objects...)
pix_texture use "mode 0" and "mode 1". what object does use rectangle?
[pix_texture] :-) i added this alias because i kept forgetting what "mode" actually means - the rectangle-mode, the repeat-mode, the clientstorage-mode, the quality-mode or the texenv-mode.
i just add a feature request to add a texunit message to the gemframebuffer, this would be very usefull.
i have seen it and agree.
fmasd.r IOhannes
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
sorry, I forgot the "dummy-image...". included now. (sorry again for the traffic. marius.
marius schebella wrote:
I did not want to attach it, so I only gave the link to it, but here it is. marius.
cyrille henry wrote:
marius schebella a écrit :
I think the way this *should* work is that you just refer two textures to to your shader and reference them by the information that is coming out of the right outlet of pix_texture or gemframebuffer. I think this information contains the size of the texturedata and the type (FLOAT,...). in fact it would be great if this was somehow exchangeable format with vertex data (where rgb <-> xyz). but I have to admit that I do not understand all the wonders of opengl, eg what pixtexcoords really are. but then, glsl should not need texunit at all, but be able to take any textures by the textureID list. maybe like this: "MyTex1 texID SLOTinGLSL", where MyTex1 is the name defined in the shader, texID is the output of pix_texture and slot_in_glsl one of the 8 available slots, although this might be assigned automatically, too. It is also possible that some of my mistakes in the past occurred because I did not realize that pix_texture sends out a list!... the only thing to worry about then is the rendering order. and there seems to be weird things happening right now. I spend almost the whole day yesterday to figure out the best way to chain two framebuffers together that can be used in a glsl shader. http://www.parasitaere-kapazitaeten.net/files/2tex_shader.zip. I use now the textureID (right output of gemframebuffer) to trigger the render chain because as in the patch cyrille posted with the 5 gemheads the rendering order is not intuitive... but still, when you chain them up like in the example patch, then it is different than using gemheads. (because you *can* trigger by one cord...).
could you post this patch?
thx cyrille
marius.
IOhannes m zmoelnig wrote:
cyrille henry wrote:
probably i should have a look at a patch where the problem is really exposed.
ok. you can have a look at this file. on the right : i use a pix_image to set the texture coordinate, in order to use it in the shader. without loading this (unused) image, it does not work.
so what would be the preferred way of doing it?
the attached modification of your example works fine and uses the framebuffer itself as a dummy texture. is this what you head in mind?
(and i should add better aliases for the messages to [gemframebuffer]; like "dimen" instead of "dim",
ok
and "rectangle" instead of "mode" to make it in-line with other objects...)
pix_texture use "mode 0" and "mode 1". what object does use rectangle?
[pix_texture] :-) i added this alias because i kept forgetting what "mode" actually means - the rectangle-mode, the repeat-mode, the clientstorage-mode, the quality-mode or the texenv-mode.
i just add a feature request to add a texunit message to the gemframebuffer, this would be very usefull.
i have seen it and agree.
fmasd.r IOhannes
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
oups, sorry, i read your mail to fast, and did not see the link. cyrille
marius schebella a écrit :
I did not want to attach it, so I only gave the link to it, but here it is. marius.
cyrille henry wrote:
marius schebella a écrit :
I think the way this *should* work is that you just refer two textures to to your shader and reference them by the information that is coming out of the right outlet of pix_texture or gemframebuffer. I think this information contains the size of the texturedata and the type (FLOAT,...). in fact it would be great if this was somehow exchangeable format with vertex data (where rgb <-> xyz). but I have to admit that I do not understand all the wonders of opengl, eg what pixtexcoords really are. but then, glsl should not need texunit at all, but be able to take any textures by the textureID list. maybe like this: "MyTex1 texID SLOTinGLSL", where MyTex1 is the name defined in the shader, texID is the output of pix_texture and slot_in_glsl one of the 8 available slots, although this might be assigned automatically, too. It is also possible that some of my mistakes in the past occurred because I did not realize that pix_texture sends out a list!... the only thing to worry about then is the rendering order. and there seems to be weird things happening right now. I spend almost the whole day yesterday to figure out the best way to chain two framebuffers together that can be used in a glsl shader. http://www.parasitaere-kapazitaeten.net/files/2tex_shader.zip. I use now the textureID (right output of gemframebuffer) to trigger the render chain because as in the patch cyrille posted with the 5 gemheads the rendering order is not intuitive... but still, when you chain them up like in the example patch, then it is different than using gemheads. (because you *can* trigger by one cord...).
could you post this patch?
thx cyrille
marius.
IOhannes m zmoelnig wrote:
cyrille henry wrote:
probably i should have a look at a patch where the problem is really exposed.
ok. you can have a look at this file. on the right : i use a pix_image to set the texture coordinate, in order to use it in the shader. without loading this (unused) image, it does not work.
so what would be the preferred way of doing it?
the attached modification of your example works fine and uses the framebuffer itself as a dummy texture. is this what you head in mind?
(and i should add better aliases for the messages to [gemframebuffer]; like "dimen" instead of "dim",
ok
and "rectangle" instead of "mode" to make it in-line with other objects...)
pix_texture use "mode 0" and "mode 1". what object does use rectangle?
[pix_texture] :-) i added this alias because i kept forgetting what "mode" actually means - the rectangle-mode, the repeat-mode, the clientstorage-mode, the quality-mode or the texenv-mode.
i just add a feature request to add a texunit message to the gemframebuffer, this would be very usefull.
i have seen it and agree.
fmasd.r IOhannes
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
-
cyrille henry -
IOhannes m zmoelnig -
Jack -
marius schebella