> 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.
I know, and this is implied -- when using unsupported stuff, surprise, doing fancy things quickly becomes unsupported! :) (I've been trying to leave that out of the conversation to keep things generally applicable in a supported manner) I have never said that pretending the matrices were constant would work well -- in fact, I've quite openly said there are cases where even built-in things would cause it to fail. Within supported-land, these aren't as common (but still possible!), but straying into unofficial api plugin territory quickly puts you on your own. We're both saying true things here, just with different frames of reference -- I'm trying to provide the best possible "will work without adding any custom code at all" solution, which is pretty lousy and error prone, but on the other hand actually possible, and might actually work in limited subsets of use cases (George hasn't filled in any more details to know if this is relevant or useful, so I'm simply guessing). Alternatively, you're trying to provide a "works everywhere, always, no matter what" solution which is admirable and in fact correct on technical grounds (I've also said glGet is necessary for a "works everywhere, always, no matter what" solution). It also has the unfortunate side effect that it requires custom plugins and patches, which introduces its own problems should you choose to distribute/deploy your creation. :/ We're both being far too transparent to go into marketing, that's for sure :) > 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? The FOV macro patch is a private, unsupported patch. As above, using it places you on your own. (I've intentionally omitted that patch from this conversation for exactly that reason). > 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 Consumer execution order is strongly defined to be in layer order. Anything with outputs, however, is not. Thus, any patch that reads the matrices to generate output (for later mathematical operations) are at the mercy of the runtime executing them before all consumers, or in the middle of consumers, or whenever it feels like, or even not at all, in a totally arbitrary undefined manner that can change between versions. So while you could make a "poor-man's macro" by having a pair of consumers to set and then unset state with stuff in between, you couldn't depend on processor patches utilizing any of that modified state (whether or not that's important depends on the use case). That's not to say it can execute patches in an incorrect order (except for some bugs), but that you absolutely cannot and should not build patches and compositions with patch-level execution order assumptions in mind. -- 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]
