plib-devel

Re: [Plib-devel] Terrain optimization in ssg?

[Gil C. <g.c...@ca...>]

At 02:15 PM 8/20/00 -0400, you wrote:
>I seem to remember a while back that someone
>was talking about adding one of the terrain optimization
>algorithms (ala ROAM and others) to ssg.  Does anyone
>know who brought this up and if anything has been done about
>it?

Well, I did mention it about a fortnight ago as a possible future 
contribution, but my efforts are currently on the VRML import/export 
followed by documentation and then the ssgStatistics module.  I think that 
it will be a fair while before I get to implementing ROAM for PLIB in my 
spare time!

That said, ROAM is only one of a number of continuous level of detail 
schemes for real time rendering - albeit a fairly oft-discussed one.  If 
you're thinking of doing some work on a CLOD system for PLIB, you might 
like to also look at some of the other methods of doing it - adaptive 
quadtrees, view independent progressive meshes and bin tri-trees, as well 
as simple distance based switching of meshes.  Ben Discoe's VTerrain site 
has a good summary of these techniques, with links to their original papers 
at http://vterrain.org/LOD/published.html

Gil
---------------------------------------------------------------------
3D Graphics Programmer
CSIRO Minesite Imaging Group
Pinjarra Hills, QLD, AUSTRALIA
http://www.cat.csiro.au/automation/projects/SurMap.htm

"Experience is something you don't get until just after you need it"
---------------------------------------------------------------------

[Plib-devel] Terrain optimization in ssg?

[Brian N. <ze...@on...>]

I seem to remember a while back that someone
was talking about adding one of the terrain optimization
algorithms (ala ROAM and others) to ssg.  Does anyone
know who brought this up and if anything has been done about
it?

-Brian

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

Re: [Plib-devel] Texture and blend modes

[Sam S. <sa...@sp...>]

Well it's nice to know that there was a simple answer, and I didn't open a
can of worms or anything :)

Re: [Plib-devel] Texture and blend modes

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

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)
- 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 
- glBlendFunc()

> For things in callbacks, you know the default state because you can
> set it before calling ssgCullAndDraw and be sure that SSG won't
> mess with it (unless I have an error).  Then you have to set it
> (unconditionally) to what you want in the pre-Draw and restore it
> to the default state in post-Draw.
>
> Whether it's better to use that mechanism or a lazy evaluation
> mechanism depends on:
>
>   * The cost to test whether the state is already what you need
>     MULTIPLIED by the number of leaf nodes that DON'T use that
>     state.
>
> Versus:
>
>   * The cost to redundantly set and unset the state MULTIPLIED by the
>     number of leaf nodes that need that state.
>
> When the number of leaf nodes containing the state is small, it's
> better to use a callback and suffer the cost of switching it redundantly.
>
> When the number of leaf nodes containing the state is large, it's
> worth paying the penalty to check for it in order to save redundant
> state changes.

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.

> Now - where that balance lies clearly depends on the application.
> Take something like glTexEnv.  I have probably used it once - on
> one leaf node once during my entire career.  For me at least, this
> doesn't warrant putting into ssgSimpleState - it's FAR better to
> put it into a node callback.

What I'm arguing for is some sort ssg mechanism that helps the user do
this robustly ...

> Look at something like glBindTexture though - and every single
> leaf node needs to be checked - so it's worth putting into
> ssgSimpleState.
>
> Notice also that with draw callbacks, you can put them higher
> up in the scene graph - so if you have an entire character in
> a game that needs some peculiar glBlendFunc (a Ghost for example),
> then you can put the state change up at the root of that
> objects scene graph rather than on every leaf node.
>
> The problem here is that SSG is used for a lot of things - and
> my personal choice of what things should or should not make it
> into ssgSimpleState may not agree with yours...so we should
> discuss the matter and see where we should compromise.

I'm not opposed to leaving ssgSimpleState essentially as it is, I'm
just wishing that ssg provided some mechanism to thelp the application
robustly handle management of some of these less common states.

> > So I suppose I could hack in my own tracking variables and sort of
> > parallel what ssgSimpleState is doing ...
>
> That's very hard to do because your post-draw callback can't tell
> whether some other leaf node (without a pre-draw callback) will be
> drawn next or whether you can safely leave the state at this
> new (non-standard) setting ready for the next leaf node that
> needs it.

Exactly why it would be nice to have some sort of ssg mechanism to
assist with this.

> Worse than that.  You'd have to apply it to EVERY leaf node.

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.  But you absolutely cannot mix ssgSimpleStates with other
> state management schemes.

I'd argue that you could (as described above) at the cost of one extra
check per node.

> Well, as I've explained, you can't do that because when this
> ssgExtendedState leaf node finishes rendering, it mustn't leave the
> extended state elements turned on because a subsequent
> ssgSimpleState doesn't do the testing to turn it back off again.
> That's why it's all-or-nothing...and why I don't want to do this.

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.

If you process a node without extended state (but this variable is
true) then you do the extra work of restoring the less common states
to their defaults, then you set this variable to false.

> I'd be VERY interested to hear which states you think are common
> enough to need to be changed lazily and which ones can be set in
> callbacks.  Since you are building a flight sim - and I'm not
> unfamiliar with the needs of such programs :-) ...I can't imagine
> what you are changing that is so commonly required.

I think we are approaching this from different mind sets.

You are talking in terms of performance and commonly used states.

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.

> Yes - but that's ONE leaf node (probably).  You can't possibly justify
> adding another conditional test before every single one of the 10,000
> or so other leaf nodes you are probably drawing just to save...well - nothing
> actually.  You still have to switch to the special blend mode before
> drawing the moon - and it would be restored again by the very next polygon
> to be drawn - lazy state evaluation would save you exactly nothing in that
> case.
>
> If you had (say) 100 moons to draw randomly throughout the scene - then
> I might be pursuaded.
>
> This example is a CLASSIC case of why I don't want to put the blendfunc
> into ssgSimpleState.

... and it is a CLASSIC case of why ssg needs some mechanism to handle
these state changes.

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.

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).

> 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.

> I think that this could be attacked in one of two ways:
>
>   1) We could add code for all the rarely used states which would
>      be tested for in one step in ssgState.  ie we'd have a "Weird State"
>      flag that ssgSimpleState would test for.  If that flag were to
>      be TRUE, then it would do a lot of unconditional state changes
>      and tell the leaf node to call a special restoration function
>      after the user's post-draw callback was called.  That adds two
>      more conditionals to every leaf node - but we could perhaps
>      win that back by moving some of the more obscure existing
>      ssgSimpleState lazy elements into the non-lazy code.
>
>   2) Documentation.  We need to write down precisely which state
>      elements SSG chooses to manage - and which ones the application
>      is responsible for.  We also need to write down the default states
>      of those elements.
>
> Remember about the 'which item Steve prefers in a list' thing?  :-)

I don't think we can just document away all the difficulties here.  I
prefer the approach I described above which is similar to your (1) but
only costs one extra test per node ... until you hit something that
uses the extended state mechanism.  But you, the application writer,
understand that you maybe trading some performance for a reliable
extended state handling scheme.  But in the case of flightgear, this
will only happen on a couple nodes per frame so the actual perfomance
cost will be minimal.

> 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. :-)

> 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.

> Well, I *think* that's my (1) above - although maybe not.  (1) above
> is NOT a lazy evaluation scheme...although you could make it so at
> some cost.
>
> 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.

> I need to be convinced that there are enough nasty things that
> ssgSimpleState can't handle to make this worthwhile.  Right now,
> I'm very reluctant to add a single line of code to ssgState
> or ssgLeaf or their descendants because doing so slows down every
> single SSG application by a measurable amount.

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.

Most of the arguments that led you to develop ssgSimpleState should
apply here to extended states as well.  Certainly performance is a
consideration, but so is code robustness and code maintainability for
larger projects.  Maybe your typical game is hacked together in a year
or so and has a shelf life of a couple of months ... a few dirty
tricks here or there isn't going to hurt anyone, and even if it does,
six months down the line no one will care.  But FlightGear is a *long*
term application ... any hack we do now will come back to bite us
later.  I've seen it happen many times already.

> 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.

Sooner or later, (actually just sooner) the flightgear project is
going to need some good mechanism to deal with these less common state
changes.  It will have to either go into the FlightGear code, the
SimGear code, or the ssg code.

I vote for putting it into ssg, but perhaps I'll have to settle for
some other place if that's not possible.

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

RE: [Plib-devel] Texture and blend modes

[Norman V. <nh...@ca...>]

Steve Baker writes:
>
>"Curtis L. Olson" wrote:
>
>> Hmmm, yes, for flightgear, there are a couple things I'd like to see
>> added to ssg's lazy state evaluator ...
>
>What - specifically?
>
>> 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.
>
>Well, that's why you have to decide which things to test before EVERY
>leaf node is drawn - and which to set and restore in callbacks.

A slightly different but related question.

Is it possible to design a branch node that does some of this ?

By this I mean that I know that everything below this node
will share a common property.  Hence short circuting some state
change tests at the leaf level for all deeper nodes.

This would allow programs such as flightgear that use
a higher level bucketing mechanism then OpenGL primitives
to minimize state changing when traversing the tree

I can envision a similar node type being used for compiled vertex arrays,

simplistically

            bucket node  ( lock vertices and set transform here when
entering bucket )
              /     |      \          ( if node passes Bounding Sphere
test )
            /       |        \
     mat1     mat2    mat3  ( set display states here )
                 /  |  \               ( should these nodes have Bounding
Spheres  ?)
               /    |    \
         Fan  Fan  Strip      ( set texture coordinates and Fine grained BS
based Display )

Maybe just a 'short-circut-me' bit in the SimpleState
and a would allow this

Does this make any sense ??

Norman

[Plib-devel] RE: TODO list in Word

[tjones <tj...@is...>]

Oh, one more thing, thanks dave for looking at the file, you must be a very
brave man for opening a win word doc.

HEHE.

Later Ben

[Plib-devel] Reply to TODO list in word crap.

[tjones <tj...@is...>]

No god no, i would not send a word doc, to a bunch of unix people, that and
I had more then enough trouble with windows text or doc files. But I did
make a mistake, i ment to say unitext (what stuff that is not from windows).
I personally hate when people send me text files from windows and everything
gets all messed up, everything is on one line and you have to run a dos2unix
program on the thing to read it.
The rest I said for all the windows people wordpad will read it, cause it
does a fine job with unix formated text files.
Sorry Steve, I had not planned on giving everybody a heart attack. I only
run linux (although I am in wincrap now, not my computer, have to deal).

Later Ben

FROM: Steve Baker
DATE: 08/18/2000 16:22:37
SUBJECT: RE:  [Plib-devel] TODO list



> Dave McClurg wrote:
>
> > AAAAArrrrrggggghhhhh!!!!
> >
> > You emailed a Microsoft Word document!!
> >
> > <Please imagine about three pages of ranting, insults, abuse,
> > etc - nah - what
> > the heck - make that four pages>
> >
> lol. it wasn`t a word doc. it was the TOBEDONE file from plib CVS.
> outlook did something funny to it when i attached it to the message
> since it didn`t have an file extension.

Well *thats* a relief.  I just about to go and scrub my motherboard
with Clorox.

  :-)

--
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

_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel

Re: [Plib-devel] TODO list

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

> Dave McClurg wrote:
> 
> > AAAAArrrrrggggghhhhh!!!!
> >
> > You emailed a Microsoft Word document!!
> >
> > <Please imagine about three pages of ranting, insults, abuse,
> > etc - nah - what
> > the heck - make that four pages>
> >
> lol. it wasn't a word doc. it was the TOBEDONE file from plib CVS.
> outlook did something funny to it when i attached it to the message
> since it didn't have an file extension.

Well *thats* a relief.  I just about to go and scrub my motherboard
with Clorox.

  :-)

-- 
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

RE: [Plib-devel] TODO list

[Dave M. <Dav...@dy...>]

> AAAAArrrrrggggghhhhh!!!!
> 
> You emailed a Microsoft Word document!!
> 
> <Please imagine about three pages of ranting, insults, abuse, 
> etc - nah - what
> the heck - make that four pages>
> 
lol. it wasn't a word doc. it was the TOBEDONE file from plib CVS. outlook
did something funny to it when i attached it to the message since it didn't
have an file extension.

--Dave

Re: [Plib-devel] Texture and blend modes

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

"Curtis L. Olson" wrote:

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

What - specifically?
 
> 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.

Well, that's why you have to decide which things to test before EVERY
leaf node is drawn - and which to set and restore in callbacks.

For things in callbacks, you know the default state because you can
set it before calling ssgCullAndDraw and be sure that SSG won't
mess with it (unless I have an error).  Then you have to set it
(unconditionally) to what you want in the pre-Draw and restore it
to the default state in post-Draw.

Whether it's better to use that mechanism or a lazy evaluation
mechanism depends on:

  * The cost to test whether the state is already what you need
    MULTIPLIED by the number of leaf nodes that DON'T use that
    state.

Versus:

  * The cost to redundantly set and unset the state MULTIPLIED by the
    number of leaf nodes that need that state.

When the number of leaf nodes containing the state is small, it's
better to use a callback and suffer the cost of switching it redundantly.

When the number of leaf nodes containing the state is large, it's
worth paying the penalty to check for it in order to save redundant
state changes.

Now - where that balance lies clearly depends on the application.
Take something like glTexEnv.  I have probably used it once - on
one leaf node once during my entire career.  For me at least, this
doesn't warrant putting into ssgSimpleState - it's FAR better to
put it into a node callback.

Look at something like glBindTexture though - and every single
leaf node needs to be checked - so it's worth putting into
ssgSimpleState.

Notice also that with draw callbacks, you can put them higher
up in the scene graph - so if you have an entire character in
a game that needs some peculiar glBlendFunc (a Ghost for example),
then you can put the state change up at the root of that
objects scene graph rather than on every leaf node.

The problem here is that SSG is used for a lot of things - and
my personal choice of what things should or should not make it
into ssgSimpleState may not agree with yours...so we should
discuss the matter and see where we should compromise.

> So I suppose I could hack in my own tracking variables and sort of
> parallel what ssgSimpleState is doing ... 

That's very hard to do because your post-draw callback can't tell
whether some other leaf node (without a pre-draw callback) will be
drawn next or whether you can safely leave the state at this
new (non-standard) setting ready for the next leaf node that
needs it.

> this leads to either
> reimplimenting something very similar to ssgSimpleState...

Worse than that.  You'd have to apply it to EVERY leaf node.

It would be better to derive a new kind of ssgState and either
use your own loaders - or walk the scene graph after loading it
from disk replacing all the ssgSimpleState's with ssgCurtStates.

Yuck.

> or coming up with an extention to it that tracks different, less
> common elements?

Yep.  But you absolutely cannot mix ssgSimpleStates with other
state management schemes.

> 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.

Well, as I've explained, you can't do that because when this ssgExtendedState
leaf node finishes rendering, it mustn't leave the extended state elements
turned on because a subsequent ssgSimpleState doesn't do the testing to turn
it back off again.  That's why it's all-or-nothing...and why I don't want to
do this.

I'd be VERY interested to hear which states you think are common enough to
need to be changed lazily and which ones can be set in callbacks.  Since
you are building a flight sim - and I'm not unfamiliar with the needs of
such programs :-) ...I can't imagine what you are changing that is so
commonly required.

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

Yes - but that's ONE leaf node (probably).  You can't possibly justify
adding another conditional test before every single one of the 10,000
or so other leaf nodes you are probably drawing just to save...well - nothing
actually.  You still have to switch to the special blend mode before
drawing the moon - and it would be restored again by the very next polygon
to be drawn - lazy state evaluation would save you exactly nothing in that
case.

If you had (say) 100 moons to draw randomly throughout the scene - then
I might be pursuaded.

This example is a CLASSIC case of why I don't want to put the blendfunc
into ssgSimpleState.

> > 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 ...

No - you just have to turn the blend mode back to 'normal' in the post-draw
callback.

> 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 ...

Indeed.
 
> 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 think that this could be attacked in one of two ways:

  1) We could add code for all the rarely used states which would
     be tested for in one step in ssgState.  ie we'd have a "Weird State"
     flag that ssgSimpleState would test for.  If that flag were to
     be TRUE, then it would do a lot of unconditional state changes
     and tell the leaf node to call a special restoration function
     after the user's post-draw callback was called.  That adds two
     more conditionals to every leaf node - but we could perhaps
     win that back by moving some of the more obscure existing
     ssgSimpleState lazy elements into the non-lazy code.
 
  2) Documentation.  We need to write down precisely which state
     elements SSG chooses to manage - and which ones the application
     is responsible for.  We also need to write down the default states
     of those elements.

Remember about the 'which item Steve prefers in a list' thing?  :-)

> 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.

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.
 
> > 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?

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.

> 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.

Well, I *think* that's my (1) above - although maybe not.  (1) above
is NOT a lazy evaluation scheme...although you could make it so at
some cost.

The bottom line for me is that this stuff simply isn't common enough
to warrant all the work and complexity.

I need to be convinced that there are enough nasty things that
ssgSimpleState can't handle to make this worthwhile.  Right now,
I'm very reluctant to add a single line of code to ssgState
or ssgLeaf or their descendants because doing so slows down every
single SSG application by a measurable amount.

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 grant that something in ssgSimpleState is going to have to change - but
the driving force for that change is the growing trend to have multiple
texture maps per polygon without using multipass tricks.

-- 
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

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

Re: [Plib-devel] TODO list

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

"Curtis L. Olson" wrote:
> 
> Steve Baker writes:
> > AAAAArrrrrggggghhhhh!!!!
> >
> > You emailed a Microsoft Word document!!
> >
> > <Please imagine about three pages of ranting, insults, abuse, etc - nah - what
> > the heck - make that four pages>
> 
> My fingers instantly went on autopilot and had already deleted the
> message and expunged it from my inbox before my eyes had a chance to
> even parse the text of the message.  Good fingers ...

Yeah - they say you can catch nasty diseases from Word documents - Melissa or
something?  Better disinfect just to be sure.

  :-)

-- 
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

Re: [Plib-devel] Texture and blend modes

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

Sam Stickland wrote:
>
> > Well, when you add a texture into an ssgSimpleState, you can either
> > pass it an 'ssgTexture' or an OpenGL texture handle - or even a
> > filename (which will result in an ssgTexture being constructed on
> > your behalf).
> 
> Oh wait, I'll look lame for saying this but I genuinely thought that
> glTexEnv didn't get caught up in the glBindTexture bit?

Well, you certainly don't look lame for thinking that - in fact, you've
inserted a little doubt in my mind too.  I hardly every use anything
other than GL_MODULATE - so I could *easily* be wrong.

In fact, I just grep'ed every line of OpenGL code on my hard drive,
and every single glTexEnv call I can find uses GL_MODULATE!  I can
distantly remember using a TexEnv other than modulate on an SGI machine
once - but the mode we used was a non-standard one associated with
an OpenGL extension that I havn't seen on a PC yet.

The OpenGL manuals are really un-clear about what is and isn't saved.

The nearest thing I could find is where the 'RedBook' says:

  "Subsequent calls to glTexImage*, glTexSubImage*, glCopyTexImage*,
   glTexParameter* and glPrioritizeTextures store data in the texture
   object"
 
Yikes! ...no mention of glTexEnv*.  It looks like you are right after all.

But then, in the example program that follows. They set the glTexEnv
when the texture is initially created - and not after every glBindTexture
as you might expect.

That would mean that either the example program has a bug in it - or
the definition of what goes into a texture binding is wrong.

So, I think you *may* be right.

It'll probably take an experiment to be sure.

> The results from glTexEnv depend on what surface you render onto, not
> just the texture so I thought it effected the "global" rendering mode
> - - hence I believed this sort of stuff was planned for:
> 
> glBindTexture(blah);
> glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
> /* Render surface */
> glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL);
> /* Render another surface */

Maybe you are right.
 
...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.

> 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.

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.  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.

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!

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.

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.

-- 
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

Re: [Plib-devel] TODO list

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

Steve Baker writes:
> AAAAArrrrrggggghhhhh!!!!
> 
> You emailed a Microsoft Word document!!
> 
> <Please imagine about three pages of ranting, insults, abuse, etc - nah - what
> the heck - make that four pages>

My fingers instantly went on autopilot and had already deleted the
message and expunged it from my inbox before my eyes had a chance to
even parse the text of the message.  Good fingers ...

:-)

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

Re: [Plib-devel] TODO list

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

tjones wrote:

> Here is a list of things todo, Its not really organized yet and I am sure
> that there are lots of things to add, such as information in old mail. I
> will continue to work on the doc and try to clean it up, but I would like to
> get other people oppinions on the list so far, ie - who is working on what,
> and explanation changes, new features, things that have already been
> complete, and things that are not going to be completed because the are not
> in to scope of plib.
> 
> Thanks Ben Woodhead
> ps If you do not have a file attached to this please e-mail me and I will
> send it to you directly. Also this file is in UNICODE, for all the unix
> people. Wordpad will open it in windows.
 
AAAAArrrrrggggghhhhh!!!!

You emailed a Microsoft Word document!!

<Please imagine about three pages of ranting, insults, abuse, etc - nah - what
the heck - make that four pages>

-- 
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

[Plib-devel] TODO list

[tjones <tj...@is...>]

Hello everybody,

Here is a list of things todo, Its not really organized yet and I am sure
that there are lots of things to add, such as information in old mail. I
will continue to work on the doc and try to clean it up, but I would like to
get other people oppinions on the list so far, ie - who is working on what,
and explanation changes, new features, things that have already been
complete, and things that are not going to be completed because the are not
in to scope of plib.

Thanks Ben Woodhead
ps If you do not have a file attached to this please e-mail me and I will
send it to you directly. Also this file is in UNICODE, for all the unix
people. Wordpad will open it in windows.

Re: [Plib-devel] Texture and blend modes

[Sam S. <sa...@sp...>]

----- Original Message -----
From: "Steve Baker" <sjb...@ai...>
To: <pli...@li...>
Sent: Friday, August 18, 2000 6:38 PM
Subject: Re: [Plib-devel] Texture and blend modes


> Sam Stickland wrote:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- ----- Original Message -----
From: "Steve Baker" <sjb...@ai...>
To: <pli...@li...>
Sent: Friday, August 18, 2000 6:38 PM
Subject: Re: [Plib-devel] Texture and blend modes


> Sam Stickland wrote:
>
> > How are these specified in ssg?  I'll take a wild guess that ssg
> > doesn't manage texture environment modes (GL_MODULATE, GL_DECAL
> > etc.) at all, and it only cares whether blending is on or off.
>
> Well, when you add a texture into an ssgSimpleState, you can either
> pass it an 'ssgTexture' or an OpenGL texture handle - or even a
> filename (which will result in an ssgTexture being constructed on
> your behalf).

Oh wait, I'll look lame for saying this but I genuinely thought that
glTexEnv didn't get caught up in the glBindTexture bit?

The results from glTexEnv depend on what surface you render onto, not
just the texture so I thought it effected the "global" rendering mode
- - hence I believed this sort of stuff was planned for:

glBindTexture(blah);
glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
/* Render surface */
glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL);
/* Render another surface */

Oh well..

>
> 5) Edit the SSG source code to add 'setEnvMode/getEnvMode' methods
> to ssgTexture - then
>    contribute your change via CVS and earn fame, the recognition of
> your peers, etc, etc.

And Beer?

>    While you are about it - add Mag/Min filter and texture wrap
> options.
>
> People who know me well soon realise that I ALWAYS put my most
> favored option at the end of a list of choices.  :-)

Guess I'll do this one then. :)

Oh, how do you set the glBendFunc ?  (Meant to ask this in the
original email but forgot).

Thanks,

Sam

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBOZ2G59oVH1DfwTXWEQJ/aQCfR8CBuFXWfx7pYZ/J5Y3rjtdfOpsAoOV5
HpjkfLnKO/vlY+1sx3SXmioi
=U5l/
-----END PGP SIGNATURE-----

>
> > How are these specified in ssg?  I'll take a wild guess that ssg
> > doesn't manage texture environment modes (GL_MODULATE, GL_DECAL etc.)
> > at all, and it only cares whether blending is on or off.
>
> Well, when you add a texture into an ssgSimpleState, you can either
> pass it an 'ssgTexture' or an OpenGL texture handle - or even a
> filename (which will result in an ssgTexture being constructed on
> your behalf).

Oh wait, I'll look lame for saying this but I genuinely thought that glTexEnv didn't get caught up in the glBindTexture bit?

The results from glTexEnv depend on what surface you render onto, not just the texture so I thought it effected the "global"
rendering mode - hence I believed this sort of stuff was planned for:

glBindTexture(blah);
glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
/* Render surface */
glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL);
/* Render another surface */

Oh well..

>
> 5) Edit the SSG source code to add 'setEnvMode/getEnvMode' methods to ssgTexture - then
>    contribute your change via CVS and earn fame, the recognition of your peers, etc, etc.

And Beer?

>    While you are about it - add Mag/Min filter and texture wrap options.
>
> People who know me well soon realise that I ALWAYS put my most favored option
> at the end of a list of choices.  :-)

Guess I'll do this one then. :)

Oh, how do you set the glBendFunc ?  (Meant to ask this in the original email but forgot).

Thanks,

Sam

Re: [Plib-devel] Texture and blend modes

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

Sam Stickland wrote:

> How are these specified in ssg?  I'll take a wild guess that ssg
> doesn't manage texture environment modes (GL_MODULATE, GL_DECAL etc.)
> at all, and it only cares whether blending is on or off.

Well, when you add a texture into an ssgSimpleState, you can either
pass it an 'ssgTexture' or an OpenGL texture handle - or even a
filename (which will result in an ssgTexture being constructed on
your behalf).

Hence, there are really just two options - ssgTexture or do-it-yourself.

ssgTexture does indeed only specify GL_MODULATE - it's hard-wired in
the constructor function with no way to change it.
 
> So, do I set the required mode in a predraw callback function?

You have (at least) five options:

1) Derive a new class from ssgTexture (say ssgDecalTexture) that
   does GL_DECAL instead of GL_MODULATE.

2) Load the texture yourself, do the glBindTexture, set GL_DECAL
   using glTexEnvi, pass the texture handle to SSG.

3) In a pre-draw callback, set the glTexEnv to GL_DECAL.

4) Use ssgTexture to load the texture and do either a ssgSimpleState::getTextureHandle()
   or an ssgTexture::getHandle() to get the texture handle.  Then you can
   glBindTexture(handle) and change the glTexEnv setting.

5) Edit the SSG source code to add 'setEnvMode/getEnvMode' methods to ssgTexture - then
   contribute your change via CVS and earn fame, the recognition of your peers, etc, etc.
   While you are about it - add Mag/Min filter and texture wrap options.

People who know me well soon realise that I ALWAYS put my most favored option
at the end of a list of choices.  :-)

-- 
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

RE: [Plib-devel] TO-DO Update

[Ben W. <be...@bg...>]

Thanks Dave
 
I am guessing that this is a little out of date, it was updated twice and
the last one was 6 months ago. 
 
I would like to see something like what the kernel does for each release,
they keep a list of things that
were just fixed, a list of things that have been fixed, things that need to
be done, and things they would
like to have done. It makes it easier to help. If some gets plib and they
see something they would like
to implement they can join the team and start working on it.
 
Later Ben
 
ps If you would like I can put a list together, if everybody wants to send
me everything they thing should go 
into plib, after I get the list put together then we can talk about was fits
into the goal of plib, and figure out
what is important and what will just stay on the list for a while.
 
Please Send List Updates:
e-mail address: tj...@is... <mailto:tj...@is...> 
Subject: List Updates
Message
 

-----Original Message-----
From: Dave McClurg [mailto:Dav...@dy...]
Sent: Thursday, August 17, 2000 2:39 PM
To: 'pli...@li...'
Subject: RE: [Plib-devel] TO-DO Update


attached is the TOBEDONE file in plib's CVS
 
--Dave

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of tjones
Sent: Thursday, August 17, 2000 10:03 AM
To: pli...@li...
Subject: [Plib-devel] TO-DO Update


Hello
 
Is there a location for a TODO list. I would like to build a list of
features that would like to be added (and how important they are) and what
has be fix or cleaned up (and of course how important).
 
Ben Woodhead

[Plib-devel] Texture and blend modes

[Sam S. <sa...@sp...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

How are these specified in ssg?  I'll take a wild guess that ssg
doesn't manage texture environment modes (GL_MODULATE, GL_DECAL etc.)
at all, and it only cares whether blending is on or off.

So, do I set the required mode in a predraw callback function?

Sam

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBOZ0BcNoVH1DfwTXWEQJU1wCfbAm1G6GeVVQU0nvLZIR4uxOW0l4AniFA
QbeblgJYqToI4YvwNmHxEQHG
=rjd4
-----END PGP SIGNATURE-----

Re: [Plib-devel] Work outstanding.

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

Gil Carter wrote:
> 
> <snip>
> 
> >You could write a function that could monitor the frame rate and
> >automatically try replacing texturing to look for swapping but I
> >think that's about as far as you can go.
> 
> I seem to recall people on the OpenGL Gamedev list talking a while ago
> about manually adjusting the MIP map level bias so that you can force the
> hardware to use smaller versions of the textures if you're swapping too
> much.  IOW, if your maximum texture size is 1024x1024, you drop back down
> the MIP tree to use the 128x128 or 64x64 version temporarily to keep the
> framerate up while your renderer gets settled again.

OpenGL 1.2 allows you to clamp the texture map so it doesn't try to use
a MIPmap level that you havn't used.

Also, there is (IMHO) an error in the OpenGL specification for how the
hardware picks which MIPmap to use - which results in a small amount of
texture aliasing at some scales and orientations.  Several OpenGL
implementations allow you to 'bias' the chosen MIPmap level by some
small amount in order to allow you a non-standard mapping function that
will remove that last vestige of aliasing.

> I guess that this idea can also be applied to having objects in the view
> frustum which are distant but visible.  For example, if your game has a
> "god monster" as the final challenge for the user to overcome, the model
> for that monster may well be very complex and heavily textured.  If the
> user can see the monster in the distance, it would be nice to be able to
> load the lo-res versions of the model textures at first, and defer loading
> of the more detailed levels in the MIP tree until you're getting close
> enough to start using them.

That should be simple enough to do - but the amount of storage for a
level boss will never be all that large to warrant the hassle.

Where it *is* useful is in things like flight simulation where you
need to be able so render low detail terrain out 50 miles or more - but
couldn't possibly afford to keep 2,500 square miles of terrain in
memory at any one time.
 
For texture mapping though, it's not a bad idea - but pretty hard to
implement in a general manner.

-- 
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

Re: [Plib-devel] Work outstanding.

[Gil C. <g.c...@ca...>]

<snip>

>You could write a function that could monitor the frame rate and 
>automatically try replacing texturing to look for swapping but I
>think that's about as far as you can go.

I seem to recall people on the OpenGL Gamedev list talking a while ago 
about manually adjusting the MIP map level bias so that you can force the 
hardware to use smaller versions of the textures if you're swapping too 
much.  IOW, if your maximum texture size is 1024x1024, you drop back down 
the MIP tree to use the 128x128 or 64x64 version temporarily to keep the 
framerate up while your renderer gets settled again.

I guess that this idea can also be applied to having objects in the view 
frustum which are distant but visible.  For example, if your game has a 
"god monster" as the final challenge for the user to overcome, the model 
for that monster may well be very complex and heavily textured.  If the 
user can see the monster in the distance, it would be nice to be able to 
load the lo-res versions of the model textures at first, and defer loading 
of the more detailed levels in the MIP tree until you're getting close 
enough to start using them.

(Hmm... Better get the real story here... Digs back through archive of 
OpenGL messages...)

Aha, here's the basics of it, courtesy of Tom Forysth and Sean Palmer, 
posted September last year:

"I remember Jan Svarovsky from Muckyfoot talking about something like this 
at GDC99 - he called it "Just Too Late" caching :-). For older cards, where 
he had to do manual texture management, he always kept all the visible 
(according to the frustum) 16x16 mipmaps around - they don't take up too 
much memory, so they can all be loaded onto even the most modest card.  But 
he would swap around the larger texture maps at the start of every frame 
according to heristics like "how big do I need this" and things like that. 
However, sometimes the prediction heuristic fails, and you end up drawing a 
large polygon, but you haven't got the properly detailed mipmap levels loaded."

"Rather than interrupt the polygon drawing to load the texture (stalls the 
pipeline badly, especially on older cards), he just drew the poly with the 
16x16 texture (always resident), and loaded the proper high-detail mipmap 
level next frame. So for one frame, the image was blurry, but it sharpened 
up the next frame. He said it was very rare to see any big problems - you 
really had to pick pathological situations to see the artifacts. And the 
performance boost was good."

"I suspect this priority scheme would produce similar effects - sounds 
plausible and cunning. (of course, the Permedia3 doesn't need any of this 
stuff anyway - so I can probably safely adopt the role of netural IHV :-)."

Tom Forsyth, DirectX Team, 3Dlabs
email: Tom...@3D...
On Tuesday, September 28, 1999 6:13 AM, Sean L. Palmer
[SMTP:sp...@po...] wrote:
 > > You mean like I am doing right now? The only extra thing I need to
handle
 > > this stuff is more control over the mipmap stuff, such as giving some
 > > textures a lower priority -- which then should (IMHO) directly relate to
 > > what mipmaps are loaded. If a texture has a low priority, and I have
 > > extra texture memory, then the lower priority texture should have a low
 > > level mipmap loaded in.
 > >
 > > Is this a reasonable thing to ask for? I don't see why it shouldn't be.
 > > Even if we need an extra extension for mipmap priorities on top of the
 > > current texture priorities.
 >
 > How about if smaller mip levels automatically get 2x the higher mipmap's
 > priority? So to completely unload a mipmap chain, set top-level priority
to
 > 0. If you set top-level priority to 1, then for a 256x256 texture the
 > following priorities would be generated down the chain:
 >
 > priority size
 > 1 256x256
 > 2 128x128
 > 4 64x64
 > 8 32x32
 > 16 16x16
 > 32 8x8
 > 64 4x4
 > 128 2x2
 > 256 1x1
 >
 > Thus, teensy mipmaps would generally always be loaded, so no matter what,
 > you'd at least have *something* to draw with. If you were out of memory
and
 > tried to load a similar texture with top-level priority of 16, it could
then
 > free the top 4 mip levels of the priority 1 texture, giving enough room
for
 > all but the highest mip level of the new texture.
 >
<snip>

>Anyone know of any opengl texture management articles that cover scaling 
>back the textures in use automatically?

Have a look at http://vterrain.org/Textures/ground_textures.html for a 
general discussion of this topic.  In fact, the whole Vterrain site is a 
good read for topics relating to this.

Rgds,

Gil

Re: [Plib-devel] VRML Loader issues

[Gil C. <g.c...@ca...>]

> > Hence - since there are quite a few VRML-1 models around and LOTS of tools
> > support it, then we should go with that.  Who knows, we might even get
> > an OpenInventor loader out of it 'for free' and with packages like COIN
> > floating around, this could become useful.
>
>This is not what I've found.  Almost all the VRML I've found on the web
>recently has been VRML2.  And all the VRML I want to use has been VRML2.

Well, all of the visualisation work I do here at my "real" work uses VRML 
97 as the file format - it has a lot more features than VRML1, and lets you 
do some pretty powerful things with scripting and node prototyping.

Have a look at http://www.dem.csiro.au/unrestricted/3dvis/ if you're 
interested to see some of our models (you'll need a VRML browser like 
Cosmoplayer or Cortona installed on your system to view them).

Unfortunately, VRML97 is much more difficult to write a fully functional 
browser for, especially if you're trying to support the event model, 
scripting and audio - hence most geometry importers tend to not do it, and 
only support VRML1.  My plan is to not try to implement the "hard parts" of 
VRML97 for import into PLIB, but to still allow users to import any valid 
VRML97 file.  The end result will hopefully be a parser which will 
ultimately return only the geometry nodes to SSG, but will read any VRML 97 
file without barfing.

>However I've yet to find anything that'll convert a VRML2 file into
>something I can import into anything.

Can you be a little more specific?  What packages do you want to import 
VRML into and what packages are producing the original VRML?

Most of the big "name brand" 3D modelling packages will do pretty good 
VRML97 import and export - 3D Studio Max is the one we use here, and it 
reads and writes VRML97 very competently.

Rgds,

Gil

[Plib-devel] Active Widgets and Selecting Items in the Main Window

[Fay J. F C. AAC/W. <joh...@eg...>]

My PUI application has a requirement for me to click on an input box in the
user interface and then select an item in the main graphics window.  The
name of the selected item would then appear in the input box.  I used the
display list feature of OpenGL to implement this.  These are the changes to
PUI that I needed to make to support it; other parts of the code invoke the
active callback if one exists and handle the display list.  I present them
as one solution to the problem; if someone else has addressed this problem
before, I would be interested in hearing of alternative solutions.
 
<begin changes to PUI>
Here are the changes to "pu.cxx":
    - add a global variable just before the definition of "puInit".  The new
global variable is "puObject *active_widget ;".
    - inside "puInit", within the "firsttime" block, initialize
"active_widget = NULL ;".
    - at the end of the file add three functions:
                void puDeactivateWidget ()  {  active_widget = NULL ; }
                void puSetActiveWidget ( puObject *w ) {   active_widget = w
; }
                puObject *puActiveWidget () {   return active_widget ; }
I'd like to make these functions inline for execution speed, but to do that
I'd have to define them in the "pu.h" header file and so expose the
"active_widget" variable to the users.  Do other people have a preference
one way or the other?
 
Here are the changes to "pu.h":
    - add prototypes for "puDeactivateWidget", "puSetActiveWidget", and
"puActiveWidget" before the definition of "puValue"
    - add to the definition of "puObject" two new callback variables:
"puCallback active_cb" and "puCallback down_cb".  The first of these is to
be called when the widget is active and the user has clicked the mouse
somewhere besides the user interface; the second is to be called when the
widget is losing focus (becoming inactive) and the user has activated
another widget.  The down callback is not strictly necessary for using the
display list but I thought it would be a good thing to add.
    - add to the definition of "puObject" six new methods to set, return,
and activate the active and down callbacks.  These new methods are strictly
analogous to the existing methods for the current callback.
 
Except as noted below, add the following code to the beginning of each
"doHit" and "checkKey" method (after the "return FALSE" checks) in the
interface:
        if ( puActiveWidget() && ( this != puActiveWidget() ) )
        {
          puActiveWidget() -> invokeDownCallback () ;
          puDeactivateWidget () ;
        }
This code invokes the down callback if there is an active widget and the
user has selected a different widget.  The following exceptions are made:
in puGroup, do not add this code to either method; in puOneShot, do not add
this code to "doHit" since it is taken care of in "puButton::doHit".  The
code should also be added to "puButtonBox::checkHit".  (This may raise a
question about the relative roles of "checkHit" and "doHit" in the case of
the "puButtonBox" but I will not go into it here.)
 
Except as noted below, wherever the user interface calls the
"invokeCallback" method, add a line to set "puSetActiveWidget ( this ) ;".
This assigns the present widget the active widget for later mouse clicks
elsewhere.  The exception is in "puInput::checkKey", where the interface
invokes the callback when the user has pressed <Enter>.  In this case, the
interface should deactivate the widget.
 
Wherever a widget has its destructor explicitly defined, add code to check
whether the present widget is the active widget.  If it is, deactivate it.
<end changes to PUI>
 
Separate callbacks for activating and deactivating a widget may be useful in
other contexts as well.  For example, a user may wish to invoke a callback
when a "puInput" is being deactivated after the user has entered all the
keystrokes, rather than having to check for valid data with each keystroke.

John F. Fay 
joh...@eg... <mailto:joh...@eg...>