[GEM-dev] 2textures + gemframebuffer

marius schebella marius.schebella at gmail.com
Mon Mar 31 16:44:16 CEST 2008


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 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
>>
>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2tex_shader.zip
Type: application/zip
Size: 78671 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20080331/2f746fee/attachment.zip>


More information about the GEM-dev mailing list