Re: [Plib-devel] Texture and blend modes

[Steve B. <sjb...@ai...>]

"Curtis L. Olson" wrote:
> 
> Steve Baker writes:
> > > Hmmm, yes, for flightgear, there are a couple things I'd like to see
> > > added to ssg's lazy state evaluator ...
> >
> > What - specifically?
> 
> Here are the additional things that the flight gear sky needs to
> control:
> 
> - GL_DEPTH_TEST (enable/disable)

I bet you are turning this off for the same reason that I used to - which
is the advice in the RedBook (which I may actually have passed on to you)
that says that you should try to keep the far-clip plane as close as
possible to the eye.

It turns out that this was poor advice (although strictly speaking not
incorrect) - a fact which is explained here:

  http://web2.airmail.net/sjbaker1/love_your_z_buffer.html

There are *still* some circumstances where turning of Z-test is good - but
there are a lot less of them than there ought to be.

> - GL_FOG        (enable/disable)  We don't change the fog function,
>                                   and the fog parameters are global,
>                                   but this might change somewhat if we
>                                   want to impliment some sort of extra
>                                   "punch through" for lights

We could add a Fog enable/disable fairly cheaply since ssgSimpleState
tests all the enable/disable flags in parallel.

> - glBlendFunc()

That's one of the things that I'd prefer to avoid.
 
> This is all true from a pure performance perspective.  Perhaps I
> should just give up on the idea of building a completely drop in sky
> that will work with any ssg friendly application.

Yikes!  If pursuasion fails - use bribery!  :-)
 
> You could impliment a state management extension scheme at the cost of
> one extra check per node.  If this check indicates there is extra
> state info for this node (or the previous node), then you branch off
> and do all the extra work to handle it.  Or in the case that the
> current node has no extra state info, but the previous node did, you
> would have to do extra work to restore all the changed items to their
> default state.

Yep - that's basically what I suggest in my non-preferred solution.
 
> You could keep an extra variable around ... something like:
> 
>   bool last_node_had_extended_state;
> 
> If you process a node with extended state you set this to false.

Well, it could be another flag in the flags field that ssgSimpleState
currently maintains.
 
> I think we are approaching this from different mind sets.
> 
> You are talking in terms of performance and commonly used states.

Yes.
 
> I am talking in terms of developing robust applications that have some
> sensible, reliable scheme to manage all the state changes needed by
> the application.  It's critical for an application with the scope and
> number of participant such as flightgear, that we get a handle on
> *all* the state changes and do it in a consistant, robust manner.
> Mixing and matching schemes points you straight down the road to
> disaster.  FlightGear has been dancing on the edge throughout it's
> entire existance.  I'm searching for a way to resolve these issues.
> As it is, I keep having to go back and try to figure out which global
> state change in one part of the code is messing up the rest of the
> code.  This is hard, it is frustrating, it is time consuming, and each
> time I have to do it I hate the mess even worse.  I want a nice, well
> thought out, robust way to deal with this.
> 
> The most sensible place to start with this (I believe) is inside ssg.

Well, basically, there is some messiness to handle - and it could rest
in the application or inside SSG. The relative benefits depend on the
frequency of usage again.  If it's something that every application
needs - then clearly SSG is a good place for it.  If only one application
wanted it - then obviously SSG is not the right place.  This problem
falls somewhere between those two extremes.

The entire reason that SSG has callback functions in DRAW is to allow
application-specific extensions.  Some Scene Graph API's have taken
the conscious decision to COMPLETELY hide OpenGL from the application
(OpenSG for example takes this philosphy - I was talking to it's author
at the SigGraph Papers' party and contrasting this behaviour with SSG's).

I don't think you'd like that.

SSG takes the approach that Performer takes which is NOT to attempt to
be all things to all men - but to at least provide enough hooks to
make anything possible - with some effort on the application side at
least.

> What if I want to drop the FlightGear sky module into some application
> that doesn't use the default blend function?  Now my sky will break
> that application, and perhaps do it in a non-obvious way.  These
> global state screw ups can suck up huge amounts of debugging time for
> large complex applications where lots of people have their fingers in
> the pie.

Yep...but moving that debugging into SSG doesn't help that.  If it's a
feature that most applications will use, you are saving most people that
debugging effort - but moving bugs down into a layer where you can't see
them doesn't help where just one or two applications are concerned.
 
> Yes, we can (and do) make do with what we have.  We find work arounds,
> we debug the state screw ups ... until the next time someone needs to
> change or use one of these uncommon states at which point we are
> plunged right back into the front end of this whole process of
> figuring out why our rendering is all screwed up (again).

I think the majority of your (and my) problems with debugging state
management has been because Mesa is/was broken.  Various push/pop
attrib commands weren't working, the ambient lighting code was
broken, etc, etc.

Since I've started using the nVidia drivers, I've not had a single
state management problem.

> > No - you just have to turn the blend mode back to 'normal' in the
> > post-draw callback.
> 
> Which you can't do in the case of my sky code because it doesn't
> necessarily know what "normal" is for the host application.

glPushAttrib/glPopAttrib ?
 
Call one in pre-draw and the other in post-draw.

> > That's certainly an issue.  But for *just* the moon, I'd toss in a
> > dirty 'glGet' to find the current blend mode so you can restore it
> > in post-draw.  Once per frame isn't going to kill anyone.
> 
> Is this really true?  I've never tried it glGet() in the primary
> render loop.  I'd imagine for current PC consumer cards or Mesa based
> drivers this would be fast, but what about higher end system?  What
> about disrupting the render pipeline?  This sounds ugly. :-)

It certainly does cause a pipeline flush on SGI machines - but it doesn't
kill performance on nVidia drivers or any of the software T&L setups that
I know of.
 
Hoever, glPushAttrib/glPopAttrib are pipelinable - I already use them
in PUI.

> > Well, as I explained before, it isn't that simple because if
> > ssgHyperExtendedState doesn't clean up the wierd stuff it changed
> > then the next ssgSimpleState that comes along will have to do so.
> > That's an additional cost for every ssgSimpleState which you can't
> > justify unless there are a heck of a lot of ssgHyperExtendedState
> > leaf nodes out there.
> 
> Well, it's only one test per node, well more like one if statement:
> 
> if ( ssgHyperExtendedState != null || ssgLastStateWasHyperExtended ) {
>     // process ssgHyperExtenedState
> }
> 
> processing a null ssgHyperExtendedState would be defined as restoring
> (anything that was previously changed) back to ssg defaults.

Yes - I guess so.
 
> > The bottom line for me is that this stuff simply isn't common enough
> > to warrant all the work and complexity.
> 
> And I will argue that it is *important* enough for building *robust*
> applications that we do need some mechanism to assist the application
> in reliably managing these less used states.

Well, as I said, *I* don't want to spend the effort to do this.

If you can cause minimal impact to performance, I'll accept a
change to ssgSimpleState to handle complex state changes - but
I don't have the time (or the inclination) to go to the hassle
of writing and debugging such a thing myself.
 
> I have no idea how many hours I've spent trying to chase down state
> problems in flight gear.  To be fair, some of these have been due to
> my own stupidity or lack of understanding of opengl, some of this has
> been do to Mesa bugs, but much of this could be saved (or prevented in
> the future) by adding some mechanism to help manage these state
> changes robustly.

Well, I know that essentially ALL the hours I've spent doing this have
been a complete waste because ALL the bugs were eventually shown to be
in Mesa - every one of them.  I think the ssgState code in the very
first revision of SSG was in fact perfect!
 
> > Certainly the FlightGear moon doesn't come even close to meeting
> > that criteria since all this work would slow *everyone* down a
> > little - yet providing no speedup at all to FlightGear!  To the
> > contrary - it would actually slow FGFS down some too!
> 
> I would honestly pay that price if it meant we gained a sensible way
> to deal with all our state headaches.

I think if you simply employed an appropriate glPushAttrib in your
pre-draw callback and a glPopAttrib in post-draw and did your
'special' state setting there, you'd have no problem - except for
those in Mesa that you can't fix with any of these mechanisms.

You'd have a couple of special state hacks in the sky model - but
that's really about it.

You need to spend 8 years arguing with the Performer team to gain
some perspective on what level of perfection to expect if you
still want performance!

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net