Re: [Plib-devel] Texture and blend modes

[Curtis L. O. <cu...@me...>]

Steve Baker writes:
> ...in which case, the TexEnv needs to be an attribute of the
> ssgSimpleState and NOT an attribute of the ssgTexture...and come to
> think of it, in Performer they have a separate pfTexture and
> pfTexEnv - so I bet you *are* right.
> 
> Ack!  I *hate* adding things to ssgSimpleState - especially things
> that hardly anyone will ever use - because it adds to the time taken
> to determine whether the state has changed and that's a
> per-leaf-node cost.

Hmmm, yes, for flightgear, there are a couple things I'd like to see
added to ssg's lazy state evaluator ...

> > Oh, how do you set the glBendFunc ?  (Meant to ask this in the
> > original email but forgot).
> 
> Same deal - I don't bother to track it in ssgSimpleState - I only
> turn it on and off.
> 
> The deal is that the function 'ssgSimpleState::apply' is called for EVERY
> leaf node that passes the cull test.
> 
> It contains lots of nasty branch instructions (bad for performance) - but
> it's absolutely critical to minimise the amount of costly OpenGL state
> change.
> 
> The question is - which state elements really change frequently enough to
> warrant going into ssgSimpleState (and thus causing more branching) - and
> which are better handled with Draw callbacks in the application.  That
> choice is rather arbitary - and somewhat application dependent.

Let me jump in here and say that I'm not exactly 100% pleased with
handling these things via a call back function.  The call back has no
way to know the initial state of the element you are interested in
changing.  So, how do you reliably restore the value?  How do you know
if you need to actually change the state or not?  You are back to all
the problems associated with randomly changing state at random points
in your program ... these are the sorts of problems ssgSimpleState was
designed to fix.

So I suppose I could hack in my own tracking variables and sort of
parallel what ssgSimpleState is doing ... this leads to either
reimplimenting something very similar to ssgSimpleState, or coming up
with an extention to it that tracks different, less common elements?
Or more likely yields an application specific mess that is more likely
to break things in the future than work.

IMHO this extra state tracking would be best done inside ssg ... maybe
with an ssgExtendedState class or something?  It would be *really*
nice if ssg had the ability to track and control some of these less
popular states.

> I chose to include only those things that I thought a 'typical' game might
> need - and to omit everything that seemed that you'd be unlikely to want
> to change often.
> 
> By my judgement, glBlendFunc doesn't cut it because
> glEnable/Disable(GL_BLEND) lets you turn it on and off quickly for
> opaque and transparent polygons - and changing the actual blend
> function is a pretty rare event.

Blend function changing happens every frame in flight gear so we can
draw the moon with the proper phase against a changing/gradient
sky. :-)

> Hence, it's better to suffer the penalty of a costly (non-lazy)
> state change done in an application draw-callback than to burden
> every leaf node with testing for a condition that'll probably never
> come up.

But using a callback introduces more than just performance penalties.
You also run the risk of leaving the element in some unknown state
that hoses the rest of your program ... and as you well know, these
sorts of global state changes can be hard to debug if you add
something that breaks because of a mistake you made 18 months ago or
any permutation there of ...

I'm still trying to eradicate these sorts of problems from FlightGear,
but I end up being forced to put scary stuff back inside of
callbacks...

I wouldn't be surprised if the simgear sky code breaks (or is broken
by) just about every application that tries to use it for this
specific reason.  It has to use call backs to change these less
popular states, and thus by definition doesn't play nice with any
application it may be dropped into.

> Similarly, glTexEnv doesn't cut it either - I certainly don't want
> to add an extra conditional for every triangle strip for a feature
> that hardly anyone uses!

Can we have perhaps have an ssgSuperExtendedSimpleState that does
include these extra things for applications that need them?  Or
perhaps something similar to ssgSimpleState that tracks all the things
that you don't want to track in ssgSimpleState?

> Finally, I'd point out that 'ssgSimpleState' is so named because it
> is the simplest imaginable lazy state handler.  I had in the back of
> my mind that we might sometime need to create
> 'ssgComprehensiveState' that would deal with every single bit of
> OpenGL state...but S-L-O-W-L-Y.

I think we need something ... hopefully implimented in some way that
doesn't completely tank performance.

> However, it turns out that by the very nature of being a
> lazy-evaluation system, it has to store the current state in some
> kind of static storage - and that makes adding an
> 'ssgComprehensiveState' class rather tricky unless ssgSimpleState
> *also* checks all the state elements.
> 
> Well, it's not for nothing that SSG is "SIMPLE" Scene Graph.   :-)
> 
> Simplicity comes at a price.

Let me propose the following:

We could add a pointer to an ssgComprehensiveState class inside of
ssgSimpleState.  The ssgComprehensiveState would handle all those
states not handled by an ssgSimpleState.

If this extra pointer is non-null then the system would evaluate the
associated ssgComprehensiveState as well (with the corresponding
performance penalties.)  We'd also need the concept of a "default"
comprehensive state.  So if you evaulate a simple state and this extra
pointer is NULL, but the previous state's pointer wasn't, you would
diff against the default state first.  This way you could recover from
a state that does things like change glTexEnv or sets up a funky blend
function.

Curt.
-- 
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org