[GEM-dev] 2textures + gemframebuffer

[cyrille henry]

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