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