But Chris, that may stand for supported public API patches (No macro support, but you *can* still work around that by changing consumers that effect the various gl matrices), but what I was saying is that in Georges domain where Kineme et. all. is in use that becomes an issue. The FOV Macro patch for example will clean up once it leaves its domain (any patches outside of it will behave as through the projection matrix is the standard 'untouched' matrix), but within the FOV patch, the projection matrix must be altered by definition right? Which means you have to get that as well to be certain your math is correct to get the wanted effect?
Granted there is a pushMatrix and a popMatrix within FOV and friends, but im talking about 'in between' them, within the Macro itself when the patch is executed under the altered FOV. Unless I am drastically mistaken.. ? * Also, getting at what I was stating above about "abuse", you can write a consumer patch that calls glMatrixMode(GL_PROJECTION), glPushMatrix(); glLoadIdentity(); (of course switching back to model view after), and set it to a low layer number. Then you later on at a higher layer number run a consumer it that calls glMatrixMode(GL_PROJECTION); glPopMatrix(); (back to modelview). and you ought to be back where you left off. This is getting awefully academic now, but in theory it is doable sans private API and encapsulate a 'macro' functionality by nesting things between layers, unless, of course, Im missing some subtely of the new 10.6 QC runtime that yet again changes how layers actually run :) :P On Sep 10, 2010, at 12:33 PM, Christopher Wright wrote: >> To be fair though, you still need to run glGets on both of those matrices, >> plentry of 3rd party patches do adjust the projection matrix, so relying on >> hard coded values would not work in situations where people use, say, the >> FOV patch. > > In general, patches should not be manipulating the Projection Matrix -- doing > so is usually "wrong" > http://www.sjbaker.org/steve/omniv/projection_abuse.html > There are a few cases where it could be legitimate, but then: Supported 3rd > party patches cannot have subpatches, so they shouldn't be modifying GL state > generally in a destructive way. Supported patches also do not destructively > modify the projection matrix (FPS display does temporarily, for example, but > that's irrelevant because it cleans up after itself before anyone can > notice), so pretending it's constant is "safe" in many situations. > > Like I said before: fetching the matrices "offline", and pretending they're > constant is the only way this can work out of the box -- it /will/ have > limitations (generally, any change to either matrix will render it invalid -- > your case above is a special case of that statement), but it's "the best" you > can do without using custom patches. If you can use custom patches then this > is all irrelevant because you can just get the matrices and do the math > yourself without adding any noodle magic to the composition. > > -- > Christopher Wright > [email protected] > > >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
