[GEM-dev] 2textures + gemframebuffer
marius schebella
marius.schebella at gmail.com
Mon Mar 31 16:48:43 CEST 2008
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 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.pd
Type: application/x-extension-pd
Size: 1837 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20080331/1f2c228b/attachment.bin>
More information about the GEM-dev
mailing list