plib-users

Re: [Plib-users] ssgInit called w/o OpenGL context

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

On Wed, 1 Aug 2001 al...@tu... wrote:

> > but I always compile my own Mesa to get the 3dfx support.
>
> fyi, my voodoo3 worked accelerated out of the box on rh7.1 ... had to install the preview tdfx.rpms for 7.0

That's different - you are getting support via the XFree86 4.x/Mesa tie.
It doesn't work that way with the Voodoo2, because there is no 2D support
for that card.  :)

Re: [Plib-users] ssgInit called w/o OpenGL context

[<al...@tu...>]

On Tue, Jul 31, 2001 at 05:27:42PM -0700, Steve Wendt wrote:
> On Wed, 1 Aug 2001 al...@tu... wrote:
> 
> > Its a Plib/Rh7.0 specific problem
> 
> Probably just a problem with the included Mesa.  I didn't have problems,
> but I always compile my own Mesa to get the 3dfx support.

fyi, my voodoo3 worked accelerated out of the box on rh7.1 ... had to install the preview tdfx.rpms for 7.0


> 
> 
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/lists/listinfo/plib-users

Re: [Plib-users] ssgInit called w/o OpenGL context

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

On Wed, 1 Aug 2001 al...@tu... wrote:

> Its a Plib/Rh7.0 specific problem

Probably just a problem with the included Mesa.  I didn't have problems,
but I always compile my own Mesa to get the 3dfx support.

Re: [Plib-users] ssgInit called w/o OpenGL context

[<al...@tu...>]

> However, if you see well-established programs doing this (The PLIB examples
> for instance) then it's most likely to be a botched OpenGL install of
> some kind.
> 
> Since RedHat Linux has been causing *ENDLESS* problems for me since version
> 7.0 was first released, I'm betting on a bad OpenGL install.
> 
> Have you managed to run any *non-PLIB* OpenGL programs?

I had this problem too with RH7.0 but i actually found a few messages in the archives dealing with this 
and as I was about to upgrade to RH7.1 anyway thats what I did.
Works fine now ...

The problem is not a general OpenGL problem though as all other OpenGL programs worked fine.
Its a Plib/Rh7.0 specific problem 

Re: [Plib-users] ssgInit called w/o OpenGL context

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

Viola & John Riggle wrote:
> 
> I'm running RH7.0 with the latest plib (1.4.2) & examples.  Everything
> compiles fine, but running any OpenGL program returns
> 
> FATAL:  ssgInit called without a valid OpenGL context.
> 
> I browsed in the archives to no avail.  Has anyone seen this before?

It's usually symptomatic of an incorrectly written application that tries
to initialise PLIB without a valid graphics window open.

However, if you see well-established programs doing this (The PLIB examples
for instance) then it's most likely to be a botched OpenGL install of
some kind.

Since RedHat Linux has been causing *ENDLESS* problems for me since version
7.0 was first released, I'm betting on a bad OpenGL install.

Have you managed to run any *non-PLIB* OpenGL programs?

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

[Plib-users] ssgInit called w/o OpenGL context

[Viola & J. R. <vjr...@mt...>]

I'm running RH7.0 with the latest plib (1.4.2) & examples.  Everything
compiles fine, but running any OpenGL program returns

FATAL:  ssgInit called without a valid OpenGL context.

I browsed in the archives to no avail.  Has anyone seen this before?
Thanks.

- Kevin Riggle

Re: [Plib-users] VRML loader

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

Diana Garroway wrote:
> 
> I noticed from the documentation on the availible loaders for plib that
> VRML was completely left out with the comment that it doesn't work very
> well.    What is the reason for this?  Why not VRML?

The old VRML loader didn't really work too well - the new one (which seems
pretty good in most cases) hasn't made it into a stable version of PLIB yet.

Having said that, the present PLIB 1.5 release seems every bit as reliable as
the latest 1.4 series release - so I'd grab that.

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

Re: [Plib-users] VRML loader

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

Diana Garroway <Dia...@nr...> wrote:

>I noticed from the documentation on the availible loaders for plib that
>VRML was completely left out with the comment that it doesn't work very
>well.   =20

Actually, the doc is not quite up to date in this respect. VRML 1 (but
not VRML 2) should work quite nicely now. If you have some VRML 1
objects you want to try, get PLIB either from CVS or one of the newer
downloads (1.4.2 or 1.5.1) and test it. Feedback is welcome.

>What is the reason for this?  Why not VRML?

The original reason is simply that no one wrote a complete, bug free
VRML loader. It is not a sort of decision "We don't need VRML".

>Diana

Bye bye,
Wolfram.

[Plib-users] VRML loader

[Diana G. <Dia...@nr...>]

I noticed from the documentation on the availible loaders for plib that
VRML was completely left out with the comment that it doesn't work very
well.    What is the reason for this?  Why not VRML?

Diana

Re: [Plib-users] Need advices to use Plib for a Roam algo

[Maltez <ma...@no...>]

> I'm not sure - that's why I asked!  I suppose you'd need to store a LIST
of
> states inside each node and to pick which set of states to use depending
> on the ssgContext that's set when your node is called.

Oh well, i didn't think about multiple root nodes for the graph, one for
each ssgContext.
Is this not a better choice to manage graphic or geometry states depending
on the camera ?

> Well, it's hard not to allow discontinuous motion...pretty much every
> application does that sooner or later.  But even if the camera motion
> is "smooth", when you are culled from the field of view - then when you
> come back into the field of view, the camera may have moved twenty miles
> and be looking at the terrain from the opposite direction.

Hmm, that will hapen only if the terrain engine is doing some kind of
pre-load or pre-computing with some predictive assumption of the camera
motion. My algo is far from that. But one day...

> Well, I thought your intention was to put this ROAM stuff *into* SSG.
That
> would be "A Good Thing" for the community - so if you are doing this as
> OpenSourced code then it would be good to put it into SSG rather than as
> a separate package.
>
> That's your call though.
>
Sorry it's not my current intention. When i feel confident and the code more
ready, i will think about that.
For now i just want to make the good choice in using and sub-classing SSG.

Maltez

Re: [Plib-users] Need advices to use Plib for a Roam algo

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

Maltez wrote:
> 
> > For example, if you use your first approach then it ought to be possible
> to model the
> > trrain skins using PrettyPoly.  If you take the second approach then what
> you have
> > is something that doesn't really become a part of PLIB/SSG because it
> doesn't subclass
> > from it.
> 
> How could PPE be aware of my subclasses ? is there some dynamic library
> loading (plugin) ?

No - I was assuming your classes would become a part of SSG...maybe that
wasn't your intention?

Presuming your classes were inside SSG, then PPE (and every other application)
would just see "some kind of a branch node" and "some kind of a leaf node" - and
so long as your derived classes support all the member functions of those
standard SSG classes, PPE (and other applications) will be happy.

> >   1) Multiple views of the same model, rendered consecutively. (PrettyPoly
> and
> >      my new 'Evil Overlord' project both do this).
> 
> For multiple views, i need to have one manager+tiles per view and share
> heightfiled and pre-computed variances because the manager and tiles states
> are depending on the camera and it's frustrum.
> How to make mgr1 visible and mgr2 invisible to camera 1 and the inverse to
> camera 2 ?

I'm not sure - that's why I asked!  I suppose you'd need to store a LIST of
states inside each node and to pick which set of states to use depending
on the ssgContext that's set when your node is called.
 
> >   However, one of the problems (as I understand it) with ROAM is that it
> > does a lot of incremental stuff (for speed) - so it needs to be run even
> > if it's not in view.  That may be unavoidable in this case - but we need
> > to think carefully about that.
> 
> My implement is not like that and it's not the case of the original algo
> don't say about that.
> When the mesh is entirely culled out from frustrum the manager will not be
> called and keep it's last state. All depends on the kind of camera move
> allowed : smooth or not.

Well, it's hard not to allow discontinuous motion...pretty much every
application does that sooner or later.  But even if the camera motion
is "smooth", when you are culled from the field of view - then when you
come back into the field of view, the camera may have moved twenty miles
and be looking at the terrain from the opposite direction.
 
> When you say EITHER, you mean only one class subclassing but not the 2 ?

Sorry, that wasn't very clear.

I mean "Don't derive from ssgEntity or ssgBase - please derive from
ssgBranch or ssgLeaf".
 
> > However, you don't need to derive from ssgVtxTable/ssgVtxArray...most
> applications
> > are quite robust in that respect.
> 
> What do you mean with robust ?

I mean that most (if not all) PLIB applications will be happy if you
feed them a new class that's derived from ssgLeaf or ssgBranch, you
don't have to derive from ssgVtxTable or ssgVtxArray.

Most applications will use ssgLoad() to grab their models and won't
have much knowledge of what's inside that model.

> > You might want to subscribe to the PLIB developer's list though - that's a
> better
> > place to ask this stuff than the user's list.
> 
> Ok, i have done that now. But i thought the devel list was for developpers
> of the core Plib not users like me which are developping with Plib but not
> modifying it. I don't want to bother the real developpers with newbie
> question.

Well, I thought your intention was to put this ROAM stuff *into* SSG.  That
would be "A Good Thing" for the community - so if you are doing this as
OpenSourced code then it would be good to put it into SSG rather than as
a separate package.

That's your call though.
 
----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

Re: [Plib-users] Need advices to use Plib for a Roam algo

[Maltez <ma...@no...>]

> For example, if you use your first approach then it ought to be possible
to model the
> trrain skins using PrettyPoly.  If you take the second approach then what
you have
> is something that doesn't really become a part of PLIB/SSG because it
doesn't subclass
> from it.

How could PPE be aware of my subclasses ? is there some dynamic library
loading (plugin) ?
i don't see that! and even think about that possibility. Perhaps i need to
watch PPE more closely.

>   1) Multiple views of the same model, rendered consecutively. (PrettyPoly
and
>      my new 'Evil Overlord' project both do this).

For multiple views, i need to have one manager+tiles per view and share
heightfiled and pre-computed variances because the manager and tiles states
are depending on the camera and it's frustrum.
How to make mgr1 visible and mgr2 invisible to camera 1 and the inverse to
camera 2 ?

>   However, one of the problems (as I understand it) with ROAM is that it
> does a lot of incremental stuff (for speed) - so it needs to be run even
> if it's not in view.  That may be unavoidable in this case - but we need
> to think carefully about that.

My implement is not like that and it's not the case of the original algo
don't say about that.
When the mesh is entirely culled out from frustrum the manager will not be
called and keep it's last state. All depends on the kind of camera move
allowed : smooth or not.

>
> > - another approach is put all in a fresh new subclass of ssgLeaf (and no
> > use of ssgVtxArray or ssgBranch). What about this technic ?
>
> You could do that...I've found that this is generally a lot more work -
but
> maybe not in your case.  It's important that you derive from EITHER
ssgLeaf
> OR ssgBranch - there is no third kind of thing allowed in the scene graph.

When you say EITHER, you mean only one class subclassing but not the 2 ?

> However, you don't need to derive from ssgVtxTable/ssgVtxArray...most
applications
> are quite robust in that respect.

What do you mean with robust ?

> You might want to subscribe to the PLIB developer's list though - that's a
better
> place to ask this stuff than the user's list.

Ok, i have done that now. But i thought the devel list was for developpers
of the core Plib not users like me which are developping with Plib but not
modifying it. I don't want to bother the real developpers with newbie
question.

Greetings

Re: [Plib-users] ExPoser

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

Steve Wendt wrote:
> 
> On Fri, 27 Jul 2001 19:00:21 +0200, Arne Kreutzmann wrote:
> 
> >       http://plib.sourceforge.net/dist/exposer_0.0.1.tar.gz
> 
> You want http://plib.sourceforge.net/dist/exposer-0.0.1.tar.gz

Yep.

I've just fixed the link (actually, I fixed it about a week ago - but
forgot to upload it onto the web site)...Doh!

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

Re: [Plib-users] ExPoser

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

On Fri, 27 Jul 2001 19:00:21 +0200, Arne Kreutzmann wrote:

>	http://plib.sourceforge.net/dist/exposer_0.0.1.tar.gz

You want http://plib.sourceforge.net/dist/exposer-0.0.1.tar.gz


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

[Plib-users] ExPoser

[Arne K. <Arn...@gm...>]

Hi,

the link to ExPoser is broken !!!!

I would like to held with the bone stuff, but without the tool I just can#t
do that.

Arne

PS.: Here Is the broken link:
From:
	http://plib.sourceforge.net/download.html#DEMOS 
to:
	http://plib.sourceforge.net/dist/exposer_0.0.1.tar.gz

Re: [Plib-users] ExPoser help required.

[Chris P. <bi...@se...>]

    I dont know much or anything about ExPoser yet so this may be out of
left field. But from what you descibe this may be a solution:

    I belive the Half Life model file also contains the bone movement for
the models. Most of them come with the "stock" halflife animation sequences.
Run Idle Crawl Jump Shoot Die Etc. Lots of the fan made custom models have
unique animations.

    This is one of the places to look for models.

http://www.planethalflife.com/polycount/downloads/index.asp?game=3&sort=date
&order=DESC

     If you could write an importer you could access a lot of pre-made
models with bone animation. And lots of developers that know how to create
that format.

    The MilkShape editor supports the format and has a fileview app with
source (dont have the link at the moment). I am not sure how "open" the
source is however. Some parts of it are from a Valve Half Life SDK. But I
guess they (Valve) dont mind you using the fileformat.

    Regards
        Chris


----- Original Message -----
From: "Steve Baker" <sjb...@ai...>
To: "PLIB-users" <pli...@li...>
Sent: Wednesday, July 25, 2001 4:21 PM
Subject: [Plib-users] ExPoser help required.


>
> I know from the volume of "Wow!" and "Thanks!" emails that quite a few
> people are having fun playing with ExPoser.
>
> I was wondering if people who are just playing or learning might like
> to contribute some ".bones" files for the "human.ac" model that comes
> with ExPoser.
>
> My next game needs:
>
>   * A variety of martial arts "moves" - anything that looks cool
>     will do.
>
>   * Shoot various weapons (these would be separate models - or
>     added to human.ac under a switch node).
>
>   * Walk, Run, Jump, Land(eg from a fall)
>
>   * Climb a ladder, Swim, Ski.
>
>   * Dive to the ground, get up again.
>
>   * Crouch down (as to place something on the floor), get up again.
>
>   * Rolls and gymnastic flips (as if to dodge a bullet - as if you
>     actually could! :-).
>
>   * Die (in a variety of creative ways - falling forwards, blown away
>     backwards, or even slump, take a couple of steps, collapse to knees,
>     say "Tis a cruel, cruel world" then fall flat on face!)
>
>   * Anything else that you can think of. :-)
>
> Any '.bones' files that would result would be released with 'ExPoser'
> under a "do whatever you like with these" kind of a license (licensing
> data is tricky)...so I'd expect these moves to start showing up in
> other games.
>
> For consistancy, load 'human.ac' and then 'human.bones' as a starting
> point (so all of our bones files have the same names for the various
> joints).
>
> Bones files are tiny - so please email these to me at
> <sjb...@ai...> and I'll coordinate the distribution
> of them - with appropriate accreditation.
>
> If everyone does just one or two, we'll be done in a day!
>
> ----------------------------- Steve Baker -------------------------------
> HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
> HomePage : http://web2.airmail.net/sjbaker1
> Projects : http://plib.sf.net     http://tuxaqfh.sf.net
http://tuxkart.sf.net
>            http://agtoys.sf.net   http://prettypoly.sf.net
>            http://freeglut.sf.net http://toobular.sf.net
>
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/lists/listinfo/plib-users
>

Re: [Plib-users] Need advices to use Plib for a Roam algo

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

> Maltez wrote:

> I have implemented a terrain engine with a ROAM like algo. It's all coded from scratch using
> Opengl with Glut and without a scene graph hierarchy of classes.
> I am evaluating to use a scene graph toolkit to port my engine and the add other
> functionality like sky, tree,... with Plib.
> Plib seems to be very lightweight but powerfull and let a clear access to OpenGl. Such small
> and clever thin toolkit i like.

Thank you!
 
> I'm new to Plib and i would like to have some advices to make the right (or not too wrong)
> use of Plib classes and right use of sub-classing shema.
> My current architecture is as usual : a manager class containing a grid of 10x10 tiles each
> containing 2 bintrees. The manager class refine the mesh with splits/merges when the camera
> frustrum change in a method Update(). The Render() method feeds arrays of vertices/normal/
> texcoord/colors for each tile and then draw them with a glDrawElements() call.

Seems reasonable.

> Now the dumb questions :
> - Is it correct to subclass the ssgBranch class to implement my tile manager class and
> subclass the ssgVtxArray for my tiles class ?

That would be my first guess.

> - another approach seems to use the predraw callback on a ssgBranch containing ssgVtxArray
> and doing all the work in my manager and tile classes (which will not be subclasses of ssgBranch
> and ssgVtxTable) ?

I don't like this.  You have to think about how things like collision detection (Isect and HOT)
will work.  If your node presents a standard ssgVtxTable interface then all that stuff can just
be inherited from the base class.

Also, there are other tools out there that *expect* to be able to use the callbacks and
userdata for their own purposes.

For example, if you use your first approach then it ought to be possible to model the
terrain skins using PrettyPoly.  If you take the second approach then what you have
is something that doesn't really become a part of PLIB/SSG because it doesn't subclass
from it.

> in that case how to get the frustrum i need to the cull the triangles ?

Well, the current "ssgContext" is obtainable (from within an SSG class, it would
be appropriate to use "_ssgCurrentContext") - and that contains:

   sgFrustum *ssgContext::getFrustum () ;

...or perhaps (more usefully?)...

   ssgContext::getProjectionMatrix ( sgMat4 mat ) ;

...you'll also need the current Modelview matrix (because your terrain may have been
rotated or translated) - and that is in

   ssgContext::getModelviewMatrix ( sgMat4 mat ) ;

...you should have a look at ssgContext - there are other useful things in there too.

> - i plan to share one instance of ssgVertexArray, ssgNormalArray,... for all the
>  ssgVtxArray tiles and a refresh the vertices before each draw of each tile. Is
>  there some pitfall with that ?

Think about:

  1) Multiple views of the same model, rendered consecutively. (PrettyPoly and
     my new 'Evil Overlord' project both do this).

  2) The intersection testing traversals. (3D graphics isn't *just* graphics!)

> - how to skip the culled out tile in the cull (and draw) traversal ?

  Well, if your new 'branch' node isn't in the field of view, it won't get
visited in the cull traversal - so you won't get called...that's a problem
for algorithms like ROAM that have 'memory' from one frame to the next.

  I dislike things that demand to be visited every frame - even when they
are outside the field of view because they don't "scale" well.  With the
present SSG scheme, you can easily have a scene that fills up the whole
of memory and overflows into virtual memory - because SSG generally only
has to visit the very top level nodes to be able to cull most of the
scene.

  However, one of the problems (as I understand it) with ROAM is that it
does a lot of incremental stuff (for speed) - so it needs to be run even
if it's not in view.  That may be unavoidable in this case - but we need
to think carefully about that.

> - another approach is put all in a fresh new subclass of ssgLeaf (and no
> use of ssgVtxArray or ssgBranch). What about this technic ?

You could do that...I've found that this is generally a lot more work - but
maybe not in your case.  It's important that you derive from EITHER ssgLeaf
OR ssgBranch - there is no third kind of thing allowed in the scene graph.
However, you don't need to derive from ssgVtxTable/ssgVtxArray...most applications
are quite robust in that respect.

> I would be glad to have some advices, critics or ideas to use Plib for my Roam engine.

Sure - If there is anything I can do to help...feel free to ask.

You might want to subscribe to the PLIB developer's list though - that's a better
place to ask this stuff than the user's list.

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

[Plib-users] Need advices to use Plib for a Roam algo

[Maltez <ma...@no...>]

HI
I have implemented a terrain engine with a ROAM like algo. It's all =
coded from scratch using Opengl with Glut and without a scene graph =
hierarchy of classes.
I am evaluating to use a scene graph toolkit to port my engine and the =
add other functionality like sky, tree,... with Plib.
Plib seems to be very lightweight but powerfull and let a clear access =
to OpenGl. Such small and clever thin toolkit i like.

I'm new to Plib and i would like to have some advices to make the right =
(or not too wrong) use of Plib classes and right use of sub-classing =
shema.
My current architecture is as usual : a manager class containing a grid =
of 10x10 tiles each containing 2 bintrees. The manager class refine the =
mesh with splits/merges when the camera frustrum change in a method =
Update(). The Render() method feeds arrays of =
vertices/normal/texcoord/colors for each tile and then draw them with a =
glDrawElements() call.

Now the dumb questions :
- Is it correct to subclass the ssgBranch class to implement my tile =
manager class and subclass the ssgVtxArray for my tiles class ?
- another approach seems to use the predraw callback on a ssgBranch =
containing ssgVtxArray and doing all the work in my manager and tile =
classes (which will not be subclasses of ssgBranch and ssgVtxTable) ? in =
that case how to get the frustrum i need to the cull the triangles ?
- i plan to share one instance of ssgVertexArray, ssgNormalArray,... for =
all the ssgVtxArray tiles and a refresh the vertices before each draw of =
each tile. Is there some pitfall with that ?
- how to skip the culled out tile in the cull (and draw) traversal ?
- another approach is put all in a fresh new subclass of ssgLeaf (and no =
use of ssgVtxArray or ssgBranch). What about this technic ?=20

I would be glad to have some advices, critics or ideas to use Plib for =
my Roam engine.
Thanks

[Plib-users] ExPoser help required.

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

I know from the volume of "Wow!" and "Thanks!" emails that quite a few
people are having fun playing with ExPoser.

I was wondering if people who are just playing or learning might like
to contribute some ".bones" files for the "human.ac" model that comes
with ExPoser.

My next game needs:

  * A variety of martial arts "moves" - anything that looks cool
    will do.

  * Shoot various weapons (these would be separate models - or
    added to human.ac under a switch node).

  * Walk, Run, Jump, Land(eg from a fall)

  * Climb a ladder, Swim, Ski.

  * Dive to the ground, get up again.

  * Crouch down (as to place something on the floor), get up again.

  * Rolls and gymnastic flips (as if to dodge a bullet - as if you
    actually could! :-).

  * Die (in a variety of creative ways - falling forwards, blown away
    backwards, or even slump, take a couple of steps, collapse to knees,
    say "Tis a cruel, cruel world" then fall flat on face!)

  * Anything else that you can think of. :-)

Any '.bones' files that would result would be released with 'ExPoser'
under a "do whatever you like with these" kind of a license (licensing
data is tricky)...so I'd expect these moves to start showing up in
other games.

For consistancy, load 'human.ac' and then 'human.bones' as a starting
point (so all of our bones files have the same names for the various
joints).

Bones files are tiny - so please email these to me at
<sjb...@ai...> and I'll coordinate the distribution
of them - with appropriate accreditation.

If everyone does just one or two, we'll be done in a day!

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

[Plib-users] Problem with texture path in 1.4.x

[Eric E. <Eri...@to...>]

Hello,

I tried TORCS with PLIB 1.4.1 and 1.4.2 and the
texture path management don't seem to work as before.

I use a list of relative directories separated by ';' as documented
and the ssgload is unable to find the texture files:

WARNING: ssgLoadTexture: Failed to open 'drivers/K1999/1;drivers/K1999;cars/cg-nascar-rwd/cg-nascar-rwd.rgb' for reading.

the ssgTexturePath was "drivers/K1999/1;drivers/K1999;cars/cg-nascar-rwd"
the texture name was "cg-nascar-rwd.rgb"

the real texture was "drivers/K1999/cg-nascar-rwd.rgb"

Thanks in advance for your help.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
                       TORCS
            The Open Racing Car Simulator
                 http://torcs.org
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

Re: [Plib-users] PLIB games

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

Steve Wendt wrote:
> 
> On Mon, 23 Jul 2001, Steve Baker wrote:
> 
> > That's almost certainly a long-standing Mesa bug where they don't handle
> > glPushAttrib/glPopAttrib correctly.
> 
> Bummer... this didn't happen with some old version of Mesa; was it
> re-introduced, or did something in PLIB change?

I think it comes and goes in Mesa...in striving for good performance,
the implementation of pushAttrib and popattrib is "tense" code...the
slightest thing seems to break it again.

> Any way to work around it
> for now?  I suppose if it only affects the MESA_FX version, it's not of
> much interest...

Well, certainly less of a priority than if (say) the nVidia drivers were
causing a problem!

The difficulty is that replacing glPushAttrib/glPopAttrib with something
else requires a *TON* of messy glGet* calls to get the current attributes
and a bunch of even more messy GL calls to restore them again.

All those calls will slow things down considerably - on an already slow
system.

If someone wants to contribute that as a patch that only turns on for
systems that are specifically affected, I'd be happy to accept it - but
I'm not going to write it myself.

This problem will affect some applications code as well as PLIB itself.
 
> > But you can have *BOTH*.  You should be able to run (say) a GeForce-2 and
> > the Voodoo together.  If you installed only the GeForce's OpenGL and
> 
> I know... need a whole new machine (no AGP slot).

*Oh*.  :-(

There *are* some PCI-bus GeForce cards out there - but I wouldn't recommend
them.

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

Re: [Plib-users] PLIB games

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

On Mon, 23 Jul 2001, Steve Baker wrote:

> That's almost certainly a long-standing Mesa bug where they don't handle
> glPushAttrib/glPopAttrib correctly.

Bummer... this didn't happen with some old version of Mesa; was it
re-introduced, or did something in PLIB change?  Any way to work around it
for now?  I suppose if it only affects the MESA_FX version, it's not of
much interest...

> But you can have *BOTH*.  You should be able to run (say) a GeForce-2 and
> the Voodoo together.  If you installed only the GeForce's OpenGL and

I know... need a whole new machine (no AGP slot).

Re: [Plib-users] PLIB games

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

Steve Wendt wrote:
> 
> On Mon, 23 Jul 2001 02:29:32 -0500, Steve Baker wrote:
> 
> >What's doubly weird is that this only happens to RedHat 7.x users.
> 
> Reverting to Mesa 3.4.2, and updating PLIB to 1.4.2, TuxKart to 0.0.6, and
> Tux:AQFH to 1.0.13, all of the problems I reported went away.  I don't think
> any of the problems had to do with the distro.  Anyway, the only problem I
> still have is that in Tux:AQFH, when I hit Space bar, the menus appear, but
> all of the scene goes black (overlaid graphics still appear though).  Any clues
> on that?

That's almost certainly a long-standing Mesa bug where they don't handle
glPushAttrib/glPopAttrib correctly.

> >Voodoo-2 is pretty old (and VERY strange) hardware.  It's *definitely* time to
> >upgrade!
> 
> Yeah, I know.  But I still have some stuff that uses glide.  :)

But you can have *BOTH*.  You should be able to run (say) a GeForce-2 and
the Voodoo together.  If you installed only the GeForce's OpenGL and
ripped out Mesa altogether - then all OpenGL progs would drive the GeForce,
but GLIDE programs would still activate the Voodoo card and shut off the video
from the GeForce - just like it currently shuts off the video from your 2D card.

You'd get the best of both worlds!

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

[Plib-users] PLIB 1.5.1 SNAFU.

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

I noticed that someone forgot to add ssgLoadVRML.h into the libplibssg_a_SOURCES
list.  Hence PLIB 1.5.1 won't build (I'm amazed nobody else found that yet!).

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

Re: [Plib-users] PLIB games

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

On Mon, 23 Jul 2001 02:29:32 -0500, Steve Baker wrote:

>What's doubly weird is that this only happens to RedHat 7.x users.

Reverting to Mesa 3.4.2, and updating PLIB to 1.4.2, TuxKart to 0.0.6, and 
Tux:AQFH to 1.0.13, all of the problems I reported went away.  I don't think
any of the problems had to do with the distro.  Anyway, the only problem I 
still have is that in Tux:AQFH, when I hit Space bar, the menus appear, but
all of the scene goes black (overlaid graphics still appear though).  Any clues
on that?

>Voodoo-2 is pretty old (and VERY strange) hardware.  It's *definitely* time to 
>upgrade!

Yeah, I know.  But I still have some stuff that uses glide.  :)


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