David Megginson writes:
> Curtis L. Olson writes:
>
> > Ok, that was definitely helpful. If you go to src/Model/model.cxx,
> > line #248 and comment out the "Load panels" section of code, the C172
> > becomes shaded again and the objects no longer glow at night.
>
> The funny thing is that this happens even when no panel is visible.
I just committed a fix to save/restore state before drawing the '3d'
panel.
I should point out a little opengl background for those that care:
Querying the current opengl state is really bad because opengl can
pipeline commands and is a 'single' state engine. To properly answer
a query, the driver must flush the pipeline and then answer the
query. This can be very disruptive to performance, especially if done
many times per frame.
Just the act of changing opengl state (i.e. different color mode,
blend mode, changing lighting, fog, clip planes, etc.) can have an
impact on performance ... especially on systems that implement more of
the opengl pipeline in hardware. I will say that modern cards/systems
seem to be have much more optimized state changers that systems from a
a few years ago.
Even so, once you through a zillion objects into your scene each with
different textures, etc. you can imagine a zillion state changes are
needed per rendered frame. This will impact performance on any
system.
So, there are two rules of thumb when writing opengl programs. 1)
Minimize your state changes 2) never query for the current value of an
opengl state.
ssg has built in state management which does a really nice job of
minimizing state changes. It keeps track of the more common states
for you in software and effeciently checks if something needs to be
changed when ever a new ssgSimpleState is applied.
If we could do all our state management in plib/ssg, that would be
ideal. Unfortunately: the real world creeps in once in a while and we
may need to change state variables not managed by plib. So we need to
do some of our own state management which means we need to be really
careful not to confuse ssg's lazy state changer.
This means a) we need to reset any state we change when we are done,
or b) force plib/ssg to completely reset the state. Usually a) is
more efficient than b)
But, remember the 2nd rule of thumb above, "*NEVER* query for the
current opengl state." So now what? The "state" could be anything
and we need to set it back after we change it. Enter glPushAttrib() /
glPopAttrib()
There are 23 attrib bits that opengl defines for use with
gl{Push,Pop}Attrib(). Each attribute bit covers several related
opengl state variables. (See the red book for more info.)
If we plan to change a lighting related state variable and a color
related state variable in our routine we can first do:
glPushAttrib( GL_COLOR_BUFFER_BIT GL_LIGHTING_BIT );
This pushes those related state variables onto the stack. We don't
care what they are, we aren't querying their value, but we are saving
them.
Then the routine can proceed to do whatever it needs to do.
Finally at the end we do:
glPopAttrib();
So there you go, we saved and restored the opengl state so we didn't
confuse plib/ssg or leave some weird state value set that screws up
some other rendering portion of the code. We hopefully have minimized
any needed state changes. And we managed to do it all without
querying for a specific state value and thus disrupting the pipeline.
Again all this is said with apologies to those that know more about
this than I do. :-)
Regards,
Curt.
--
Curtis Olson IVLab / HumanFIRST Program FlightGear Project
Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED]
Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
