plib-users

[Plib-users] How should I use plib?

[Troy Y. <tro...@ho...>]

Sorry for the long post.  I'll ask my question(s)
up front.  A description of what I've been up to follows.

Q: What is the best way to create a scene/world using plib?
   It seems to me that loaders are extremely useful but
   what is their impact on one's ability to render a scene
   quickly and efficiently?  Aside from loading a model,
   and scaling/rotating/translating it what else must be
   done to manage the scene/world (i.e. BSP trees, LOD, etc.)?


What I'm doing...

The project I'm working on (day job) is a naval simulator
in which ships, aircraft, subs, weapons, rain clouds,
countermeasures, and biologics (whales, birds, etc.) appear.
A game engine exists that moves things around periodically.

Currently the only view into the simulation is a via
a 2D birds-eye representation using standard symbology.
I'm interested in spicing things up with a 3D representation.

Enter OpenGl... Enter plib...

Using the Tux-on-a-box example as a starting point, I've
managed to put something together that places models at the
correct locations and even has an ocean and land... first
iteration complete!

Now it's time to refine/improve/tune through reiteration
- and there's lots to do here.  

My current method of populating the scene is not at all
practical (not to mention ugly) especially with regard to
land and ocean.  Right now, I'm using an AC3D model of a
plane composed of 4 co-planar quads and scaling that to my
game boundaries (2000 nautical miles on a side).  I know I
could get creative and draw only a large enough 'ocean' to
produce a rendered scene that looks right but I've been
working in'minimum intervention' mode - aside from pointing
the camera, I don't have to do anything once the models are
placed. (Please remember that this is my first iteration on
my first OpenGl/3D program! :)

One of the immediate problems with my ocean approach is that
the ocean often disappears - it depends on the direction the
camera is pointing and where in the scene it is placed.  I'm
guessing that it's getting culled because there are no vertices
of the ocean inside the view frustum. Ok, so I'll have to use a
different method.  Eventually I'll want to add a texture and
possibly even some height variations (waves).  Before I talk
about this further, let me tell you about land.

I mentioned above that the game area is quite large - 2000
nautical miles on a side.  Although all action will typically
take place in a very small portion of the map, there is no
way to decide up front where that might be.  It is also
possible to 'warp' any entity to any place on the map at any
time. Since this is a naval simulation, most of the action
will take place on the water but may be near a major land mass.

At the moment, my land resolution is very coarse - altitude
in feet at every nautical mile grid point
(= 2000x2000 = 4,000,000 points).  Since much of this will
be water in many instances, I'm not using a 2000x2000 array
to store the data.  

Here's the worst part (I think) of how I'm realizing this land
in the scene... <cringing in anticipation of being bashed about
the head>... I'm loading a single instance of a unit sized AC3D
cube, scaling the height to match the height of a grid point
(by adding model to ssgTransform node) and translating it to
the appropriate grid location.  The net result is lots of
stretched cubes clustered about.

I know this is not going to work (it's not scalable and it's
UGLY) but I wanted to put something together with minimum
effort on my part (Think 'baby steps!').  I noted that
FlightGear has defined a bunch of tiles that get loaded
in and I assume that something like this is the way to go
here. How does one deal with being able to warp the
camera anywhere on the map though?

Well, thanks for your time.  Any pointers/comments would
be appreciated - perhaps you know of a 'getting started'
tutorial?  Anyway, welcome to my adventure! :)

Troy.

[Plib-users] Please Help!

[Ibrahim El-S. <sh...@ma...>]

Dear sir,
    At the installation, I typed ./configure and its ok no problem but when
I typed make I got the message attached with my E-Mail. thanks gor your
help.

Yours,
Ibrahim El-Shafei

[Plib-users] [Fwd: [FGFS-Devel] DON'T PANIC ?]

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

Hello PLIB developers!

Perhaps you do know that FGFS (which uses PLIB) has a booth at the San
Jose Linux World Expo.

We need desperately people who can help a bit at the booth. Wouldn't
this be a good chance to show to the world what PLIB is capable of?

So could you please mail Alex (ale...@qm...) if you are interested
in helping a bit - at least for a short time (I understood that you get
free entry).

I'm sure that you can help, even when you aren't *the* FGFS
hardcore-user.

The original message is attached.

CU,
Christian

-------- Original Message --------
Subject: [FGFS-Devel] DON'T PANIC ?
Date: Sun, 13 Aug 2000 14:13:46 -0700
From: Alex Perry <ale...@qm...>
Reply-To: fgf...@fl...
To: "'fgf...@fl...'" <fgf...@fl...>
CC: "'cu...@fl...'" <cu...@fl...>

The GOOD NEWS is that we have a booth
at the San Jose Linux World Expo.

The BAD NEWS is that we have the _best_
location of _any_ of the non-profit 
organizations.  Our location is much
better than Debian, or FSF, or LDP, etc...

(1) We desperately need people to man the booth.
Expo show hours are 10am-6pm Tue and Wed,
and 10am-2pm Thu this week.  If you know
anybody who might be able to make it,
please LET THEM KNOW ABOUT THIS.
They need to send me e-mail, so I can
create badges (if they don't have them).

(2) We have a 10 ft wide by 8 ft high
rear wall, which is currently mostly empty.
There is also a side wall of similar area.
All I have, so far, is four color pictures
in "letter" (approx A4) size and a copy
of the handout in double that size.

I also have about a thousand business card
size reminders that people can take away.
Note that this covers 5% of attendees, max.

They expect about 20,000 people to attend.
Based on the show map, I expect about a
quarter of them to walk though the door
which faces directly into our booth.

*** HELP!

Alex.


--
Please visit the FGFS web page:  http://www.flightgear.org
For help on using this list (especially unsubscribing), send a message
to
"fgf...@fl..." with a single line of text: "help".

Re: [Plib-users] SSG for 3ds and ASE

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

> Dave McClurg wrote:
> 
> > Can you detect when you get an old-style file and generate
> > normals like ssgLoadAC does?  (AC3D files *never* contain
> > normals).
> 
> ssgLoadAC doesn't generate normals.  That happens in ssgOptimiser
> (void OptVertexList::makeNormals()).  This code crashes when it runs
> on an ASE model.  What is worse is that ASE models create indexed
> ssgVtxArrays and shared verticies imply shared normals.
>  ssgOptimiser creates face normals instead of vertex normals.
>  This means a shared vertex may require two *different* normals
> and the indexed ssgVtxArray would have to be rebuilt.  ugh.

Yikes!  You understand this unholy mess better than I do!

We really need to stop and think about "Loader Service Routines" before
we go too much further down the loader writing curve.

I'd expect nearly any loader to benefit from:

  * Polygon decimation to triangles.
  * Optimal Tristrip creation.
  * Parser support.
  * Callbacks for applications that need to extend the
    file format via comment fields, etc.
  * Callbacks for applications that need to build their
    own ssgStates.
  * Surface normal generation.
  * Degenerate triangle/vertex removal.
  * Flattening (multiplying out the matrices in ssgTransform
    nodes and doing a one-time transform of vertices in the
    leaf node)
  * Degenerate group removal (eg deleting ssgBranch nodes with
    either one or zero children - but only if the node isn't
    known to the application - or a derived class of ssgBranch).
  * ssgState sharing between leaf nodes.
  * Texture coordinate size reduction.

...and probably a lot more.

Back when it looked like AC3D and maybe one other might be the only
loaders there would ever be, I didn't take too much time to modularize
this stuff.  But with the likelyhood that we could end up with a dozen
or more loaders eventually (especially since the advent of PPE), we need
to seriously look into this.

-- 
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] SSG for 3ds and ASE

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

> Can you detect when you get an old-style file and generate 
> normals like ssgLoadAC does?  (AC3D files *never* contain
> normals).
>

ssgLoadAC doesn't generate normals.  That happens in ssgOptimiser (void
OptVertexList::makeNormals()).  This code crashes when it runs on an ASE
model.  What is worse is that ASE models create indexed ssgVtxArrays and
shared verticies imply shared normals.  ssgOptimiser creates face normals
instead of vertex normals.  This means a shared vertex may require two
*different* normals and the indexed ssgVtxArray would have to be rebuilt.
ugh.

--Dave

Re: [Plib-users] SSG for 3ds and ASE

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

> Dave McClurg wrote:

> The problem turned out to be null color and normal arrays in a ssgVtxArray. GL_TEXTURE_2D was disabled, as it should be.

Ah - that'll do it!
 

> I already explained how to get proper vertex colors. To get proper vertex normals, things get tougher. The ASE format has vertex normals but they are wrong. :(  You'll either have to compute them yourself or fix the ASE exporter and use that.  The ASE exporter source comes with 3DSMAX in the MAXSDK cdrom folder.  Blake Senftner has a *fixed* ASE exporter here: http://www.pond.net/~davem/asciiexp/.  I have not had time to look at this.  If the format is still compatible with the *old* ase format and the vertex normals are correct, I can fix the ASE loader in SSG to read them.  Please let me know if you can help investigate.

Can you detect when you get an old-style file and generate normals like ssgLoadAC does?  (AC3D
files *never* contain normals).

-- 
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] SSG for 3ds and ASE

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

Steve Baker wrote:
> > 
> > Dan Gelb wrote:
> >
> > 1. Objects with just plain color properties, no textures, 
> > show up as white instead of the correct color.  Textured
> > objects work properly.  I've taken the tux_example and
> > replaced the tux model with models from 3DSMax, but
> > only textured objects show up properly.  Is there 
> > something I need to enable?
> > 
> It sounds like texturing is enabled - but no texture is 
> currently bound.
>

The problem turned out to be null color and normal arrays in a ssgVtxArray.
GL_TEXTURE_2D was disabled, as it should be.

The ASE exporter in 3DSMAX can dump vertex colors (if you mark the checkbox
for them) but they were not present in the files you gave me.  You might
have to *bake* them in first using the "Assign Vertex Color Utility".  It
takes the scene lighting and computes each vertex color.  What is you see in
3DSMAX is what you get in SSG.  I always bake my colors and use texture
mapping, so I didn't see the problems you were having.

Regardless, ssgLoadASE should handle this better so I addressed this problem
and did a CVS commit.  The source change in ssgLoadASE is based on
ssgLoadAC:

  if ( data -> st -> isEnabled ( GL_LIGHTING ) )
  {
    if ( data -> cl == NULL )
    {
      sgVec4 c ;
      sgCopyVec3 ( c, mat -> diff ) ;
      c[3] = 1.0f - mat -> transparency ;
  
      data -> cl = new ssgColourArray ( 1 ) ;
      data -> cl -> add ( c ) ;
    }
  
    if ( data -> vl -> getNum () >= 3 )
    {
      sgVec3 n ;
      sgMakeNormal ( n,
        data -> vl -> get(0),
        data -> vl -> get(1),
        data -> vl -> get(2) ) ;
  
      data -> nl = new ssgNormalArray ( 1 ) ;
      data -> nl -> add ( n ) ;
    }
  }

I already explained how to get proper vertex colors. To get proper vertex
normals, things get tougher. The ASE format has vertex normals but they are
wrong. :(  You'll either have to compute them yourself or fix the ASE
exporter and use that.  The ASE exporter source comes with 3DSMAX in the
MAXSDK cdrom folder.  Blake Senftner has a *fixed* ASE exporter here:
http://www.pond.net/~davem/asciiexp/.  I have not had time to look at this.
If the format is still compatible with the *old* ase format and the vertex
normals are correct, I can fix the ASE loader in SSG to read them.  Please
let me know if you can help investigate.

Anything that relates to improving support for the ASE format in SSG is very
important to me.  Thanks for reporting the ASE bugs.

-- Dave McClurg
mailto:dav...@dy...         http://www.dynamix.com
mailto:da...@po... (home)            http://www.pond.net/~davem 

Re: [Plib-users] SSG for 3ds and ASE

[Dan G. <dg...@hp...>]

When I use ASE models, I get no colors no matter what.  Dave seemed to
imply that is expected.

I discovered that with 3ds format, even if I have no textured objects
in the scene I still have weird color problems.  The first object in
the scene is always white, but subsequent objects seem to have the proper
colors.  If there are any textured objects in the scene I get no colors.

I also have weird behavior where sometimes objects don't show up in .3ds
format, but they do appear when the scene is saved in .ase format.
And also the problem of it crashing sometimes with .3ds models.

Eliminating the ssgFlatten did solve my problems with loading .ase models.  Thanks.

To sum it all up, with .ase format everything loads, but colors never work.
With .3ds format, things don't load very well, but colors kind of work.

Dan

Steve Baker wrote:
> 
> Dan Gelb wrote:
> >
> > I'm trying to use SSG for loading up some models out of 3DSMax, and I'm
> > having a few problems.  Sorry if these are newbie issues, I just started
> > trying to use Plib.  I looked through the mailing list archive but didn't
> > see these problems mentioned.
> >
> > 1. Objects with just plain color properties, no textures, show up as white
> > instead of the correct color.  Textured objects work properly.  I've taken
> > the tux_example and replaced the tux model with models from 3DSMax, but
> > only textured objects show up properly.  Is there something I need to enable?
> 
> It sounds like texturing is enabled - but no texture is currently bound.
> 
> OpenGL substitutes white texels when this happens.
> 
> > 2. Some models work when exported into ASE format, but crash when tried
> > in .3ds format.  This happens in parse_mapname in ssgLoad3ds.cxx on line 272
> > when strcmp seems to be passed a bad mapname.
> >
> > 3. Some models load in 3ds format, but crash in ASE format.  The crash
> > seems to happen in ssgFlatten.
> 
> ssgFlatten needs to be 'retired' - it was really only intended to clean up
> AC3D models after they are loaded in order to get reasonable performance
> from them.
> 
> --
> 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] works with Mesa 3.3?

[Wolfram K. <w_...@rz...>]

Steve wrote:

>Post - don't read!

Either that or use the bug-tracking tool at
http://sourceforge.net/project/?group_id=3
Look at the sample bug report first.
AFAIK, if you report a Mesa-bug and it is closed, you will
automatically get an E-mail.
(BTW, does anyone know how to close bugs in the Sourceforge bug
tracker?).

Bye bye,
Wolfram.

Re: [Plib-users] SSG for 3ds and ASE

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

> Dave McClurg wrote:

> > 3. Some models load in 3ds format, but crash in ASE format.  The crash
> > seems to happen in ssgFlatten.
> i've seen this too. don't use ssgFlatten or Stripify for now.
> Steve- can we put ssgOptimiser.cxx and ssgKeyFlier.h in ssgaux?

They need to be rewritten to make less assumptions about what they are
optimising before we can do that.  Meanwhile, those routines should really
only be used on something that ssgLoadAC created.

-- 
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] SSG for 3ds and ASE

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

Dan Gelb wrote:
> 
> I'm trying to use SSG for loading up some models out of 3DSMax, and I'm
> having a few problems.  Sorry if these are newbie issues, I just started
> trying to use Plib.  I looked through the mailing list archive but didn't
> see these problems mentioned.
> 
> 1. Objects with just plain color properties, no textures, show up as white
> instead of the correct color.  Textured objects work properly.  I've taken
> the tux_example and replaced the tux model with models from 3DSMax, but
> only textured objects show up properly.  Is there something I need to enable?

It sounds like texturing is enabled - but no texture is currently bound.

OpenGL substitutes white texels when this happens.

> 2. Some models work when exported into ASE format, but crash when tried
> in .3ds format.  This happens in parse_mapname in ssgLoad3ds.cxx on line 272
> when strcmp seems to be passed a bad mapname.
> 
> 3. Some models load in 3ds format, but crash in ASE format.  The crash
> seems to happen in ssgFlatten.

ssgFlatten needs to be 'retired' - it was really only intended to clean up
AC3D models after they are loaded in order to get reasonable performance
from them.

-- 
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] SSG for 3ds and ASE

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

Dan wrote:
> I'm trying to use SSG for loading up some models out of 
> 3DSMax, and I'm
> having a few problems.  Sorry if these are newbie issues, I 
> just started
> trying to use Plib.  I looked through the mailing list 
> archive but didn't
> see these problems mentioned.
> 
> 1. Objects with just plain color properties, no textures, 
> show up as white
> instead of the correct color.  Textured objects work 
> properly.  I've taken
> the tux_example and replaced the tux model with models from 
> 3DSMax, but
> only textured objects show up properly.  Is there something I 
> need to enable?
all my ASE models are textured but i've been meaning to fix that.
thanks for supplying the motivation.

> 3. Some models load in 3ds format, but crash in ASE format.  The crash
> seems to happen in ssgFlatten.
i've seen this too. don't use ssgFlatten or Stripify for now.
Steve- can we put ssgOptimiser.cxx and ssgKeyFlier.h in ssgaux?

> 
> I have sample files that reproduce the problems.
great! please send them to me and i'll get right on it. mailto:dp...@ef...

--Dave 

[Plib-users] SSG for 3ds and ASE

[Dan G. <dg...@hp...>]

I'm trying to use SSG for loading up some models out of 3DSMax, and I'm
having a few problems.  Sorry if these are newbie issues, I just started
trying to use Plib.  I looked through the mailing list archive but didn't
see these problems mentioned.

1. Objects with just plain color properties, no textures, show up as white
instead of the correct color.  Textured objects work properly.  I've taken
the tux_example and replaced the tux model with models from 3DSMax, but
only textured objects show up properly.  Is there something I need to enable?

2. Some models work when exported into ASE format, but crash when tried
in .3ds format.  This happens in parse_mapname in ssgLoad3ds.cxx on line 272
when strcmp seems to be passed a bad mapname.

3. Some models load in 3ds format, but crash in ASE format.  The crash
seems to happen in ssgFlatten.

I have sample files that reproduce the problems.

Dan

Re: [Plib-users] works with Mesa 3.3?

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

Steve Wendt wrote:
> 
> On Mon, 07 Aug 2000 19:40:13 -0500, Steve Baker wrote:
> 
> >> approximately the top inch of the screen is black when in 3Dfx mode on my
> >> Voodoo 2.  I guess the new Mesa fixes were tested on Voodoo 3, Banshee, or
> >> Voodoo 5.  :(   I guess I will stick to Mesa 3.2 until the next release comes out.
> >
> >Have you posted this to the Mesa list?
> >It's very important that they get this kind of feedback.
> 
> Nope... not on that list.  Last I looked, it was too high traffic for my interest level.
> :)

Post - don't read!

-- 
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] works with Mesa 3.3?

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

On Mon, 07 Aug 2000 19:40:13 -0500, Steve Baker wrote:

>> approximately the top inch of the screen is black when in 3Dfx mode on my
>> Voodoo 2.  I guess the new Mesa fixes were tested on Voodoo 3, Banshee, or
>> Voodoo 5.  :(   I guess I will stick to Mesa 3.2 until the next release comes out.
>
>Have you posted this to the Mesa list?
>It's very important that they get this kind of feedback.

Nope... not on that list.  Last I looked, it was too high traffic for my interest level.  
:)


-----------
"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] works with Mesa 3.3?

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

Steve Wendt wrote:
> 
> On Mon, 31 Jul 2000 00:31:57 -0500, Steve Baker wrote:
> 
> >> Has anyone tried using plib 1.2 with the 3Dfx Mesa 3.2.1 or 3.3?
> >> the top of the screen is blank
> >> I haven't tested other OpenGL apps yet (I should)
> >
> >Also, it's working in software mode - and since what Mesa does internally in
> >software and hardware modes is drastically different - but PLIB does the exact
> >same thing in both cases - we have to expect Mesa to be at fault.
> 
> This is definitely a Mesa problem, other, non-plib apps have the same problem --
> approximately the top inch of the screen is black when in 3Dfx mode on my
> Voodoo 2.  I guess the new Mesa fixes were tested on Voodoo 3, Banshee, or
> Voodoo 5.  :(   I guess I will stick to Mesa 3.2 until the next release comes out.

Have you posted this to the Mesa list?

It's very important that they get this kind of feedback.

-- 
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] works with Mesa 3.3?

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

On Mon, 31 Jul 2000 00:31:57 -0500, Steve Baker wrote:

>> Has anyone tried using plib 1.2 with the 3Dfx Mesa 3.2.1 or 3.3?
>> the top of the screen is blank
>> I haven't tested other OpenGL apps yet (I should)
>
>Also, it's working in software mode - and since what Mesa does internally in
>software and hardware modes is drastically different - but PLIB does the exact
>same thing in both cases - we have to expect Mesa to be at fault.

This is definitely a Mesa problem, other, non-plib apps have the same problem -- 
approximately the top inch of the screen is black when in 3Dfx mode on my 
Voodoo 2.  I guess the new Mesa fixes were tested on Voodoo 3, Banshee, or 
Voodoo 5.  :(   I guess I will stick to Mesa 3.2 until the next release comes out.


-----------
"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] plib compile error

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

Donald Harter wrote:
> 
> I get the following errors when I try to compile plib.  I am using redhat 6.1.
>  I had another error that I fixed by just defining HAVE_GLUT....

Well, it sounds like that original error is the source of your problems.

You *probably* don't have GLUT installed (or not installed properly).

You should have:

     /usr/include/GL/glut.h
     /usr/lib/libglut.so

> c++ -DPACKAGE=\"plib\" -DVERSION=\"1.2.0\" -DHAVE_LIBDL=1 -DHAVE_LIBGL=1 -DSTDC_HEADERS=1 -DHAVE_GL_GL_H=1 -DLINUX_JOYSTICK_IS_PRESENT=1  -I. -I.  -I../../src/sg -I../../src/fnt    -g -O2 -O6 -Wall -c pu.cxx
> pu.cxx: In function `void puInit()':
> pu.cxx:121: warning: implicit declaration of function `int glXGetCurrentContext(...)'
> pu.cxx:121: ANSI C++ forbids comparison between pointer and integer

glXGetCurrentContext is defined in /usr/include/GL/glx.h - which I don't include
explicitly because GLUT handles that in /usr/include/GL/glut.h.

So - check that GLUT is installed - if you had to force the HAVE_GLUT variable then
the configure script didn't auto-detect GLUT - which fits with this theory.

-- 
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] plib compile error

[Donald H. <dh...@ly...>]

I get the following errors when I try to compile plib.  I am using redhat 6.1.  I had another error that I fixed by just defining HAVE_GLUT....
make[2]: Leaving directory `/usr/src/plib-1.2.0/src/js'
Making all in sl
make[2]: Entering directory `/usr/src/plib-1.2.0/src/sl'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/usr/src/plib-1.2.0/src/sl'
Making all in pui
make[2]: Entering directory `/usr/src/plib-1.2.0/src/pui'
c++ -DPACKAGE=\"plib\" -DVERSION=\"1.2.0\" -DHAVE_LIBDL=1 -DHAVE_LIBGL=1 -DSTDC_HEADERS=1 -DHAVE_GL_GL_H=1 -DLINUX_JOYSTICK_IS_PRESENT=1  -I. -I.  -I../../src/sg -I../../src/fnt    -g -O2 -O6 -Wall -c pu.cxx
pu.cxx: In function `void puInit()':
pu.cxx:121: warning: implicit declaration of function `int glXGetCurrentContext(...)'
pu.cxx:121: ANSI C++ forbids comparison between pointer and integer
make[2]: *** [pu.o] Error 1
make[2]: Leaving directory `/usr/src/plib-1.2.0/src/pui'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/plib-1.2.0/src'
make: *** [all-recursive] Error 1  


I am using: 
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)   


Send your favorite photo with any online greeting!
http://www.whowhere.lycos.com/redirects/americangreetings.rdct

[Plib-users] yet another realtime interactive API

[Lance E A. <lan...@vt...>]

I found the the SL part of PLIB is something that I was looking for.
So thanks Steve!

I have a general interest in realtime interactive software,
writing it and using it.

I have written a LGPL Licensed C++ API that may be of interest to
you.  It's for networking of realtime user-in-the-loop simulator data
and hardware data (like joysticks).  It "network shares" data by
seemlessly abstracting arena shared memory to remote networked shared
memory.  So for example you could use it to share rigid body positions
(Nx6 floats) of aircraft in a multi-player dog fight simulator.  
The idea is that the coding of the single-player dog fight simulator
would be no different then coding a multi-player dog fight simulator
as long as rigid body positions are written to this "special shared
memory".  When the shared memory is not networked (turned off) it
acts just like regular inter process shared memory. The network
connectivity of the shared memory is a fully connected graph, but I plan
to extend this to general topologies. I think it will get pretty good
performance across modems. It's ported to IRIX and Linux. This is just
part of what it does. I've been working on it full-time.  I've been
building a crane ship simulator for the US navy that uses this package.

The package it called DIVERSE ToolKit: http://www.diverse.vt.edu/DTK/

If you like it let me know.  If you think this is spam let me know.
Please push this message around to interested parties.

cheers
lance

Re: [Plib-users] ssg and other things

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

Will Newton wrote:
 
> I apologise for not replying directly, but my wonderful hosting company
> deleted my mail spool. :)

Oh joy!  :-(
 
> Firstly, cell shading (probably the wrong term really, but the one most
> people seem to use)

OH!  "CEL SHADING" - one 'L' - as in Cel Animation.

> is 3D shading that looks like a comic book 2D image.
> Like Jet Set Radio (a fantastic Japanese Dreamcast game)... it may be used
> in a few other titles but that's probably the best example.

Yep - I know what you mean. Solid colours, hard shading transitions
and everything has a black outline...well, something like that.

Cool!
 
> I've had a look at the ssg code and I've decided it's easier just to rip
> the code out of the ssgLoad routines and the drawing stuff and hack it
> into something half approximatinbg a working program.

The joys of OpenSource!   :-)

> I'm not sure if any
> of the code I'm writing would be any use in plib (it's pretty
> specialized), but when I have something working I'll post a link.

It would be interesting - but you're right - it's a minority interest
kind of a thing.

Good luck!

-- 
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] ssg and other things

[Will N. <wi...@mi...>]

I apologise for not replying directly, but my wonderful hosting company
deleted my mail spool. :)

Firstly, cell shading (probably the wrong term really, but the one most
people seem to use) is 3D shading that looks like a comic book 2D image.
Like Jet Set Radio (a fantastic Japanese Dreamcast game)... it may be used
in a few other titles but that's probably the best example.

I've had a look at the ssg code and I've decided it's easier just to rip
the code out of the ssgLoad routines and the drawing stuff and hack it
into something half approximatinbg a working program. I'm not sure if any
of the code I'm writing would be any use in plib (it's pretty
specialized), but when I have something working I'll post a link.

Re: [Plib-users] Messing with ssg

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

Will Newton wrote:
> 
> I've been writing some cell shading code (Jet Set Radio style :) and I'm
> trying to hook it into ssg as a simple way to debug it.

I've never heard of 'cell shading' - or 'Jet Set Radio' - please enlighten me!

> In essence I need to override the drawing code of a particular object. It
> looks like it probably isn't possible, but can anyone see a way to do
> this?

Well, there are several ways:

* Write a derived class of ssgLeaf or ssgVtxTable that replaces the 'draw'
  virtual member function with whatever you need to do. You'll have to take
  on responsibility for calling pre- and post-Draw callbacks and working with
  the ssgState management system to get the states setup.

* As above - but only override the 'fraw_geometry' member function.  Then
  *all* you have to do is draw the polygons - the underlying native SSG
  class will do everything else.

* Write a pre-Draw callback for an existing class - but have it do all the
  rendering and return FALSE - which will tell SSG *not* to go and draw
  the object itself.

The third way avoids SSG's state setup code though - so you'd have to
set up (and restore) the OpenGL state before and after your rendering.

The first way is therefore considerably superior - but maybe more
than you want to do for a quick hack.

The second way is probably what you need.  Just look at:

   void ssgVtxTable::draw_geometry()

...in src/ssg/ssgVtxTable.cxx - use that as an example.

...and of course, when it's all working - CONTRIBUTE IT!

-- 
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] Messing with ssg

[Will N. <wi...@mi...>]

I've been writing some cell shading code (Jet Set Radio style :) and I'm
trying to hook it into ssg as a simple way to debug it.

In essence I need to override the drawing code of a particular object. It
looks like it probably isn't possible, but can anyone see a way to do
this?

Re: [Plib-users] works with Mesa 3.3?

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

Steve Wendt wrote:
 
> Has anyone tried using plib 1.2 with the 3Dfx Mesa 3.2.1 or 3.3?

Not yet.

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

Hmmm - not good - but then 3.3 is experimental/unstable.
 
> 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.  :)

Can you either describe this more carefully (What *exactly* do you mean by "severely
distorted"? Does it flick back and forth between 'distorted' and 'blank' in a single
run - even if the eyepoint is stationary?  When it's "blank" - is it black or some
other colour?) - or better still, post a screenshot to a web site somewhere (or if
you must, email to me *privately* - not to the list).  I'm particularly interested
in seeing the "distorted" case - that'll tell me much more than the "blank" case.

> I haven't tested other OpenGL apps yet (I should), but is this more likely to be a
> Mesa or plib problem? 

PLIB doesn't do anything special at the top of the screen - it doesn't even know
when it's drawing at the top of the screen.  I havn't seen this problem on any other OpenGL
implementations - so it's pretty certain to be a Mesa problem - but I *really*
need either a very careful description or a screen dump.

Also, it's working in software mode - and since what Mesa does internally in
software and hardware modes is drastically different - but PLIB does the exact
same thing in both cases - we have to expect Mesa to be at fault.

> Did something get fixed in Mesa that plib was "working around,"....

Nope - nothing that I'm aware of.

> or did something in Mesa break (which seems less likely, since they put
> some 3Dfx specific fixes in this one)?

Let's see the screen dump before passing a final opinion...but I'm betting
on Mesa.

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