Curtis L. Olson wrote: > Erik Hofman writes: > > Curtis L. Olson wrote: > > > Erik, > > > > > > Using glGet() is considered a no-no in real time applications. That > > > stalls out the pipeline and forces all pending operations to flush > > > before the card can return with the correct answer. We might be able > > > to get away with it in limited quantities, but this can *quickly* turn > > > into a performance killer (probably varies signifantly from platform > > > to platform.) > > > > > > Please consider an alternative approach! > > > > The only thing I can think of is not using glFogf() until this issue is > > resolved. Anybody else have a suggestion? > > I haven't looked into this issue very closely. I have an nvidia card > and wasn't seeing anything odd, but perhaps I wasn't looking closely > enough. > > My gut feeling is that it is less likely that we have found a bug in > nvidia's opengl drivers and much more likely we are doing something > slightly odd, or misunderstanding the nuances of the opengl calls we > are using. > > ssg's lazy state evaulation mechanism is set up precisely so that we > can minimize state changes by note reseting things that are already > set correctly *and* avoid doing glGet()'s because the lazy state > evaluator knows the current state of all the items it tracks. > > However, ssg only tracks a limited set of parameters which is why > glPush and glPopAttrib() come in handy because they allow you to save, > change, and then restore a particular item without actually querying > it's original value.
In this case, there is a glPushAttrib in the preDraw routine and a glPopAttrib in the postDraw routine. When there is the glGet/glFog pair, things are OK, so the fog is not corrupted before the preDraw or after the postDraw. I have just checked the depth of the attrib stack before the push and after the pop, and the values are the same so there is unlikely a mismatch here. The only thing to be sure is to hack a small example program and see if it works or not. -Fred _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
