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 ?