[GEM-dev] 2textures + gemframebuffer

[marius schebella]

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