Actually, this one is more complicated, because it involves the underlying pix buffer. That has nothing to do with OpenGL...
Mark
-----Original Message----- From: Chris McCormick [mailto:chris@mccormick.cx] Sent: Thursday, December 07, 2006 7:49 PM To: chris clepper Cc: Danks, Mark; Mathieu Bouchard; pd-liste; vincent Rioux; IOhannes m zmoelnig Subject: Re: [PD] pix_record mixed pixes
On Thu, Dec 07, 2006 at 01:00:04PM -0600, chris clepper wrote:
On 12/7/06, Danks, Mark MDanks@ea.com wrote:
Reversing the order pix_invert and pix_record will still apply
the
invert?it will just happen after the pix_record happens.
That is a much clearer way to say what I was try to say. The
inversion
will
not be applied to the image input to pix_record, but the processing
would
still happen.
Well, I don't want to speak for Matju, but I think what he's saying is that he realises this, but it is counter intuitive and suprising. If I have a dsp or message graph and I send the output of something through some modifiers, I don't expect those modifiers to be automatically
applied
to another cable going somewhere else. I expect modifiers further down the tree to only effect things on the same branch. Essentially, when patching Gem, you have to be even more aware of the order of
operations
than when just regularly patching dsp, because operations on one
branch
of the graph can affect operations on another branch of the graph. I guess one way to 'fix' that (and break backwards compatability) would be perform a GLPushMatrix every time there is a fork in the graph, and a GLPopMatrix every time you get to a leaf node.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx