Hello Jack,
I didn't realized how using gemframebuffer is really an interesting approach, in fact there is no need to move textures with glsl because it's possible move objects rendered into the framebuffer, also the flipping problem isn't occuring anymore... The solution you are proposing here gives results I haven't expected, and might fit some other purposes that might come later, since the texture processed by glsl (tex0) isn't anymore mapped with mixed textures (tex1 and tex2)... In all cases thank you for the contribution that gave me all the solutions I need in the project I'm working on.
Colet Patrice
----- Mail original -----
De: "Jack" jack@rybn.org À: "Patrice Colet" colet.patrice@free.fr Cc: "PD List" pd-list@iem.at Envoyé: Mercredi 10 Avril 2013 17:13:07 Objet: Re: [PD] flip image in glsl
Le 10/04/2013 07:48, Patrice Colet a écrit :
Hi Jack,
the fragment code is now very short and much more elegant, certainly faster than using conditions, I guess this is due to [pix_info] that is computing dimensions of the resulting texture. This procedure seems to work for horizontal flipping then corrects strange behavior between pix_image and glsl, but vertical flipping has no consequence. It's also possible to crop using the dimen parameter, but I believe there is a zoom parameter missing to do it entirely. So I'm going to restart coding a fragment code from the basis you propose that would allow to crop both textures, because this looks fundamental for my possible use of this object, that is mainly about mixing two textures which coordinates could be modulated to fit a particular context, where textures would need to be placed accurately without having to modify it in an image editor, maybe you have an idea about how to do it simply?
You can do operations directly on vec2 instead of two floats in your fragment shader. You can also avoid condition (could be slow). See patch and glsl vertex and fragment attached for flip. ++
Jack
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->open http://lists.puredata.info/listinfo/pd-list
Hello Patrice,
Not sure to understand what you mean about the problem on horizontal/vertical flipping. Here a new patch and the fragment shader. This time, all is computed from the Gem window size. You can flip, scale and move each texture. (the flip is done from the center position of the Gemwin). In this patch, i use a workaround to avoid to see the 'border' of the texture thanks to the message [perspec( on [gemframebuffer]. I don't know if there is a better solution ? Hope it will help. ++
Jack
PS : I can clean the this patch and keep only the part about position and scale of a texture with GLSL for Gem example if it is interesting ?