plib-users

[Plib-users] works with Mesa 3.3?

[Steve W. <st...@sh...>]

Has anyone tried using plib 1.2 with the 3Dfx Mesa 3.2.1 or 3.3?  First I tried 3.3, 
which seemed to have some problems of its own (like #including glext.h, and not 
copying it when you do a make install), as well as causing pui to really screw up 
when using glide on my Voodoo2.

I switched to 3.2.1 (which had no internal problems that I could see), and it has the 
same problem:  the top of the screen is either severely distorted or blank, both in 
windowed and fullscreen modes.  Software mode (MESA_GLX_FX=d) works fine.  
The problem occurs in both tux:aqfh and tuxkart, so it's not my code.  :)

I haven't tested other OpenGL apps yet (I should), but is this more likely to be a 
Mesa or plib problem?  Did something get fixed in Mesa that plib was "working 
around," or did something in Mesa break (which seems less likely, since they put 
some 3Dfx specific fixes in this one)?



-----------
"Good people do not need laws to tell them to act responsibly,
while bad people will find a way around the laws."
     - Plato (427-347 B.C.)

Re: [Plib-users] Cannot compile examples

[Stephen J B. <sj...@li...>]

Risto S Varanka said:

> I was trying to compile the example programs for PLIB-1.1.8 or
> later.  All other examples compile fine, but in the sg examples I
> run into errors.  I am using recently updated Debian Potato, Mesa
> 3.1, GLUT 3.7 and plib 1.2. 

Yes - I'm sorry about that - we are in the process of rewriting
and reorganizing the examples package (you can see it's about
10 revisions behind PLIB itself) - so these problems are not
entirely unexpected!

You should find that if you 'cd' down into the examples/<libraryname>
directory and do a 'make' there, that more of the examples programs
will build - but some of them (notably that Quaternion test program)
won't build no matter what.

Actually, the Quaternion test was never meant to be in the
distribution at all - it was just something I was testing
with and didn't intend to ship out.

The version of the examples suite that's in the current CVS
version of PLIB *does* compile against the version of PLIB that's
in CVS - but that's in the unstable development branch and you
might not want to go there.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

[Plib-users] Cannot compile examples

[Risto S V. <rva...@cc...>]

I was trying to compile the example programs for PLIB-1.1.8 or
later.  All other examples compile fine, but in the sg examples I
run into errors.  I am using recently updated Debian Potato, Mesa
3.1, GLUT 3.7 and plib 1.2. 

Here's the error:

fun13:/usr/src/plib-1.2.0/examples/plib_examples-1.1.8$ make
Making all in examples
make[1]: Entering directory `/usr/src/plib-1.2.0/examples/plib_examples-1.1.8/examples'
Making all in js
/* Everything went well for the first few directories, so not pasting them here */
Making all in sg
make[2]: Entering directory `/usr/src/plib-1.2.0/examples/plib_examples-1.1.8/examples/sg'
c++ -DPACKAGE=\"plib_examples\" -DVERSION=\"1.1.8\" -DHAVE_LIBGL=1 -DHAVE_LIBGLU=1 -DHAVE_LIBGLUT=1 -DSTDC_HEADERS=1
-DHAVE_GL_GL_H=1 -DHAVE_GL_GLUT_H=1 -DHAVE_PLIB_SG_H=1 -DHAVE_PLIB_SL_H=1 -DHAVE_PLIB_SSG_H=1 -DHAVE_PLIB_FNT_H=1
-DHAVE_PLIB_PU_H=1 -DHAVE_PLIB_JS_H=1 -DLINUX_JOYSTICK_IS_PRESENT=1  -I. -I.      -O6 -Wall -c sg_quat_test.cxx
sg_quat_test.cxx: In function `int main(int, char **)':
sg_quat_test.cxx:49: implicit declaration of function `int sgMakeQuat(...)'
sg_quat_test.cxx:50: no matching function for call to `sgMakeRotMat4 (float[4][4], float (*)[4])'
/usr/include/plib/sg.h:131: candidates are: void sgMakeRotMat4(float (*)[4], float, const float *)
/usr/include/plib/sg.h:134:                 void sgMakeRotMat4(float (*)[4], const float *)
/usr/include/plib/sg.h:139:                 void sgMakeRotMat4(float (*)[4], float, float, float)
make[2]: *** [sg_quat_test.o] Error 1
make[2]: Leaving directory `/usr/src/plib-1.2.0/examples/plib_examples-1.1.8/examples/sg'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/plib-1.2.0/examples/plib_examples-1.1.8/examples'
make: *** [all-recursive] Error 1

-- 
Risto Varanka | http://www.helsinki.fi/~rvaranka/		
ris...@he...

[Plib-users] Prepare for PLIB 1.3/1.4

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

IMPORTANT NOTICE:
~~~~~~~~~~~~~~~~~

From PLIB 1.3.1 onwards, there will be a new library 'libplibul.a' with some common
utility functions that other PLIB libraries may need.

If you use 'autoconf/automake' to build your application, you can easily cope
with this change by adding:

    AC_CHECK_LIB(plibul, ulInit,,,)

...with that in your 'configure.in', you should be able to build against either
PLIB 1.3.0 and earlier or PLIB 1.3.1 and later.

If you intend to actually call any UL functions in your application, then you'll
need to call ulInit() before you do so - and #include <plib/ul.h>

If you don't intend to call UL functions, you still need to link to UL - but you
don't have to call ulInit.

-- 
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] Can't compile examples

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

Peter A Barros wrote:
> 
> I recently downloaded plib-1.2.0 and set it up fine, now I am trying to do
> the same for the "plib_examples-1.1.8" but when i do a make on it i get:


> sg_quat_test.cxx:49: implicit declaration of function `int
> sgMakeQuat(...)'

Ooops!

That test program wasn't supposed to end up in the distribution.
It's junk.

> any idea how to fix this problem?

Change sg_quat_test.cxx to read:

  int main ()
  {
    return 0 ;
  }

:-)

(If you just delete it, you'll have to change the Makefile.am, re-run autoconf/automake,
etc, etc)

Those examples and documents are in *severe* need of updating...So many jobs - so
little time.  :-(

Sorry!

-- 
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] Can't compile examples

[Peter A B. <p.a...@la...>]

I recently downloaded plib-1.2.0 and set it up fine, now I am trying to do
the same for the "plib_examples-1.1.8" but when i do a make on it i get:

Making all in sg
make[2]: Entering directory `/devices/plib_examples-1.1.8/examples/sg'
c++ -DPACKAGE=\"plib_examples\" -DVERSION=\"1.1.8\" -DHAVE_LIBGL=1
-DHAVE_LIBGLU=1 -DHAVE_LIBGLUT=1 -DSTDC_HEADERS=1 -DHAVE_GL_GL_H=1
-DHAVE_GL_GLUT_H=1 -DHAVE_PLIB_SG_H=1 -DHAVE_PLIB_SL_H=1
-DHAVE_PLIB_SSG_H=1 -DHAVE_PLIB_FNT_H=1 -DHAVE_PLIB_PU_H=1
-DHAVE_PLIB_JS_H=1 -DLINUX_JOYSTICK_IS_PRESENT=1  -I. -I.      -g -O2 -O6
-Wall -c sg_quat_test.cxx
sg_quat_test.cxx: In function `int main(int, char **)':
sg_quat_test.cxx:49: implicit declaration of function `int
sgMakeQuat(...)'
sg_quat_test.cxx:50: no matching function for call to `sgMakeRotMat4
(float[4][4], float (*)[4])'
/usr/include/plib/sg.h:131: candidates are: void sgMakeRotMat4(float
(*)[4], float, const float *)
/usr/include/plib/sg.h:134:                 void sgMakeRotMat4(float
(*)[4], const float *)
/usr/include/plib/sg.h:139:                 void sgMakeRotMat4(float
(*)[4], float, float, float)
make[2]: *** [sg_quat_test.o] Error 1
make[2]: Leaving directory `/devices/plib_examples-1.1.8/examples/sg'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/devices/plib_examples-1.1.8/examples'
make: *** [all-recursive] Error 1

here's my info
Redhat 6.2
kernel is 2.2.14
i686 Pentium II w/ 400 MHz
gcc 2.95.2


any idea how to fix this problem?

Thanks!

[Plib-users] ANNOUNCING PLIB 1.2.0 and 1.3.0.

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

ANNOUNCING PLIB 1.2.0 and 1.3.0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is one of those rare occasions when there is nothing significantly
new in the release - but we are incrementing the version number to indicate
stability.

Both PLIB 1.2.0 and 1.3.0 are essentially identical to 1.1.12.

From today onwards:

  1.0.xx is officially obsolete - please don't use it, rely on it
         or distribute it.  If you find an application that needs
         it, please ask the author to upgrade.

  1.1.xx is also officially obsolete - same deal.

  1.2.0  is the new 'stable' release, it's feature set is frozen and
         there won't be a 1.2.1 unless we have to fix a critical bug.
         This is the "known good" version that Linux distro's should
         ship, application developers should build against and users
         should download.

  1.3.0  is the first of the new 'experimental' versions - that's where all
         the cutting edge new development will be done, new features will
         be added - new bugs also.  Ultimately there will be a 1.4.0 which
         will once again be stable.

Thanks to the many people who helped to push 1.2.0 screaming and
kicking into the world.  There is no great glamor in working on PLIB
- but several quality projects would not be where they are without your
help.

-- 
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] New Linux game using plib

[Blake F. <umf...@cc...>]

Hi, I've been working on a strategy game for linux using OpenGL and plib.
Screenshots and sourcecode/cvs access can be found at
http://foundation.sourceforge.net

Blake

R: [Plib-users] Linux-based game console

[Paolo L. <p.l...@ci...>]

The approach to rely on true opensource standards shouldn't miss to actract
developers (always the same stories...) - not to mention that an always
larger game developer community is unhappy with Direct3D and likes OpenGL.

Plib is thus candidate to take an honorable place in this promising
scenario, to my opinion mostly for simulation, whereas other more or less
open engines are instead suited to portals/room-based scenes. And would
neither needs to change the license from LGPL!

What about "Tux-the-Kart" to be one of the first games of this new
generation?!

Wishes -
----------------------------------------------------------------------------
-
Paolo Leoncini                              phone:  +39 (0823) 623134
Scientific Visualization Group                fax:    +39 (0823) 623126
CIRA - Italian Center for Aerospace Researches  p.l...@ci...
Via Maiorise - 81043 Capua (CE) Italy         www.cira.it/research/vis

> -----Messaggio originale-----
> Da: pli...@li...
> [mailto:pli...@li...]Per conto di Steve Baker
> Inviato: mercoledì 21 giugno 2000 14.44
> A: pli...@li...
> Oggetto: Re: [Plib-users] Linux-based game console
>
>
> Paolo Leoncini wrote:
> >
> > For your knowledge -
> >
> >  http://www.indrema.com/servlet/site
>
> Hmmm - interesting.
>
> I wonder how they intend to get software for this box?  Presumably
> they aren't going to rely on Quake plus Loki plus 23 versions of
> Tetris to get this thing off the ground?
>
> --
> Steve Baker                  http://web2.airmail.net/sjbaker1
> sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
> sj...@ht...      (work)
>
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users
>

Re: [Plib-users] Linux-based game console

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

Paolo Leoncini wrote:
> 
> For your knowledge -
> 
>  http://www.indrema.com/servlet/site

Hmmm - interesting.

I wonder how they intend to get software for this box?  Presumably
they aren't going to rely on Quake plus Loki plus 23 versions of
Tetris to get this thing off the ground?

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

[Plib-users] Linux-based game console

[Paolo L. <p.l...@ci...>]

For your knowledge -  
 
 http://www.indrema.com/servlet/site

Greetings -

Paolo

Re: R: R: [Plib-users] Transparent texture

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

Paolo Leoncini wrote:
> 
> Thanks, Steve, for the useful suggestions - I finally saw those
> semi-translucent textures in my database. What I did? these simple three
> things:
> 
> 1. glBlendFunc( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA )
>    so to not actually need alpha planes still getting roughly good blending;

Yep - only a few rather esoteric algorithms actually need destination
alpha - and quite a few graphics cards don't support them.

> 2. mat->enable( GL_BLEND ) and mat->setAplhaClamp(0.01)
>    the latter to get the full [0:255] alpha range;

Yep.
 
> 3. switch for tests to a AccellGraphics GMX2000-equipped NT box (!!!!)
> instead of my G200 on NT, which soon switch to software with as few as
> 2.5Mtexels loaded and doesn't want to know about alpha-ed textures (latest
> driver, of course).

I'm not familiar with Windoze drivers - but a board shouldn't switch
to software rendering just because you are using too much texture memory.
It might take a while to swap maps in and out of memory - but it's probably
still hardware accellerated.

Dunno why G200 would have trouble with alpha - it works OK under Linux.

> Since I would like to rely on (3DS) modeller's information as much as
> possible, a further little work will focus on automatically set those
> properties for transparent textures (only the image loader knows about the
> 2/4-components) - the AppStateCallback seems once again the final resource.

Well, I guess whatever the problem is should be fixed - but I still believe
that most applications will want to use AppStateCallback in the end.

> Furthermore one has also to "isolate" translucent objects from the rest of
> the database for rendering with z-buffer disabled after all other objects,
> for best blending results.

SSG does that automatically for you.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

R: R: [Plib-users] Transparent texture

[Paolo L. <p.l...@ci...>]

Thanks, Steve, for the useful suggestions - I finally saw those
semi-translucent textures in my database. What I did? these simple three
things:

1. glBlendFunc( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA )
   so to not actually need alpha planes still getting roughly good blending;

2. mat->enable( GL_BLEND ) and mat->setAplhaClamp(0.01)
   the latter to get the full [0:255] alpha range;

3. switch for tests to a AccellGraphics GMX2000-equipped NT box (!!!!)
instead of my G200 on NT, which soon switch to software with as few as
2.5Mtexels loaded and doesn't want to know about alpha-ed textures (latest
driver, of course).

Since I would like to rely on (3DS) modeller's information as much as
possible, a further little work will focus on automatically set those
properties for transparent textures (only the image loader knows about the
2/4-components) - the AppStateCallback seems once again the final resource.
Furthermore one has also to "isolate" translucent objects from the rest of
the database for rendering with z-buffer disabled after all other objects,
for best blending results.

Thanks again -

----------------------------------------------------------------------------
-
Paolo Leoncini						phone:  +39 (0823) 623134
Scientific Visualization Group			fax:    +39 (0823) 623126
CIRA - Italian Center for Aerospace Researches	p.l...@ci...
Via Maiorise - 81043 Capua (CE) Italy		www.cira.it/research/vis

> -----Messaggio originale-----
> Da: pli...@li...
> [mailto:pli...@li...]Per conto di Steve Baker
> Inviato: venerdì 16 giugno 2000 21.02
> A: pli...@li...
> Oggetto: Re: R: [Plib-users] Transparent texture
>
>
> Paolo Leoncini" <p.l...@ci...> wrote:
>
> > The easy explanation could be that all works ok, and I'm doing something
> > wrong...
>
> That's what I'm going with right now!
>
> > but the fact is that I don't set anything special for getting
> > trasparent textures, other than to supply the alpha-equipped [2/4
> > compoments] texture.
> > The little step forward, that anyway doesn't solve the general
> problem, is
> > to set
> >
> > materials[...]->setAlphaClamp(0.5f)
> >
> > into the 3DS loader. This actually rises the threshold of the
> transparent
> > part with respect to the opaque, but I'm still in trouble with the full
> > [0:255] alpha range support in rgba/inta textures.
>
> I don't know offhand what the 3DS loader is doing with that
> field...however,
> transparency *certainly* works in SSG - I use it constantly in all sorts
> of applications.
>
> Here is the code I use to set up an ssgSimpleState in my latest project:
>
>   /* Declare it... */
>
>   *gst = new ssgSimpleState ;
>
>   /*
>     I allocate a simple integer index to every State
>     to make it easier for my collision detection code
>     to tell me what kind of material we collided with.
>   */
>
>   (*gst) -> setExternalPropertyIndex ( index ) ;
>
>   /*
>     Load up the texture...or not.
>   */
>
>   if ( texture_map [ 0 ] != '\0' )
>   {
>     (*gst) -> setTexture ( texture_map, !(clamp_tex & UCLAMP),
>                                         !(clamp_tex & VCLAMP) ) ;
>     (*gst) -> enable ( GL_TEXTURE_2D ) ;
>   }
>   else
>     (*gst) -> disable ( GL_TEXTURE_2D ) ;
>
>   /*
>     Turn on lighting...or not
>   */
>
>   if ( lighting )
>     (*gst) -> enable ( GL_LIGHTING ) ;
>   else
>     (*gst) -> disable ( GL_LIGHTING ) ;
>
>   /*
>     Set up some other things I use a lot
>   */
>
>   (*gst) -> setShadeModel ( GL_SMOOTH ) ;
>   (*gst) -> enable ( GL_COLOR_MATERIAL ) ;
>   (*gst) -> enable ( GL_CULL_FACE      ) ;
>   (*gst) -> setColourMaterial ( GL_AMBIENT_AND_DIFFUSE ) ;
>   (*gst) -> setMaterial ( GL_EMISSION, 0, 0, 0, 1 ) ;
>   (*gst) -> setMaterial ( GL_SPECULAR, 0, 0, 0, 1 ) ;
>   (*gst) -> setShininess ( 0 ) ;
>
>   /*
>     Set up transparency...or not
>   */
>
>   if ( transparency )
>   {
>     (*gst) -> setTranslucent () ;
>     (*gst) -> enable ( GL_ALPHA_TEST ) ;
>     (*gst) -> setAlphaClamp ( alpha_ref ) ;  /* 0..1 */
>     (*gst) -> enable ( GL_BLEND ) ;
>   }
>   else
>   {
>     (*gst) -> setOpaque () ;
>     (*gst) -> disable ( GL_BLEND ) ;
>   }
>
>
> I have noticed that my GeForce-256 card (running the nVidia
> OpenGL-for-Linux
> driver) seems to misbehave a little with some values of AlphaClamp.
>
> > Does anybody work with full alpha'ed textures for special effects in
> > plib/ssg-based games?
>
> Yes.
>
> > I read 3DS files for tests, so if anyone does it with
> > (secene data) in a different format, it could lead to
> understand that there
> > is some bad setting in the 3DS reader, so we could modify it...
>
> Well, I find that modellers in general do a very poor job of giving me the
> exact 'material' parameters that I need - so my applications generally
> load a table of material properties that I create by hand (either as a
> parsed ASCII file - or hard-coded into the application).  As the model
> is loaded, I match up the texture map that was applied to the model to
> the texture map name in my application's material property table.
>
> The 'ssgSetAppStateCallback(getAppState)' callback does this.
>
> Hence, I don't care what the loader does with material properties...so
> there could easily be a bug.
>
> > Sorry for insisting on it, but I'm very disappointed (still loving plib,
> > anyway!) -
>
> Well, don't worry too much - it *does* work in the core of SSG - so either
> you are not setting it up right or the 3DS loader is broken.
>
> From your description, it seems like you probably don't have...
>
>     ssgstate -> enable ( GL_BLEND ) ;
>
> ...set.  If you don't have that then OpenGL will still compute
> alpha values - but it won't BLEND the new polygon into the
> background - it'll either be on or off - opaque or *nothing*.
>
> So, check that out - and if you are still getting nowhere,
> *someone* will need to take a look into the ssgState stuff
> in the 3DS loader.
>
>
> --
> Steve Baker                  http://web2.airmail.net/sjbaker1
> sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
> sj...@ht...      (work)
>
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users
>

Re: R: [Plib-users] Transparent texture

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

Paolo Leoncini" <p.l...@ci...> wrote:

> The easy explanation could be that all works ok, and I'm doing something
> wrong...

That's what I'm going with right now!

> but the fact is that I don't set anything special for getting
> trasparent textures, other than to supply the alpha-equipped [2/4
> compoments] texture.
> The little step forward, that anyway doesn't solve the general problem, is
> to set
> 
> materials[...]->setAlphaClamp(0.5f)
>
> into the 3DS loader. This actually rises the threshold of the transparent
> part with respect to the opaque, but I'm still in trouble with the full
> [0:255] alpha range support in rgba/inta textures.

I don't know offhand what the 3DS loader is doing with that field...however,
transparency *certainly* works in SSG - I use it constantly in all sorts
of applications.

Here is the code I use to set up an ssgSimpleState in my latest project:

  /* Declare it... */

  *gst = new ssgSimpleState ;

  /*
    I allocate a simple integer index to every State
    to make it easier for my collision detection code
    to tell me what kind of material we collided with.
  */
 
  (*gst) -> setExternalPropertyIndex ( index ) ;
 
  /*
    Load up the texture...or not.
  */

  if ( texture_map [ 0 ] != '\0' )
  {
    (*gst) -> setTexture ( texture_map, !(clamp_tex & UCLAMP),
                                        !(clamp_tex & VCLAMP) ) ;
    (*gst) -> enable ( GL_TEXTURE_2D ) ;
  }
  else
    (*gst) -> disable ( GL_TEXTURE_2D ) ;

  /*
    Turn on lighting...or not
  */
 
  if ( lighting )
    (*gst) -> enable ( GL_LIGHTING ) ;
  else
    (*gst) -> disable ( GL_LIGHTING ) ;

  /*
    Set up some other things I use a lot
  */
 
  (*gst) -> setShadeModel ( GL_SMOOTH ) ;
  (*gst) -> enable ( GL_COLOR_MATERIAL ) ;
  (*gst) -> enable ( GL_CULL_FACE      ) ;
  (*gst) -> setColourMaterial ( GL_AMBIENT_AND_DIFFUSE ) ;
  (*gst) -> setMaterial ( GL_EMISSION, 0, 0, 0, 1 ) ;
  (*gst) -> setMaterial ( GL_SPECULAR, 0, 0, 0, 1 ) ;
  (*gst) -> setShininess ( 0 ) ;

  /*
    Set up transparency...or not
  */
 
  if ( transparency )
  {
    (*gst) -> setTranslucent () ;
    (*gst) -> enable ( GL_ALPHA_TEST ) ;
    (*gst) -> setAlphaClamp ( alpha_ref ) ;  /* 0..1 */
    (*gst) -> enable ( GL_BLEND ) ;
  }
  else
  {
    (*gst) -> setOpaque () ;
    (*gst) -> disable ( GL_BLEND ) ;
  }                                                                             

I have noticed that my GeForce-256 card (running the nVidia OpenGL-for-Linux
driver) seems to misbehave a little with some values of AlphaClamp.

> Does anybody work with full alpha'ed textures for special effects in
> plib/ssg-based games?

Yes.

> I read 3DS files for tests, so if anyone does it with
> (secene data) in a different format, it could lead to understand that there
> is some bad setting in the 3DS reader, so we could modify it...

Well, I find that modellers in general do a very poor job of giving me the
exact 'material' parameters that I need - so my applications generally
load a table of material properties that I create by hand (either as a
parsed ASCII file - or hard-coded into the application).  As the model
is loaded, I match up the texture map that was applied to the model to
the texture map name in my application's material property table.

The 'ssgSetAppStateCallback(getAppState)' callback does this.

Hence, I don't care what the loader does with material properties...so
there could easily be a bug.

> Sorry for insisting on it, but I'm very disappointed (still loving plib,
> anyway!) -

Well, don't worry too much - it *does* work in the core of SSG - so either
you are not setting it up right or the 3DS loader is broken.

From your description, it seems like you probably don't have...

    ssgstate -> enable ( GL_BLEND ) ;

...set.  If you don't have that then OpenGL will still compute
alpha values - but it won't BLEND the new polygon into the
background - it'll either be on or off - opaque or *nothing*.

So, check that out - and if you are still getting nowhere,
*someone* will need to take a look into the ssgState stuff
in the 3DS loader.


-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

[Plib-users] SUNWspro patch, questions

[Loring H. <ls...@cs...>]

This patch allows PLIB to be built under Solaris w/ the SUNWspro C++ compiler
on a system without glut in the default place (ie, adds --with-glut and
--with-glut-includes).

Also - not sure if it is my version of automake or not (1.4), but automake
creates PLIB Makefile's that assume you are using gcc (uses -Md to create
dependencies).  I didn't know of any easy way to fix this - it gives a
warning message when compiling with SUNWspro 4.2, but builds fine.

Other issues - the README in cvs is out of date (points to the wrong URL),
and the documentation is out of date with the cvs source.  Would it be
possible to put the examples and docs in cvs so it would be easier to get the
most recent versions (and give all the other benefits of cvs)?

Thanks,
Loring

Index: configure.in
===================================================================
RCS file: /cvsroot/plib/plib/configure.in,v
retrieving revision 1.4
diff -u -r1.4 configure.in
--- configure.in	2000/05/16 22:22:15	1.4
+++ configure.in	2000/06/16 13:14:12
@@ -27,6 +27,26 @@
 AC_PROG_INSTALL
 AC_PROG_RANLIB
 
+dnl Command line arguments
+AC_ARG_WITH(glut,
+[  --with-glut=DIR         set the prefix directory where GLUT resides],
+GLUT_PREFIX=$withval, GLUT_PREFIX=auto)
+
+AC_ARG_WITH(glut-includes,
+[  --with-glut-includes=DIR
+                          set the directory where GLUT include files reside],
+GLUT_INCLUDES=$withval, GLUT_INCLUDES=auto)
+if test "x$GLUT_INCLUDES" != "xauto"; then
+    CPPFLAGS="$CPPFLAGS -I$GLUT_INCLUDES" 
+else
+    if test "x$GLUT_PREFIX" != "xauto"; then
+        CPPFLAGS="$CPPFLAGS -I$GLUT_PREFIX/include"
+    fi
+fi
+if test "x$GLUT_PREFIX" != "xauto"; then
+    LIBS="$LIBS -L$GLUT_PREFIX/lib"
+fi
+
 dnl Checks for library functions.
 dnl check for OpenGL related libraries
 
@@ -39,6 +59,9 @@
     AC_PATH_XTRA
 
     x_suffix="$X_LIBS $X_PRE_LIBS -lX11 -lXi -lXext -lXmu $X_EXTRA_LIBS -lm"
+    if test "x$x_includes" != "x"; then
+       CPPFLAGS="$CPPFLAGS -I$x_includes"
+    fi
 
     dnl Reasonable stuff non-windoze variants ... :-)
 
Index: src/sl/slPortability.h
===================================================================
RCS file: /cvsroot/plib/plib/src/sl/slPortability.h,v
retrieving revision 1.2
diff -u -r1.2 slPortability.h
--- src/sl/slPortability.h	2000/02/20 00:54:23	1.2
+++ src/sl/slPortability.h	2000/06/16 13:14:13
@@ -66,7 +66,7 @@
 #  include <audio.h>
 #endif
 
-#if defined(__svr4__)
+#if defined(__svr4__) || defined(__SVR4)
 #  include <sys/audioio.h>
 #  include <sys/stropts.h>
 #  define SOLARIS
Index: src/ssg/ssg.h
===================================================================
RCS file: /cvsroot/plib/plib/src/ssg/ssg.h,v
retrieving revision 1.20
diff -u -r1.20 ssg.h
--- src/ssg/ssg.h	2000/05/16 21:58:27	1.20
+++ src/ssg/ssg.h	2000/06/16 13:14:13
@@ -21,6 +21,13 @@
 #define FALSE 0
 #endif
 
+// SUNWspro 4.2 and earlier need bool to be defined
+#if defined(__SUNPRO_CC) && __SUNPRO_CC < 0x500
+typedef int bool;     
+const   int true  = 1;
+const   int false = 0;
+#endif
+
 #ifndef _SSG_PUBLIC
 #define _SSG_PUBLIC  protected
 #endif

R: [Plib-users] Transparent texture

[Paolo L. <p.l...@ci...>]

Dear plib/ssg friends,

I didn't hear anything related to the subject, and I am a bit surprised that
a community around a game-oriented library is not much sensitive to it.
The easy explanation could be that all works ok, and I'm doing something
wrong... but the fact is that I don't set anything special for getting
trasparent textures, other than to supply the alpha-equipped [2/4
compoments] texture.
The little step forward, that anyway doesn't solve the general problem, is
to set

materials[...]->setAlphaClamp(0.5f)

into the 3DS loader. This actually rises the threshold of the transparent
part with respect to the opaque, but I'm still in trouble with the full
[0:255] alpha range support in rgba/inta textures.

Does anybody work with full alpha'ed textures for special effects in
plib/ssg-based games? I read 3DS files for tests, so if anyone does it with
(secene data) in a different format, it could lead to understand that there
is some bad setting in the 3DS reader, so we could modify it...

Sorry for insisting on it, but I'm very disappointed (still loving plib,
anyway!) -

Paolo

----------------------------------------------------------------------------
-
Paolo Leoncini						phone:  +39 (0823) 623134
Scientific Visualization Group			fax:    +39 (0823) 623126
CIRA - Italian Center for Aerospace Researches	p.l...@ci...
Via Maiorise - 81043 Capua (CE) Italy		www.cira.it/research/vis

> -----Messaggio originale-----
> Da: pli...@li...
> [mailto:pli...@li...]Per conto di Paolo
> Leoncini
> Inviato: martedì 6 giugno 2000 12.06
> A: pli...@li...
> Oggetto: [Plib-users] Transparent texture
>
>
> Why in SSG my transparent (rgba/inta) textures appear with a sharp
> transition from alpha=255 to alpha<255, like 1-bit alpha?
>
> Better explained, whilst alpha channel is fully exploited (i.e. [0:255]
> range), transparent area on such textures is limited to where
> alpha is 255.
> This obviously results in a bad "halo" where, let's say, 0<alpha<255, and
> effects like steam, smoke are thus impossible to be done thru textures.
>
> Should I enable some special flag in the state node? (the image loader
> correctly understand the zsize 2 or 4 of such textures).
>
> Greetings -
>
> Paolo
>
> ------------------------------------------------------------------
> ----------
> -
> Paolo Leoncini
> phone:  +39 (0823) 623134
> Scientific Visualization Group			fax:    +39
> (0823) 623126
> CIRA - Italian Center for Aerospace Researches	p.l...@ci...
> Via Maiorise - 81043 Capua (CE) Italy		www.cira.it/research/vis
>
>
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users
>

Re: [Plib-users] axes, OpenGL primitives and other confusion.

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

Stafford Goodsell wrote:

> 1)
> I am having major trouble with this coordinate system stuff. I did some more
> tests, and i really must insist that the axis of rotation is different to the
> axis of translation in plib.

No - your error is in assuming that the two three element float arrays
are: translation in X/Y/Z and rotation around X/Y/Z - that is NOT the
case.  The rotation array is H/P/R (Heading/Pitch/Roll) - which is
rotation about (respectively) Z,X,Y.  This may seem a little strange - but
I always think of Euler angle rotations as 'Heading', 'Pitch' and 'Roll'
and *NOT* as rotations about the three axes.  Since people generally
talk about "Heading/Pitch/Roll" and not "Pitch/Roll/Heading", the order
of elements in the array seems "appropriate".

Some people prefer the term "Yaw" rather than "Heading" - but I dislike
using a word that begins with X,Y or Z since that prohibits the use of
single letter variables!

> Here is the startup code i use for the position of my helicopter:
> 
>     model_obj->lin_p[0] = 0.0; // model_obj can be considered a structure that
>     model_obj->lin_p[1] = 0.0; // holds the angle (ang_p), and position
>     model_obj->lin_p[2] = 90.0; // (lin_p) values of the model.
>     model_obj->ang_p[0] = 0.0;
>     model_obj->ang_p[1] = 0.0;
>     model_obj->ang_p[2] = 0.0;
> 
> Then later on, every frame calls this:
>     sgSetCoord(&modelpos, model_obj->lin_p, model_obj->ang_p);
>     model -> setTransform(&modelpos);
>     ssgCullAndDraw ( scene ) ; // model is a ssgTransform in scene

Seems reasonable.
 
> This puts the helicopter at 90 units above the 'ground' (which is at 0,0,0),

...indeed.

> and indicates as you have all pointed out that the z is up axis for plib.

Correct.

> Now, suppose i want to rotate around z? This would be equivalent to the
> helicopter spinning as if its tail rotor were being activated.

Yep - this is a change in the helicopter's heading - which is the first
element in the 'hpr' array. (That's why it's called 'hpr' - to remind
you of the order of the elements!)

> Since z is up,
> and the axis i want to rotate around, i should be able to do this:
> 
>     model_obj->lin_p[0] = 0.0;
>     model_obj->lin_p[1] = 0.0;
>     model_obj->lin_p[2] = 90.0;
>     model_obj->ang_p[0] = 0.0;
>     model_obj->ang_p[1] = 0.0;
>     model_obj->ang_p[2] = 90.0;

Yep - so the third element of the ang_p array is 'Roll'...
 
> But alas, the helicopter then ends up rotated 90 degrees around the axis going
> into the screen (y?), not z.

Yep - it rolled - just like you told it to.

> This indicates to me that the axis of rotation is
> different than the axis of translation.

It's just a matter of convention.  I'm used to using SGI's Performer
scene graph library - and if you've ever used that, you'll notice a
rather strong resemblence to my own SG library in Performer's linear
math functions.

> If i am mistaken anywhere here please point out where im wrong, but if this is
> true... well im stumped as to how to do rotations relative to the object
> properly :(

Just remember 'hpr' and you'll be OK...or just forget the whole thing and
use Matrices or Quaternions.

> 2)
> On Steve's note about drawing with both opengl and ssg, I tried using a
> ssgSimpleState method, but it just produced lots of red flashes. (my lines
> are supposed to be red) I will continue to work on it, since i suspect it is
> a problem with my lines being in the wrong place or something like that, but
> in the process, i think i found a another bug in plib :) When i call
> ssgSimpleState->disable(), it produces a message:
> 
> 'Illegal mode passed to ssgSimpleState::disable(X)'
> 
> where 'X' is the mode given to the call. (I tried this with modes 0, 2 and 5
> (SSG_GL_TEXTURE_EN, SSG_GL_COLOR_MATERIAL_EN, SSG_GL_LIGHTING_EN; probably
> not in that order :)

The ssgSimpleState::enable/disable functions now take regular OpenGL tokens.

   eg

      my_state -> enable ( GL_LIGHTING ) ;


> Oh btw, if you feel like being a hero and playing with the whole code :), you
> can get it from anonymous cvs at sourceforge under the geome project:
> ano...@cv...:/cvsroot/geome
> checkout the 'demos' module

I'm *way* too busy right now - sorry.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

[Plib-users] axes, OpenGL primitives and other confusion.

[Stafford G. <su...@ma...>]

Hi again,

Thanks to those who gave me some pointers before.

1)
I am having major trouble with this coordinate system stuff. I did some more 
tests, and i really must insist that the axis of rotation is different to the 
axis of translation in plib. Whilst i will shortly be using opengl with plib 
together (thanks to Steve) these tests were done using only plibssg 
coordinate systems.
Here is the startup code i use for the position of my helicopter:

    model_obj->lin_p[0] = 0.0; // model_obj can be considered a structure that
    model_obj->lin_p[1] = 0.0; // holds the angle (ang_p), and position 
    model_obj->lin_p[2] = 90.0; // (lin_p) values of the model.
    model_obj->ang_p[0] = 0.0;
    model_obj->ang_p[1] = 0.0;
    model_obj->ang_p[2] = 0.0;

Then later on, every frame calls this:
    sgSetCoord(&modelpos, model_obj->lin_p, model_obj->ang_p);
    model -> setTransform(&modelpos);
    ssgCullAndDraw ( scene ) ; // model is a ssgTransform in scene

This puts the helicopter at 90 units above the 'ground' (which is at 0,0,0), 
and indicates as you have all pointed out that the z is up axis for plib.
Now, suppose i want to rotate around z? This would be equivalent to the 
helicopter spinning as if its tail rotor were being activated. Since z is up, 
and the axis i want to rotate around, i should be able to do this:

    model_obj->lin_p[0] = 0.0;
    model_obj->lin_p[1] = 0.0;
    model_obj->lin_p[2] = 90.0;
    model_obj->ang_p[0] = 0.0;
    model_obj->ang_p[1] = 0.0;
    model_obj->ang_p[2] = 90.0;

But alas, the helicopter then ends up rotated 90 degrees around the axis going 
into the screen (y?), not z. This indicates to me that the axis of rotation is 
different than the axis of translation. 

If i am mistaken anywhere here please point out where im wrong, but if this is 
true... well im stumped as to how to do rotations relative to the object
properly :(

2)
On Steve's note about drawing with both opengl and ssg, I tried using a 
ssgSimpleState method, but it just produced lots of red flashes. (my lines 
are supposed to be red) I will continue to work on it, since i suspect it is 
a problem with my lines being in the wrong place or something like that, but 
in the process, i think i found a another bug in plib :) When i call 
ssgSimpleState->disable(), it produces a message:

'Illegal mode passed to ssgSimpleState::disable(X)'

where 'X' is the mode given to the call. (I tried this with modes 0, 2 and 5
(SSG_GL_TEXTURE_EN, SSG_GL_COLOR_MATERIAL_EN, SSG_GL_LIGHTING_EN; probably 
not in that order :) 

Oh btw, if you feel like being a hero and playing with the whole code :), you 
can get it from anonymous cvs at sourceforge under the geome project:
ano...@cv...:/cvsroot/geome
checkout the 'demos' module

--
Stafford Goodsell  <su...@po...>                                     _
                                                                       C")
  Programmer, administrator, avid gamer and all-round computer geek    (_)
                 http://www.marys.dyndns.org/                          -"-

Re: [Plib-users] OpenGL primitives

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

Stafford Goodsell wrote:

> Im trying to debug some physics code i have, and i would like to draw a
> 'force vector' (GL_LINE) indicating where the force is applied. However, when
> i do, it does not show. (Yes i did it between glBegin/glEnd pairs) I think it
> is because im also using the ssg library to draw the main scene.

Well for starters, you need GL_LINES  the 'S' is important!  It's *really*
annoying that OpenGL defines a valid token 'GL_LINE' - but it's not the token
you pass to glBegin() - always use 'GL_LINES' - even if you are only drawing
one line!

However, that may not be your only problem because SSG generally leaves OpenGL
in an unspecified state - texture might be enabled - or lighting might be
turned on with the glMaterial specifying an alpha of zero (hence invisible
lines)...you really don't know...but we've thought about this, so...
 
> Is it possible to draw using both OpenGL and ssg scenes at the same time?

Yes - I do that all the time.

You'll probably need to do things like disabling texture, make sure that
the modelview and projection matrices are what you want (SSG has functions
to help with that).

The easiest way to get the OpenGL state to be what you want is to define
an ssgSimpleState object for your GL_LINES and to call:

     my_state->apply () ;

...just before you start drawing.  That way, SSG will change the current
state to do what you want without you having to worry about what states
SSG might have messed with.
 
> Also, the reason i need to debug this code so intensely is because it seems
> that the axes are different depending on if you are rotating or translating...
> for translating x appears to be -, y is |, and z is . (into the screen), but
> for rotations, x is around |, y is around -, and z is the same.

SSG uses a Z-is-up, X-is-right and Y-is-into-the-screen coordinate
system, with heading, pitch and roll defined appropriately for that
coordinate system.

> For example i can only get a helicopter to rotate around the
> global y axis (|) not its own y axis, which may be totally different.
> See http://marys.dyndns.org/~surge/geome/ for some pictures of this.

I think you need to read my paper:

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

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

RE: [Plib-users] OpenGL primitives

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

Stafford Goodsell writes
>Sent: Thursday, June 08, 2000 9:28 PM
>To: pli...@li...
>Subject: [Plib-users] OpenGL primitives
>
>
>
>Hi,
>
>Also, the reason i need to debug this code so intensely is 
>because it seems that the axes are different depending on 
>if you are rotating or translating... 
>for translating x appears to be -, y is |, and z is . (into 
>the screen), but for rotations, x is around |, y is around -, 
and z is the same. 

My guess is that you are confused by the difference between the
coordinate systems used by SSG and OpenGL.

In OpenGL Z is going in and out of the screen
whereas in SSG Z is up down or Y in OpenGL

To convert from  SSG to OpenGL you can use the following
// hack
sgMat4 copy_of_ssgOpenGLAxisSwapMatrix =
{
  {  1.0f,  0.0f,  0.0f,  0.0f },
  {  0.0f,  0.0f, -1.0f,  0.0f },
  {  0.0f,  1.0f,  0.0f,  0.0f },
  {  0.0f,  0.0f,  0.0f,  1.0f }
} ;

sgMat4 vm_tmp, view_mat;
sgTransposeNegateMat4 ( vm_tmp, current_view.VIEW ) ;
sgCopyMat4( view_mat, copy_of_ssgOpenGLAxisSwapMatrix ) ;
sgPreMultMat4( view_mat, vm_tmp ) ;
glLoadMatrixf( (float *)view_mat );

Nice Looking Helicopter :-))

Have you checked out FlightGear.
http://www.flightgear.otg

It is using SSG for the majority of its rendering
and comes with source. 

Norman Vine

Re: [Plib-users] OpenGL primitives

[Land T. S. <lan...@am...>]

Hello Stafford,

I don't know about 2d drawing, but I have a starfield in the back of one of my
menus -- here is the code I use:

void StarField::Draw()
{
    int i;
    float *px, *py, *pz;
    static float c = 0.0f;

    glMatrixMode( GL_PROJECTION );
    glLoadIdentity();
    gluPerspective(90.0f, 640.0f/480.0f, 1.0, 500.0);


    glMatrixMode( GL_MODELVIEW );
    glLoadIdentity();
    gluLookAt( 0.0, 0.0, -5.0f,
           0.0, 0.0, 0.0,
           0.0, 1.0, 0.0 );

    px = x;
    py = y;
    pz = z;

    glDisable(GL_LIGHTING);
    glPointSize(1.0f);
    glBegin( GL_POINTS );

    for( i=0; i<numStars; i++ )
    {
 glColor3f( 1.0f - *pz / STAR_MAXZ,
     1.0f - *pz / STAR_MAXZ,
     1.0f - *pz / STAR_MAXZ);

  glVertex3f( *px, *py, *pz );
 px++; py++; pz++;
    }
    glEnd();
    glEnable(GL_LIGHTING);
    glDisable(GL_BLEND);
}

Stafford Goodsell wrote:

> Hi,
>
> Im trying to debug some physics code i have, and i would like to draw a
> 'force vector' (GL_LINE) indicating where the force is applied. However, when
> i do, it does not show. (Yes i did it between glBegin/glEnd pairs) I think it
> is because im also using the ssg library to draw the main scene.
>
> Is it possible to draw using both OpenGL and ssg scenes at the same time?
>
> Also, the reason i need to debug this code so intensely is because it seems
> that the axes are different depending on if you are rotating or translating...
> for translating x appears to be -, y is |, and z is . (into the screen), but
> for rotations, x is around |, y is around -, and z is the same.
> For example:
>
> an object at (0, 0, 0):
>                                          -.
> an object at (0, -2, 5):
>                                               -.
> an object at (0, -4, 0), rotated by (180, 0, 0):
>                                          .-
>                          .
> the last one should be '- ' if the coordinate systems were the same.
>
> Is this a bug in plib, or some strange 'feature' of OpenGL? I have tried both
> plib 1.0.20, and 1.1.11, and they are the same in this respect. This anomaly
> is giving me much trouble in creating rotations relative to an object (as one
> needs in physics). For example i can only get a helicopter to rotate around the
> global y axis (|) not its own y axis, which may be totally different.
> See http://marys.dyndns.org/~surge/geome/ for some pictures of this.
>
> Thanks for any help.
>
> --
> Stafford Goodsell  <su...@po...>                                     _
>                                                                        C")
>   Programmer, administrator, avid gamer and all-round computer geek    (_)
>                 http://www.marys.dyndns.org/                          -"-
>
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-users

--
+-------------------------+--------------------------------------------+
| Landshark (dave)        | Visio clone for *nix? It's in the works:   |
| lan...@am... | http://queesio.sourceforge.net             |
+-------------------------+--------------------------------------------+
| X10 GUI Device Controller for *nix? http://q10.phlan.net             |
+----------------------------------------------------------------------+

[Plib-users] OpenGL primitives

[Stafford G. <su...@ma...>]

Hi,

Im trying to debug some physics code i have, and i would like to draw a 
'force vector' (GL_LINE) indicating where the force is applied. However, when 
i do, it does not show. (Yes i did it between glBegin/glEnd pairs) I think it 
is because im also using the ssg library to draw the main scene.

Is it possible to draw using both OpenGL and ssg scenes at the same time?

Also, the reason i need to debug this code so intensely is because it seems 
that the axes are different depending on if you are rotating or translating... 
for translating x appears to be -, y is |, and z is . (into the screen), but 
for rotations, x is around |, y is around -, and z is the same. 
For example:

an object at (0, 0, 0):  
                                         -.
an object at (0, -2, 5):
                                              -.
an object at (0, -4, 0), rotated by (180, 0, 0):
                                         .-
                         .
the last one should be '- ' if the coordinate systems were the same.

Is this a bug in plib, or some strange 'feature' of OpenGL? I have tried both 
plib 1.0.20, and 1.1.11, and they are the same in this respect. This anomaly 
is giving me much trouble in creating rotations relative to an object (as one 
needs in physics). For example i can only get a helicopter to rotate around the 
global y axis (|) not its own y axis, which may be totally different.
See http://marys.dyndns.org/~surge/geome/ for some pictures of this.

Thanks for any help.

--
Stafford Goodsell  <su...@po...>                                     _
                                                                       C")
  Programmer, administrator, avid gamer and all-round computer geek    (_)
                 http://www.marys.dyndns.org/                          -"-

Re: [Plib-users] bug in PLIB/SSG

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

dongoodman wrote:
> 
> I have downloaded PLIB 1.1.11; i do not know if this bug has been
> addressed, so I will mention it anyway.
> 
> with VC++ 6.0, when I attempt to compile SSG, VC++ returns four
> errors in ssg.SimpleState.cxx:
> C:\My Code\Plib\plib-1.1.11\src\ssg\ssgSimpleState.cxx(18) : error C2106: '=' : left operand must be l-value
> C:\My Code\Plib\plib-1.1.11\src\ssg\ssgSimpleState.cxx(19) : error C2106: '=' : left operand must be l-value
> C:\My Code\Plib\plib-1.1.11\src\ssg\ssgSimpleState.cxx(20) : error C2106: '=' : left operand must be l-value
> C:\My Code\Plib\plib-1.1.11\src\ssg\ssgSimpleState.cxx(21) : error C2106: '=' : left operand must be l-value
> 
> I have fixed these errors by commenting out lines 18,19,20,21 and
> adding:
>   sgCopyVec4(specular_colour, src -> specular_colour);
>   sgCopyVec4(emission_colour, src -> emission_colour);
>   sgCopyVec4( ambient_colour, src ->  ambient_colour);
>   sgCopyVec4( diffuse_colour, src ->  diffuse_colour);
> 
> in thier stead. I can generate a diff file if that would be preferred.

This is a known bug and is already fixed in the newest versions in the
CVS.

> On that note: whenever I try to link against any PLIB static library (again,
> in windows), I get a whole lot of undefined symbol linker errors: is there
> something with the project files that prevents the libraries from compiling
> properly, or is it more likely that I'm just not linking them in to my
> project properly?

The MSVC workspaces are quite old. So they miss out a few files. As
these files aren't compiled their functions aren't availbe at linking.

So you'd just need to add the missing files to the correct projects
(IIRC only SSG is affected).

CU,
Christian

[Plib-users] Transparent texture

[Paolo L. <p.l...@ci...>]

Why in SSG my transparent (rgba/inta) textures appear with a sharp
transition from alpha=255 to alpha<255, like 1-bit alpha?

Better explained, whilst alpha channel is fully exploited (i.e. [0:255]
range), transparent area on such textures is limited to where alpha is 255.
This obviously results in a bad "halo" where, let's say, 0<alpha<255, and
effects like steam, smoke are thus impossible to be done thru textures.

Should I enable some special flag in the state node? (the image loader
correctly understand the zsize 2 or 4 of such textures).

Greetings -

Paolo

----------------------------------------------------------------------------
-
Paolo Leoncini						phone:  +39 (0823) 623134
Scientific Visualization Group			fax:    +39 (0823) 623126
CIRA - Italian Center for Aerospace Researches	p.l...@ci...
Via Maiorise - 81043 Capua (CE) Italy		www.cira.it/research/vis

[Plib-users] bug in PLIB/SSG

[dongoodman <de...@Ra...>]

I have downloaded PLIB 1.1.11; i do not know if this bug has been
addressed, so I will mention it anyway.

with VC++ 6.0, when I attempt to compile SSG, VC++ returns four
errors in ssg.SimpleState.cxx:
C:\My Code\Plib\plib-1.1.11\src\ssg\ssgSimpleState.cxx(18) : error C2106: '=' : left operand must be l-value
C:\My Code\Plib\plib-1.1.11\src\ssg\ssgSimpleState.cxx(19) : error C2106: '=' : left operand must be l-value
C:\My Code\Plib\plib-1.1.11\src\ssg\ssgSimpleState.cxx(20) : error C2106: '=' : left operand must be l-value
C:\My Code\Plib\plib-1.1.11\src\ssg\ssgSimpleState.cxx(21) : error C2106: '=' : left operand must be l-value

I have fixed these errors by commenting out lines 18,19,20,21 and
adding:
  sgCopyVec4(specular_colour, src -> specular_colour);
  sgCopyVec4(emission_colour, src -> emission_colour);
  sgCopyVec4( ambient_colour, src ->  ambient_colour);
  sgCopyVec4( diffuse_colour, src ->  diffuse_colour);

in thier stead. I can generate a diff file if that would be preferred.

On that note: whenever I try to link against any PLIB static library (again,
in windows), I get a whole lot of undefined symbol linker errors: is there
something with the project files that prevents the libraries from compiling
properly, or is it more likely that I'm just not linking them in to my
project properly?

please use the Reply-To address above to reply to me as I do not subscribe
to this mailing list. Though that may change.

thanks in advance!

have fun
dongoodman

    %---...@ra...|  |bleu|
    |`I invented the term 'object oriented',              pobox 2516|  |----|
    |and I can tell you                         mississippi state ms|  | () |
 /. |I did not have C++ in mind.'                              39762|  | /\ |
    |Alan Kay-------------------------------------------------------%