Re: [Plib-users] Trouble making simple colored triangle

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

Ben Discoe wrote:

> But, this makes a triangle which is white, not green.  Stepping into the SSG
> code, i discovered that in the function ssgVtxTable::draw_geometry(), there
> is the line:
>   if ( num_colours == 0 ) glColor4f   ( 1.0f, 1.0f, 1.0f, 1.0f ) ;

That's a very carefully considered decision - don't mess with it!

OK - there is a common misconception about ssgState's:

  **** THERE IS NO "DEFAULT" VALUE FOR ANY FIELD OF AN SSGSTATE ****
 
The 'default' is that if you don't set some attribute of the state, SSG
won't set it - and you'll get whatever garbage happens to be set up in
OpenGL at the time.  You *MUST* set precisely those state elements that
you need and pay attention to NOT setting the ones you truly don't
care about.

This has THREE very important benefits:

  1) Speed.  Since there are many aspects to OpenGL state, if I had to
     set them all up before drawing every Leaf node, we would be there all
     night doing pre-triangle setup.  Hence, you only set what you care about
     and I don't waste time setting up parameters you care nothing about.

  2) Some applications want to set a particular state globally.  By leaving
     that state out of all of your primitives, you can set that state
     yourself in the application and SSG won't mess with it.

  3) Future enhancements.  If there is some aspect of OpenGL state that
     SSG doesn't manage (there are quite a few) - and so the application
     sets it up, then if ssgState had a default for everthing, we would
     not be able to extend the coverage of ssgState in the future without
     breaking existing programs.  With the default being "don't change
     anything", we could (hypothetically) decide to implement (say) bump
     mapping in ssgState without destroying programs that already set that
     up outside of SSG.

Of these, speed is by far the most important.

> This forces all primitives to white if they don't have a color per vertex!

No - it sets them to white if you didn't give the LEAF node a colour.  That's
a very rare circumstance in practice. (Notice the comments earlier about there
not being defaults applied to *STATE* structures not *LEAF* structures.)

> I worked around this problem by making and using a subclass of ssgVtxTable
> with a draw_geometry that doesn't make this assumption.  The triangle was
> still white, so i found the next problem.

Nah - that was wrong.
 
> In ssgSimpleState::apply(), it uses glMaterialfv to set the diffuse color.
> However, GL is in "Color Material" mode by default, so the glMaterialfv
> calls have no effect, making the shape default white.

It's unwise to rely on OpenGL's default state.  Many implementations get
that wrong.

No - it's simply that you didn't enable or disable GL_COLOR_MATERIAL explicitly
and you didn't set the glColorMaterial setting to (say) GL_AMBIENT_AND_DIFFUSE
in the ssgStates that needed that.

> I tried to solve this problem by adding a statement to the triangle code:
>     state->disable(GL_COLOR_MATERIAL);

OK - that's going to mean that the polygon colour is entirely determined by
the glMaterial - but *ONLY* if GL_LIGHTING is enabled.

> But, another problem (bug?) in ssgSimpleState::apply() prevents this from
> working.  The Enable/Disable state code, required to disable "Color
> Material", is called *after* the glMaterialfv code, but OGL requires the
> glMaterialfv call to come after!

That's *REALLY* unclear in the OpenGL spec. Many of the experts (including
two members of the ARB) have disagreed on this point.

Mesa *used* to behave as you have described it - but the latest versions
do not.  It's a mess!
 
> So, i tried to work around this by changing the order in ssgSimpleState.cxx.
> 
> That worked, so i finally got a green triangle.

What OpenGL implementation do you have - and what PLIB are you using?
 
> Surely there is some way to do simple colored geometry without all the
> hacking i had to do?

Yes - 99% of people put the colour in the leaf node and enable GL_COLOR_MATERIAL.
This is presumed to be faster than changing the colour with glMaterial (the
OpenGL RedBook says that somewhere) - and you can change the colour with
vertex arrays, etc.

It's *possible* that you have found a bug in the state apply code - but I'm not
convinced that it isn't an error in your OpenGL - or something else screwed up.

Can you mail me a short example program so that I can investigate more carefully?

>  Please help, i would really love to be able to use SSG.
 
Sure - I'm always anxious to help people with interesting applications.

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