[PD] still struggling with basic understanding of Gem dataflow
marius schebella
marius.schebella at gmail.com
Thu Mar 26 05:46:02 CET 2009
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:
>> 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.
> 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.
>> 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?
>>
>>
>> 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.
> 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.
>
> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtx_sch.pd
Type: application/x-extension-pd
Size: 4177 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20090326/d63defff/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtx_sch2.pd
Type: application/x-extension-pd
Size: 1566 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20090326/d63defff/attachment-0001.bin>
More information about the Pd-list
mailing list