hi, I think your pix_coordinate idea was not that bad (see attached patch). but that is probably not what you want??on the other hand, using pdp_rotate and converting twice is really eating up a lot of cpu. pdp is a different world again and the bridge between pdp and gem is buggy (your patch crashed my computer for example). but again, as chris said. there is a difference between rotating the content of the pix data and rotating the geometry that this data is mapped to. so the second patch shows, what I think you really want. rotate an image and then feed this into your pix_rtx.
marius.
John Harrison wrote:
This is extremely helpful. I'm starting to "get" it. Comments/questions inline.chris clepper wrote:would [pix_coordinate] be an exception to this? I've been playing with it and it seems to behave the way you have described OpenGL objects and not GEM objects. I read the help patch about [pix_texture] reassigning the coordinate values, but that still didn't explain all the behavior I was seeing.There are two types of objects in GEM: pix and OpenGL. Pix objects do work in the top to bottom manner like Pd DSP objects.The convention in GEM is to put the GL objects after the pix_ ones showing that once the pix_ processes are done on the CPU it is time for the GL processes on the GPU to start.I understand you to be saying that the GL processes will always be applied after the pix_ processes. If that is the case, then it sounds like there is no way to have [rotateXYZ] applied before [pix_rtx]. Makes sense.For the more general case, is it correct that there is no way in GEM to give an arbitrary rotation of an image as input to a pix_ object since there is no Gem pix_ object with arbitrary rotation function?Figuring that might be the case, I tried to build [pix_rotate] using [pix_coordinate]...and this led me to the question about about [pix_coordinate]Using pdp_rotate, pix_2gem and gem2pdp, I did successfully build a pix_ rotator. On the chance it might be helpful to see, I attached a demo patch which feeds a rotated video stream to [pix_rtx] then rotates the stream back to the way it was. While it more-or-less works it seems a bit scabby. Is there a better way?As long as I can make sense of what the rules are, which objects break them, and some rough idea as to why, I'm cool with that.There are lots of exceptions to Pd rules in GEM and there is really no way around them. It is kind of like learning English - I before E except after C, excepting all of those words that ignore the rule.Thank you again for your help. As Hans suggests, I'd like to find a way to help organize, then share this information, whether it be on the wiki or in some other meaningful way.-John
rtx_sch.pd
Description: application/extension-pd
rtx_sch2.pd
Description: application/extension-pd
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
