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