plib-users

[Plib-users] Re: "make"ing in Cygwin

[Tyler M. <TMi...@li...>]

Same problem occurs when making 1.3 as well.
Is there some other software that I'm missing perhaps?

>What version of plib are you running. If its a version from cvs please let
>me know what day you downloaded it. I have been using cygwin and I have
yet
>to run into this problem.

[Plib-users] Re: "make"ing in Cygwin

[Tyler M. <TMi...@li...>]

Hi Ben,

>What version of plib are you running. If its a version from cvs please let
>me know what day you downloaded it. I have been using cygwin and I have
yet
>to run into this problem.

I'm trying to install the PLIB 1.2.0 package.

Re: [Plib-users] Library Initialization - Conclusion

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

Elad Lahav wrote:
> 
> I have switch to Mandrake 7.1, and everything works great now. Not only
> plib, but also many other things I have tried to compile ever since I had
> installed the beta and release versions of RedHat 7.
> It is such a disappointment to learn that a major distribution (THE major
> distribution?) has made such a big mistake, and is not even admitting it.

<rant>

I'm just astounded that:

a) ...they'd ever pick up a non-released CVS and put it into a distro.
b) ...they'd do something like that for something as critically
      important as the C/C++ compiler.
c) ...that they wouldn't change their policy when the kernel team
      *and* the compiler team tell them not to do it.
d) ...that all these problems didn't come out during beta test.

They must be out of their tiny minds!

Distro's should only *ever* ship "even numbered" versions of anything. To
do otherwise does a great disservice to us poor maintainers because:

 * It makes us look bad when our software fails in the field.

 * It dramatically increases the number of emails we have to deal
   with from people for whom it failed.

Neither can be a good thing.

</rant>

> Anyway, things have worked for the best, since Mandrake looks (up to now)
> like a better distribution in other aspects as well.

I'm still a fan of SuSE - but that may change with their 7.0 release now that
they've split into 'amateur' and 'professional' versions.  I havn't had very
good dealings with Mandrake so far, I've gotten dragged into a couple of
flame wars with some of their package maintainers - and on the basis of that,
I don't have a terribly high opinion of their staff.

-- 
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-users] PUI compilation problems

[<Va...@t-...>]

Simon Foster wrote:
> 
> When attempting to compile the pui part of plib (nb:
> all the rest of plib compiles no problem) I get these
> (and other) errors:
> 
> pu.h: In method `puFont::puFont()':
> pu.h:87: `GLUT_BITMAP_8_BY_13' undeclared
> pu.cxx: In function `int puGetWindowHeight();
> pu.cxx: `GLUT_WINDOW_HEIGHT' undeclared
> .......

You are missing a define. IIRC:
#define USE_GLUT

On Linux machines this should be done automatically.


BTW: Could we *please* add this define as default? Perhaps something
like:

#ifnef USE_GLUT
#  ifndef USE_FREE_GLUT
#    define USE_GLUT
#  endif
#endif

CU,
Christian

PS: I haven't looked at the code, so I don't know if the spelling of the
defines are correct.

[Plib-users] Library Initialization - Conclusion

[Elad L. <el...@el...>]

I have switch to Mandrake 7.1, and everything works great now. Not only
plib, but also many other things I have tried to compile ever since I had
installed the beta and release versions of RedHat 7.
It is such a disappointment to learn that a major distribution (THE major
distribution?) has made such a big mistake, and is not even admitting it.
Anyway, things have worked for the best, since Mandrake looks (up to now)
like a better distribution in other aspects as well.
Thanks for all of your help.

Elad Lahav
R&D Department
Eldar Shany Technologies
972-7-6736804 ext. 227

Re: [Plib-users] wxWindows and SSG together?

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

> Ben Discoe wrote:
> 
> Has anyone on this list tried using wxWindows and PLIB/SSG together?  It seems like
> a good combination (open source GUI, open source 3D).

You'd use wxWindows *voluntarily* ?!?

I'm not aware of anyone trying this - but if you can wrestle wxWindows into doing *anything*
in the way of an OpenGL window, then SSG should work OK.

Good luck though - after my last "experiences" with wxWindows, I truly, deeply, advise you
to look at something else.  FLTK maybe?  GTK?

> It should work well since wxWindows can set up an OpenGL context, and SSG just draws
> into the current context.  However, my attempts so far to combine the small wxWindows
> OpenGL sample program with some SSG functions has not been successful - the SSG objects
> aren't appearing.

I can't imagine why not - but wxWindows is *so* strange, it may well have set up some really
wacky OpenGL modes before it draws.
 
-- 
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-users] wxWindows and SSG together?

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

Ben Discoe  writes:

  Has anyone on this list tried using wxWindows and PLIB/SSG together?  It
seems like a good combination (open source GUI, open source 3D).

  It should work well since wxWindows can set up an OpenGL context, and SSG
just draws into the current context.  However, my attempts so far to combine
the small wxWindows OpenGL sample program with some SSG functions has not
been successful - the SSG objects aren't appearing.

  Has someone used them successfully, and if so perhaps someone has a small
sample program with them working together?

  Hi Ben,

  Welcome aboard. :-)

  Using the FLTK windowing kit was fairly easy to do
  There are some minor yet show stopping gottchas however.
  i.e you have to make sure that you have a valid GLContext
  prior to any SSG calls.

  basically all you should need to do is derive a new class
  from wxGLCanvas and attach a ssgContext

  You can look at the PPE source
  http://sourceforge.net/projects/prettypoly
  To see a way to do this
  The pertinent code is in src/viewer/ppeViewer.cxx
  esp. ppeViewer::init()

  Watch out for possible confusion of
  wxGLCanvas::SetCurrent()  and
  ssgContext::makeCurrent()

  MakeCurrent() !!! MUST !!! come after SetCurrent()

  Cheers

  Norman

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

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

Ben Discoe wrote:

> > (BTW: The Quadro is a ripoff - it's an identical chip/board to the
> GeForce,
> > with the exception of a single resistor value.  If you know how to solder
> > small surface-mount parts, you can convert a GeForce card into a Quadro!)
> 
> The way i heard it, the Quadro was a ripoff because it was identical
> hardware, shipped with a different driver which enabled fast line-draw
> (because CAD people use wireframe so much).

Nearly.  In fact, the driver is identical - but either it or the nVidia
GeForce/Quadro chip reads the value of a resistor that's connected across
two pins of the chip - depending on the value, it either does LINE-SMOOTH
lines using the hardware - or in a software routine that must have been
deliberately crippled because it's AMAZINGLY slow.  One of my programs
runs at 500Hz plus with non-smoothed lines (about 1000 polygons in
wireframe mode) - and takes nearly a minute per frame (on a 750MHz PC)
with line-smoothing turned on.  When Mesa is run in software-only mode,
it does the same image at about 10Hz.  Hence either those nVidia programmers
are really bad at their job - or it's deliberately crippled.

> Anyhow, back at the time that
> card was purchased, it was also the only way to get a 64MB NVidia card.

Not any more.  There are 64Mb GeForce-2's in Fry's at $280 right now.

> I'm really tearing my hair out here over making simple coloured geometry.
> Steve, i beg of you to please help me with my previous email, the one with
> the stuff about sgSimpleState/ssgVertexColourArray.

I'm *really* busy right now - I'll try to find some time...no promises though.

You said that you could get this to happen with simple GL-level commands - shouldn't
you just take out all of the PLIB code and mail your example to one of the OpenGL
mailing lists (and possibly to the nVidia developers) ??

-- 
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-users] wxWindows and SSG together?

[Ben D. <be...@wa...>]

Has anyone on this list tried using wxWindows and PLIB/SSG together?  It =
seems like a good combination (open source GUI, open source 3D).

It should work well since wxWindows can set up an OpenGL context, and =
SSG just draws into the current context.  However, my attempts so far to =
combine the small wxWindows OpenGL sample program with some SSG =
functions has not been successful - the SSG objects aren't appearing.

Has someone used them successfully, and if so perhaps someone has a =
small sample program with them working together?

Thanks,
Ben

Re: [Plib-users] PUI compilation problems

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

Simon Foster wrote:
> 
> When attempting to compile the pui part of plib (nb:
> all the rest of plib compiles no problem) I get these
> (and other) errors:
> 
> pu.h: In method `puFont::puFont()':
> pu.h:87: `GLUT_BITMAP_8_BY_13' undeclared
> pu.cxx: In function `int puGetWindowHeight();
> pu.cxx: `GLUT_WINDOW_HEIGHT' undeclared
> .......
> 
> glut.h etc. is there but something is going wrong, has
> anyone any ideas what? I am running Mandrake.

Well, those symbols certainly come from glut.h - which should
be in /usr/include/GL/glut.h

Perhaps you have an old version of GLUT installed - or perhaps
Mandrake has installed it somewhere freaky.  (That wouldn't
suprise me)

Did the PLIB 'configure' script complain about GLUT being
missing?

-- 
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-users] Trouble making simple colored triangle

[Ben D. <be...@wa...>]

> >  glEnable(GL_COLOR_MATERIAL);
> >  glDisable(GL_COLOR_MATERIAL);
> >
> > and was able to duplicate the white-object problem, thus it's not SSG's
> > fault.
>
> I was aware of a bug like this in Mesa - which (IIRC) was recently fixed.

So far i've tried:
Quadro with 0522 drivers
Quadro with 0631 (latest) drivers
GeForce DDR with 0631 drivers

... all under Win2k, and all of them exhibit the same problem!  Could
someone please try that small 'green triangle' example in my last email,
does it work on anyone's system?

> (BTW: The Quadro is a ripoff - it's an identical chip/board to the
GeForce,
> with the exception of a single resistor value.  If you know how to solder
> small surface-mount parts, you can convert a GeForce card into a Quadro!)

The way i heard it, the Quadro was a ripoff because it was identical
hardware, shipped with a different driver which enabled fast line-draw
(because CAD people use wireframe so much).  Anyhow, back at the time that
card was purchased, it was also the only way to get a 64MB NVidia card.

I'm really tearing my hair out here over making simple coloured geometry.
Steve, i beg of you to please help me with my previous email, the one with
the stuff about sgSimpleState/ssgVertexColourArray.

Desperate thanks in advance,
Ben

[Plib-users] PUI compilation problems

[<fa...@ya...>]

When attempting to compile the pui part of plib (nb:
all the rest of plib compiles no problem) I get these
(and other) errors:

pu.h: In method `puFont::puFont()':
pu.h:87: `GLUT_BITMAP_8_BY_13' undeclared
pu.cxx: In function `int puGetWindowHeight();
pu.cxx: `GLUT_WINDOW_HEIGHT' undeclared
.......

glut.h etc. is there but something is going wrong, has
anyone any ideas what? I am running Mandrake.

Regards,

SiMON

__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/

Re: [Plib-users] "make"ing in Cygwin

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

Hello

What version of plib are you running. If its a version from cvs please let
me know what day you downloaded it. I have been using cygwin and I have yet
to run into this problem.

Thanks Ben


----- Original Message -----
From: Tyler Mitchell <TMi...@li...>
To: <pli...@li...>
Sent: Friday, October 13, 2000 1:50 PM
Subject: [Plib-users] "make"ing in Cygwin


> Just installed the whole shabang of Cygwin and now have run MAKE on the
> PLIB installation.
> Everything seems okay until part way through compiling slMOFfile.  Below
is
> a snippit of where the errors started and how the make process ended.  Can
> anyone direct to me to rectify the problem?
>
> Tyler
> .....
> /lib -c slMODfile.cxx
> slMODfile.cxx:9: parse error before `unsigned'
> slMODfile.cxx: In method `void MODfile::modToS3m(unsigned char (*)[4],
Note
> *)':
>
> slMODfile.cxx:325: `transTab' undeclared (first use this function)
> slMODfile.cxx:325: (Each undeclared identifier is reported only once
> slMODfile.cxx:325: for each function it appears in.)
> slMODfile.cxx: In method `void MODfile::makeSampleInfo(int)':
> slMODfile.cxx:438: stray '\' in program
> slMODfile.cxx:438: invalid type argument of `unary *'
> slMODfile.cxx:438: parse error before `;'
> slMODfile.cxx:439: parse error before `)'
> slMODfile.cxx:439: stray '\' in program
> slMODfile.cxx:441: `lLen' undeclared (first use this function)
> slMODfile.cxx:444: stray '\' in program
> slMODfile.cxx:444: invalid type argument of `unary *'
> slMODfile.cxx:444: parse error before `;'
> slMODfile.cxx:456: parse error before `]'
> slMODfile.cxx:476: stray '\' in program
> slMODfile.cxx:476: invalid type argument of `unary *'
> slMODfile.cxx:476: parse error before `;'
> slMODfile.cxx:486: `pp0' undeclared (first use this function)
> slMODfile.cxx:500: `n' undeclared (first use this function)
> slMODfile.cxx:512: declaration of `int MODfile::update()' outside of class
> is no
> t definition
> slMODfile.cxx:512: parse error before `{'
> slMODfile.cxx:544: `return' with a value, in function returning void
> slMODfile.cxx:549: `return' with a value, in function returning void
> slMODfile.cxx:438: warning: unused variable `unsigned int len'
> slMODfile.cxx:555: declaration of `unsigned char *
> MODfile::read_whole_file(char
>  *, int *)' outside of class is not definition
> slMODfile.cxx:555: parse error before `{'
> slMODfile.cxx:560: `fname' undeclared (first use this function)
> slMODfile.cxx:566: `return' with a value, in function returning void
> slMODfile.cxx:569: `statbuf' undeclared (first use this function)
> slMODfile.cxx:572: `return' with a value, in function returning void
> slMODfile.cxx:577: conflicting types for `unsigned char * p'
> slMODfile.cxx:425: previous declaration as `struct SampleInfo * p'
> slMODfile.cxx:581: `len' undeclared (first use this function)
> slMODfile.cxx:584: `return' with a value, in function returning void
> slMODfile.cxx:484: warning: `unsigned char * p' might be used
uninitialized
> in t
> his function
> slMODfile.cxx: At top level:
> slMODfile.cxx:652: confused by earlier errors, bailing out
> make[2]: *** [slMODfile.o] Error 1
> make[2]: Leaving directory `/plib/src/sl'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/plib/src'
> make: *** [all-recursive] Error 1
> .....
>
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users
>
>

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

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

Ben Discoe wrote:

>  glEnable(GL_COLOR_MATERIAL);
>  glDisable(GL_COLOR_MATERIAL);
> 
> and was able to duplicate the white-object problem, thus it's not SSG's
> fault.

I was aware of a bug like this in Mesa - which (IIRC) was recently fixed.
 
> The question remains why merely enabling and disabling this state messes up
> rendering.  Perhaps it's a driver bug, but the Quadro is a pretty common
> card.  Anyone have an idea?

(The Quadro?  That's just the 'professional' version of the GeForce - right?)

Are you using Linux or Windoze?   If Linux, are you using the nVidia drivers
or the Utah-GLX drivers?   I'm not having any problems of this kind with the 
GeForce - and in fact the way we found the original Mesa bug was when I got
my GeForce cards and all the peculiar lighting problems 'went away'.

(BTW: The Quadro is a ripoff - it's an identical chip/board to the GeForce,
with the exception of a single resistor value.  If you know how to solder
small surface-mount parts, you can convert a GeForce card into a Quadro!)

-- 
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-users] Trouble making simple colored triangle

[Ben D. <be...@wa...>]

I spent more time trying to debug the problem, and have more information.
The reason that SSG seemed to be causing trouble is that inside ssgInit, it
enables GL_COLOR_MATERIAL.

What i discovered is that even if i disable GL_COLOR_MATERIAL afterwards,
geometry is still rendered incorrectly!  Instead of calling SSG, i tried
simply calling:

 glEnable(GL_COLOR_MATERIAL);
 glDisable(GL_COLOR_MATERIAL);

and was able to duplicate the white-object problem, thus it's not SSG's
fault.

The question remains why merely enabling and disabling this state messes up
rendering.  Perhaps it's a driver bug, but the Quadro is a pretty common
card.  Anyone have an idea?

Thanks,
Ben

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

[Ben D. <be...@wa...>]

Hi Steve, thanks for the quick response!

> >   if ( num_colours == 0 ) glColor4f   ( 1.0f, 1.0f, 1.0f, 1.0f ) ;
> > 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.

I don't understand.  The num_colors field comes from this:
  int num_colours   = getNumColours   () ;

which is the number of colors in the vertex color table.  I would presume in
general that more than one primitive will share the same vertex table, so
color information will come from the state, not the per-vertex colors.  Or
are you saying that it is customary to make a ssgColourArray with a single
element in it, for each differently-colored primitive??

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

OK, i can set the state's state explicitly - but which is correct?  Is
disabling GL_COLOR_MATERIAL required to get any ssgSimpleState-colored
objects?

> 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've tried that, and the triangle is still white, not green.

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

I've tried that, and the triangle is still white, not green.

> What OpenGL implementation do you have - and what PLIB are you using?

I'm using a NVidia Quadro under Win2k, presumably OGL1.2.
I've been using PLIB 1.2.0, but i looked at the latest 1.3.1 as well, and it
didn't appear to have changed in the core functionality i'm using.

> Yes - 99% of people put the colour in the leaf node and enable
> GL_COLOR_MATERIAL.

Does this mean i can't use ssgSimpleState?  Using vertex colors ("in the
leaf node") means that the ssgSimpleState values are ignored, since they are
ignored by OpenGL when *not* using GL_COLOR_MATERIAL.

Wouldn't that also mean that i can't set additional properties like
Emission?  You can't specify that with a ssgColourArray, so do 99% of people
not care about any state besides diffuse?

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

I've attached a small example, which is basically the "tux" example with tux
replaced by a "green" triangle, which appears white.

Thanks!
Ben

[Plib-users] "make"ing in Cygwin

[Tyler M. <TMi...@li...>]

Just installed the whole shabang of Cygwin and now have run MAKE on the
PLIB installation.
Everything seems okay until part way through compiling slMOFfile.  Below is
a snippit of where the errors started and how the make process ended.  Can
anyone direct to me to rectify the problem?

Tyler
.....
/lib -c slMODfile.cxx
slMODfile.cxx:9: parse error before `unsigned'
slMODfile.cxx: In method `void MODfile::modToS3m(unsigned char (*)[4], Note
*)':

slMODfile.cxx:325: `transTab' undeclared (first use this function)
slMODfile.cxx:325: (Each undeclared identifier is reported only once
slMODfile.cxx:325: for each function it appears in.)
slMODfile.cxx: In method `void MODfile::makeSampleInfo(int)':
slMODfile.cxx:438: stray '\' in program
slMODfile.cxx:438: invalid type argument of `unary *'
slMODfile.cxx:438: parse error before `;'
slMODfile.cxx:439: parse error before `)'
slMODfile.cxx:439: stray '\' in program
slMODfile.cxx:441: `lLen' undeclared (first use this function)
slMODfile.cxx:444: stray '\' in program
slMODfile.cxx:444: invalid type argument of `unary *'
slMODfile.cxx:444: parse error before `;'
slMODfile.cxx:456: parse error before `]'
slMODfile.cxx:476: stray '\' in program
slMODfile.cxx:476: invalid type argument of `unary *'
slMODfile.cxx:476: parse error before `;'
slMODfile.cxx:486: `pp0' undeclared (first use this function)
slMODfile.cxx:500: `n' undeclared (first use this function)
slMODfile.cxx:512: declaration of `int MODfile::update()' outside of class
is no
t definition
slMODfile.cxx:512: parse error before `{'
slMODfile.cxx:544: `return' with a value, in function returning void
slMODfile.cxx:549: `return' with a value, in function returning void
slMODfile.cxx:438: warning: unused variable `unsigned int len'
slMODfile.cxx:555: declaration of `unsigned char *
MODfile::read_whole_file(char
 *, int *)' outside of class is not definition
slMODfile.cxx:555: parse error before `{'
slMODfile.cxx:560: `fname' undeclared (first use this function)
slMODfile.cxx:566: `return' with a value, in function returning void
slMODfile.cxx:569: `statbuf' undeclared (first use this function)
slMODfile.cxx:572: `return' with a value, in function returning void
slMODfile.cxx:577: conflicting types for `unsigned char * p'
slMODfile.cxx:425: previous declaration as `struct SampleInfo * p'
slMODfile.cxx:581: `len' undeclared (first use this function)
slMODfile.cxx:584: `return' with a value, in function returning void
slMODfile.cxx:484: warning: `unsigned char * p' might be used uninitialized
in t
his function
slMODfile.cxx: At top level:
slMODfile.cxx:652: confused by earlier errors, bailing out
make[2]: *** [slMODfile.o] Error 1
make[2]: Leaving directory `/plib/src/sl'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/plib/src'
make: *** [all-recursive] Error 1
.....

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

[Plib-users] Trouble making simple colored triangle

[Ben D. <be...@wa...>]

I'm in the process of porting my whole 3d project over to PLIB/SSG, and
mostly it's great, but i'm having a lot of trouble trying to build some
simple geometry with SSG.

As an example, consider a plain green triangle.  You might think that the
following code would work:

 sgVec4 color;
 sgVec3 pos;
 ssgSimpleState *state = new ssgSimpleState();
 sgSetVec4(color, 0.0f, 1.0f, 0.0f, 1.0f);
 state->setMaterial(GL_DIFFUSE, color);

 ssgVertexArray   *vertices = new ssgVertexArray(3);
 ssgNormalArray   *normals = new ssgNormalArray(3);

 ssgVtxTable *pVtx = new ssgVtxTable(GL_TRIANGLES, vertices,
  normals, NULL, NULL);

 for (int i = 0; i < 3; i++)
 {
  double a = i * PI2f / 3.0f;
  sgSetVec3(pos, cos(a), sin(a), 0);
  vertices->add(pos);
  sgSetVec3(pos, 0, 0, 1);
  normals->add(pos);
 }
 pVtx->setState(state);

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


This forces all primitives to white if they don't have a color per vertex!
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.

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.

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

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!

So, i tried to work around this by changing the order in ssgSimpleState.cxx.

That worked, so i finally got a green triangle.

Surely there is some way to do simple colored geometry without all the
hacking i had to do?  Please help, i would really love to be able to use
SSG.

Thanks,
Ben Discoe
http://vterrain.org/

Re: [Plib-users] Library Initialization

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

> > I think it's only on RedHat 7.0 as a getout for Alan Cox's decision to
the
> > development release of gcc.
>
> So they were WELL AWARE of what they were doing - and the kernel guys
complained
> and they STILL WENT AHEAD!  Yikes!  This is much worse than I thought.

Well we're getting wildly offtopic but here's Alan Cox's statement on the
gcc inclusion:

----
From there, the argument ensued at full strength, with Linux kernel
developer and Red Hat employee Alan Cox taking up the cause of Red Hat's
decision to release Red Hat 7 with these packages. Cox's primary argument
was that the inclusion of application like GCC 2.96 is innovative progress
for users of Red Hat 7.

"I want people to be prepared to ship new and innovative things," Cox wrote
in the discussion, "If everyone complains about not shipping precise
reference kernels, then all of a sudden for [kernel] 2.2 I become some
anointed high power for approval for vendors--that is something I don't wish
to be and which would be very, very bad for Linux. Do you really want a
world where you cannot buy a distribution with 2.2 that has Reiserfs because
Alan Cox refused to merge it with the mainstream?"
----

And later on

----
Cox's comments were echoed by Eric Troan, Red Hat's VP of Product
Engineering in an online interview with Linux Today.

"The questions which have arrived over the compiler is actually about the
user-space compiler we ship, not the kernel compiler. The kernel compiler is
essentially the same version we shipped in the last couple of Red Hat
releases," Troan explained. "The user space is based on a snapshot version
of gcc, which we have tested extensively inside of Red Hat. While no
compiler is perfect, we've built tens of millions of lines of code and it
works very well for us."
----

But most worrying is this statement:

----
Troan went on to outline Red Hat's position towards the accusations that Red
Hat is attempting to depart from the Linux standard.

"As for the compatibility issues, we do think binary compatibility between
Linux distributions is very important. We do not ship kernels with extra
APIs unless Linus Torvalds has accepted those new APIs into the development
kernel trees. Likewise, we work hard to maintain full backwards
compatibility," Troan said.

"As the Linux Standard Base (LSB) group gets finalized, Red Hat will be
fully compliant with it's recommendations, ensuring that LSB compatible
applications will run on the widest varieties of Linux-compatible systems
possible," Troan continued, "Fragmenting the Linux binary APIs will not help
anyone.

"Moving Linux forward is important, however. Doing that requires changes
that can make it difficult to move applications from newer systems to older
ones. This is inevitable, and every platform vendor has this type of problem
(applications built for Windows 2000 apps do not work on Windows 98, for
example, and Solaris applications do not run on SunOS). The LSB will provide
a common denominator to allow application compatibility between releases
while still providing a path for new features to be added to Linux
distribution," Troan explained.
----

(He's wrong btw, apps compiled under Windows 2000 run just fine on 98
providing you don't make use of any API's that don't exist on 98).

Sam

> > > > alias gcc kgcc
> > > >
> > > > might do the trick
> > >
> > > ...and g++ ==> kg++ ?
> > >
> > > I don't think an 'alias' will work BTW, the Makefile system probably
uses
> > > bash or something.
> >
> > Yeah, I was thinking it might do that but I don't have to much
experience
> > with the way Unix shells handle their environments.  I supposed you
could
> > add the aliases to.bashrc but to...
>
> The way things are set up is to try to avoid user's own aliases creeping
> into scripts and Makefiles and such.  People like to do thing like:
>
> alias ls ls -al
> alias rm rm -i
> alias test /home/steve/binaries/my_test_program
>
> ...which can play **HAVOC** with system scripts, configure scripts and
> Makefiles!!
>
> The system doesn't prevent you from doing things like that (because
> UNIX likes to give you all the power it can) - but it is mildly
> resistant to non-knowledgeable users tinkering.
>
> > > rename the original gcc/g++ to something else and
> > > symlink to them to kgcc or whatever.
> >
> > ...is probably a better solution.
>
> Yes.
>
> --
> 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-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users
>

Re: [Plib-users] Library Initialization

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

Sam Stickland wrote:

> > > > You might want to downgrade your gcc to something that works.  RedHat
> > > > are coming in for a lot of flak over their decision to ship a
> relatively
> > > > poorly tested beta version.
> > >
> > > No need.  Type recompiling everything with kgcc instead of gcc. kgcc is
> the
> > > Linus blessed version for compiling kernals.
> >
> > I havn't heard of that.  It's not installed on SuSE Linux.
> 
> I think it's only on RedHat 7.0 as a getout for Alan Cox's decision to  the
> development release of gcc.

So they were WELL AWARE of what they were doing - and the kernel guys complained
and they STILL WENT AHEAD!  Yikes!  This is much worse than I thought.
 
> > > alias gcc kgcc
> > >
> > > might do the trick
> >
> > ...and g++ ==> kg++ ?
> >
> > I don't think an 'alias' will work BTW, the Makefile system probably uses
> > bash or something.
> 
> Yeah, I was thinking it might do that but I don't have to much experience
> with the way Unix shells handle their environments.  I supposed you could
> add the aliases to.bashrc but to...

The way things are set up is to try to avoid user's own aliases creeping
into scripts and Makefiles and such.  People like to do thing like:

alias ls ls -al
alias rm rm -i
alias test /home/steve/binaries/my_test_program

...which can play **HAVOC** with system scripts, configure scripts and
Makefiles!!

The system doesn't prevent you from doing things like that (because
UNIX likes to give you all the power it can) - but it is mildly
resistant to non-knowledgeable users tinkering.
 
> > rename the original gcc/g++ to something else and
> > symlink to them to kgcc or whatever.
> 
> ...is probably a better solution.

Yes.

-- 
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-users] Library Initialization

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

----- Original Message -----
From: "Steve Baker" <sjb...@ai...>
To: <pli...@li...>
Sent: Wednesday, October 11, 2000 12:04 PM
Subject: Re: [Plib-users] Library Initialization


> Sam Stickland wrote:
>
> > > You might want to downgrade your gcc to something that works.  RedHat
> > > are coming in for a lot of flak over their decision to ship a
relatively
> > > poorly tested beta version.
> >
> > No need.  Type recompiling everything with kgcc instead of gcc. kgcc is
the
> > Linus blessed version for compiling kernals.
>
> I havn't heard of that.  It's not installed on SuSE Linux.

I think it's only on RedHat 7.0 as a getout for Alan Cox's decision to  the
development release of gcc.

> > alias gcc kgcc
> >
> > might do the trick
>
> ...and g++ ==> kg++ ?
>
> I don't think an 'alias' will work BTW, the Makefile system probably uses
> bash or something.

Yeah, I was thinking it might do that but I don't have to much experience
with the way Unix shells handle their environments.  I supposed you could
add the aliases to.bashrc but to...

> rename the original gcc/g++ to something else and
> symlink to them to kgcc or whatever.

...is probably a better solution.

Sam

RE: [Plib-users] Compiling for windows

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

Steve Baker writes:
>
>Norman Vine wrote:
>
>> Also FWIW there is some 'ugly' code in the FlightGear
>> Source cockpit / hud.hxx
>> that I used to speed up PLib text when I 'KNEW'
>> that I was rendering a lot of text with no intervening
>> glstate changes.
>> 
>> class fgText
>> class fgTextList
>> 
>> This code could probably be cleaned up a little bit
>> but it served its purpose for me as is :-)
>
>I don't know that code - but I thought about this very
>carefully when I wrote the FNT library.
>
>You *should* be able to avoid state costs when rendering
>text by using the begin()/end() member functions to
>bracket your rendering.  Did you need something beyond
>that?  I'd be suprised.

I worded that wrong  

I should have said 

There are a couple of utility classes in FlightGear
that demonstrate a method of collecting all of your
Text and Line primitives into 'displaylist' like structures
for 'all at once' rendering.

I found these useful so that I did not kill the frame rate 
with unnecessary state changes when drawing things 
like multiple HUD instruments that intersperse textured 
text and other graphic primitives

Norman

Re: [Plib-users] Compiling for windows

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

Norman Vine wrote:

> Also FWIW there is some 'ugly' code in the FlightGear
> Source cockpit / hud.hxx
> that I used to speed up PLib text when I 'KNEW'
> that I was rendering a lot of text with no intervening
> glstate changes.
> 
> class fgText
> class fgTextList
> 
> This code could probably be cleaned up a little bit
> but it served its purpose for me as is :-)

I don't know that code - but I thought about this very
carefully when I wrote the FNT library.

You *should* be able to avoid state costs when rendering
text by using the begin()/end() member functions to
bracket your rendering.  Did you need something beyond
that?  I'd be suprised.

-- 
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-users] Compiling for windows

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

Don Lafontaine wrote:

> I'm thinking of replacing "glf" fonts with plib fonts.  I hope to get a
> little more speed out of my project.  It uses text pretty heavily compared
> to the average OpenGL program.

Well, if you are not currently using texturemapped fonts and assuming you
have a hardware-accellerated OpenGL implementation then you'll get a huge
speedup from using PLIB's "FNT" library.  Textured fonts can be tricky
though - they tend to get hard to read when scaled down and can look
terrible when scaled up.

If you don't have hardware accellerated OpenGL then FNT will probably
slow things down rather than speed them up.

If you are already using textured fonts then I won't make any promises!

I have a FAQ about font rendering that you may find
instructive:

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

...it has links to several other OpenGL font libraries (but use PLIB
anyway! :-)

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