plib-devel

[Plib-devel] ASE import/export

[Dave M. <dp...@ef...>]

I have finished my ASE import/export module for PLIB and also a generic parser and error handler for use in other import/export modules.

however, i'm having trouble using cvs on sourceforge.  i'm getting authorization failed messages.  i'm a cvs newbie.  i read the cvs howto and faqs but still having trouble.  could someone send me their cvs scripts/commands for login sans password?

Thanks,
--Dave

Re: [Plib-devel] OBJ loader for ssg

[Dave M. <dp...@ef...>]

Bill Weiland wrote:

> The topic of loaders seems to be on everyone's mind.  At the moment, I'm working on a quick turnaround effort that would really be helped by having a Wavefront OBJ loader, and I'm thinking of building one, but I'm a bit nervous about my current superficial understanding of ssg and the ssgVtxTable node.  Does anyone have even a crude OBJ loader that they'd be willing to share?  Any advice?

There is a Wavefront OBJ import & export routine in IVCON.c
( http://www.psc.edu/~burkardt/ivcon.html )

The crystal space project used the IVCON module to get their import/export formats up and running and have added to them.

> Also, just for the record, a good, highly functional VRML2/97 loader (with PROTO's) would be a great thing (even better than the OBJ loader for me, but it's a bit of a reach given my time frame).

I'm currently trying to finish up my ASE import/export but after that I may try to write a VRML 1.0 ascii import.

--Dave

[Plib-devel] Problems with nVidia/TNT drivers.

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

I saw this posted to the Mesa mailing list.

Perhaps it will be of some help to various people
who have been posting complaints about 3D performance
under Linux when using nVidia hardware such as TNT and
TNT2.

It's certainly been my understanding that the older drivers
worked MUCH better than the more recent ones.

> ---------- Forwarded message ----------
> Date: Fri, 18 Feb 2000 14:18:14 -0800
> From: "Shaul, Frederick" <fre...@in...>
> Subject: RE: [mesa] Problems with nvidia-glx.src (+ glquake.glx)
> 
> There have been a lot of reports of bugs with the latest NVIDIA drivers.  An
> excellent resource for understanding what does work is
> http://www.lokigames.com/support/gldrivers/
> 
> They have NVIDIA's classic GLX driver available for download.  This driver
> may not have the latest bleeding edge speed, but it seem quite stable on
> TNT2 to me.
> 
> - Frederick Shaul
>   Linux 3D Graphics Projects
>   MGL - Parallel Prototypes and Demos
>   Intel Microprocessor Research Lab

Thanks Loki - You guys *rule*.  :-)

Re: [Plib-devel] OBJ loader for ssg

[Curtis L. O. <cu...@me...>]

Bill Weiland writes:
> The topic of loaders seems to be on everyone's mind.  At the moment,
> I'm working on a quick turnaround effort that would really be helped
> by having a Wavefront OBJ loader, and I'm thinking of building one,
> but I'm a bit nervous about my current superficial understanding of
> ssg and the ssgVtxTable node.  Does anyone have even a crude OBJ
> loader that they'd be willing to share?  Any advice? 

The flight gear project has a loader for a format that is a very small
subset of obj (plus a couple extensions.)  It outputs ssgVtxTables.
You'd likely have to hack it up quite a bit to make it do anything
useful to you, but it might make for a reasonable starting point.

Feel free to email me offline if you'd like more details:

    cu...@fl...

Regards,

Curt.
-- 
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

[Plib-devel] OBJ loader for ssg

[Bill W. <bil...@ch...>]

Hi all:

The topic of loaders seems to be on everyone's mind.  At the moment, I'm working on a quick turnaround effort that would really be helped by having a Wavefront OBJ loader, and I'm thinking of building one, but I'm a bit nervous about my current superficial understanding of ssg and the ssgVtxTable node.  Does anyone have even a crude OBJ loader that they'd be willing to share?  Any advice?

Also, just for the record, a good, highly functional VRML2/97 loader (with PROTO's) would be a great thing (even better than the OBJ loader for me, but it's a bit of a reach given my time frame).

Bill Weiland

Re: [Plib-devel] MDL loader for plib ssg

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

Charles McLachlan wrote:
> 
> On Mon, 21 Feb 2000, you wrote:
> > This MDL isn't the MDL that Moray (a PovRay modeller) uses, is it?
> 
> It's the MDL that Quake uses which may well have been adopted by others. It
> seems to be quite a nice format and Nathaniel's loader makes it into a nice,
> easily convertable, C++ object.

OK, then I really doubt that that'll be the same file format.

CU,
Christian

Re: [Plib-devel] MDL loader for plib ssg

[Charles M. <ci...@uk...>]

On Mon, 21 Feb 2000, you wrote:
> This MDL isn't the MDL that Moray (a PovRay modeller) uses, is it?

It's the MDL that Quake uses which may well have been adopted by others. It
seems to be quite a nice format and Nathaniel's loader makes it into a nice,
easily convertable, C++ object.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Charlie McLachlan 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Re: [Plib-devel] MDL loader for plib ssg

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

Charles McLachlan wrote:

> I'm considering implementing an MDL / MDL2 loader based on Nathaniel Saint
> Martin's Crystal Space loader. (This email copied to him in case he has any
> comments)

This MDL isn't the MDL that Moray (a PovRay modeller) uses, is it?

> Is anybody working on such a thing already?

No, don't think so.

CU,
Christian

[Plib-devel] MDL loader for plib ssg

[Charles M. <ci...@uk...>]

I'm considering implementing an MDL / MDL2 loader based on Nathaniel Saint
Martin's Crystal Space loader. (This email copied to him in case he has any
comments) 

Is anybody working on such a thing already? 

Presumably all I want to do is write an ssgLoadMDL.cxx file and put an extra
line in ssgLoad()

BTW, I've just CVS'd the latest plib off Source forge, ran autoconf to get
myself a configure script, then ran it, only to get a complaint about a missing
install.sh file.

Am I doing this wrong or has install.sh been missed somewhere along the line? 

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Charlie McLachlan 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Re: [Plib-devel] ssgVtxTable question

[Curtis L. O. <cu...@me...>]

Steve Baker writes:
> Yes - but I need it sometimes when I have two copies of the same
> object - but rendered in different colours (or - I guess - with
> different texture coordinates - or a different ssgState).
> 
> Also, the reference counting thing meant that feature came "for free".

Ok, fair enough ... I hadn't thought about replacing one of the arrays
to change the object slightly.

Regards,

Curt.
-- 
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] ssgVtxTable question

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

"Curtis L. Olson" wrote:
> 
> Steve Baker writes:
> > The arrays are reference counted - so you can use the same array
> > for multiple VtxTables and they'll be deleted only when they are
> > no longer needed.
> 
> I'm having trouble thinking of a case where this would be useful.  You
> can't specify alternate indices into these arrays, so wouldn't you end
> up with duplicate objects?  And if you want a duplicate object,
> wouldn't it be simpler just to connect the same node into the graph
> multiple times?

Yes - but I need it sometimes when I have two copies of the same
object - but rendered in different colours (or - I guess - with
different texture coordinates - or a different ssgState).

Also, the reference counting thing meant that feature came "for free".

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

Re: [Plib-devel] ssgVtxTable question

[Curtis L. O. <cu...@in...>]

Steve Baker writes:
> The arrays are reference counted - so you can use the same array
> for multiple VtxTables and they'll be deleted only when they are
> no longer needed.

I'm having trouble thinking of a case where this would be useful.  You
can't specify alternate indices into these arrays, so wouldn't you end
up with duplicate objects?  And if you want a duplicate object,
wouldn't it be simpler just to connect the same node into the graph
multiple times?

Regards,

Curt.
--
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] ssgVtxTable question

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

"Curtis L. Olson" wrote:

> I was taking a quick look at the new ssgVtxTable's tonight and trying
> to get a feel for how they work.  As I understand it, these take care
> of freeing up the memory used by the arrays fed to it, correct?

Yes - that was the main change I wanted to effect.

> I just want to double check to make sure I'm understanding this.

Yep.

> So in my application I can do something like:
> 
> for each structure {
>   ssgVertexArray *vl = new ssgVertexArray;
>   ssgNormalArray *nl = new ssgNormalArray;
>   ...
> 
>   // fill in these structures with my data
> 
>   ssgVtxTable( GL_WHATEVER, vl, nl, ... );
> }

Yes.
 
> So from the calling application I can just allocate all the arrays I
> need, hand them to ssgVtxTable, and completely forget about them after
> that, right?  ssg will free up the memory when the node is removed,
> right?

Right.

The arrays are reference counted - so you can use the same array
for multiple VtxTables and they'll be deleted only when they are
no longer needed.

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

[Plib-devel] ssgVtxTable question

[Curtis L. O. <cu...@in...>]

Steve,

I was taking a quick look at the new ssgVtxTable's tonight and trying
to get a feel for how they work.  As I understand it, these take care
of freeing up the memory used by the arrays fed to it, correct?  I
just want to double check to make sure I'm understanding this.

So in my application I can do something like:

for each structure {
  ssgVertexArray *vl = new ssgVertexArray;
  ssgNormalArray *nl = new ssgNormalArray;
  ...

  // fill in these structures with my data

  ssgVtxTable( GL_WHATEVER, vl, nl, ... );
}

So from the calling application I can just allocate all the arrays I
need, hand them to ssgVtxTable, and completely forget about them after
that, right?  ssg will free up the memory when the node is removed,
right?

Thanks,

Curt.
-- 
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

R: [Plib-devel] ssgVtxTable and SSG Import/Export modules

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

Steve Baker wrote:

> Well, I guess this is a case for dynamic linking. DSO's under Linux
> and DLL's under Windoze.   Step #1 will be to write a portable
> dynamic linker wrapper.

GNU Libtool should do that (http://www.gnu.org/software/libtool/libtool.html).

Regards -

Paolo

Re: [Plib-devel] ssgVtxTable and SSG Import/Export modules

[Joel U. <joe...@ya...>]

Dave McClurg wrote:

> I'd like to incorporate most of IVCON (http://www.psc.edu/~burkardt/ivcon.html)
> into SSG.  Would that be a good thing?

That would be a _Great_ thing.

Bye - Joel.

RE: [Plib-devel] SL playMusic() callbacks don't work

[Vallevand, M. K <Mar...@UN...>]

I've tried this in two places...

In my game it didn't work.  So, I fixed up the mod test program
that comes with the PLIB docs.  I just added a simple callback
that prints "got here" and changed the loopMusic call.  It never
"gets here".  The same code in my game for samples works.  I
also fixed up the playSample demo and it "gets here".

It was too late last night to debug PLIB, so I thought I'd ask
today.

Regards.
Mark K Vallevand   ma...@rs...
Outside of a dog, a book is man's best friend.
 Inside of a dog, its too dark to read.  - Groucho


> -----Original Message-----
> From: Steve Baker [mailto:sjb...@ai...]
> Sent: Thursday, February 17, 2000 1:44 PM
> To: pli...@li...
> Subject: Re: [Plib-devel] SL playMusic() callbacks don't work
> 
> 
> "Vallevand, Mark K" wrote:
> > 
> > The playMusic() in slScheduler allows a callback to be specified,
> > but the callback is never called.  Is this a known restriction?
> 
> No - it should work.  I looked (briefly) at the code and the
> callback is actually passed down to the lower level slPlayer
> class.  That's the common base class for MOD music and sound
> effects - and I *know* the sound effects callbacks work because
> I've used them.
> 
> It's possible that this has never been tested though - I probably
> just assumed that the base class would handle it - and for some
> reason it can't.  I can't think of any code that I've written
> that didn't simply set the music track to loop indefinitely
> until I decide to tell it to stop.
> 
> You have tried this and know it doesn't work or were you
> just looking at the sources and wondering when it gets
> called?
> 
> If so then you've found a bug and I'll have to go and track
> it down because this is important functionality.
> 
> -- 
> Steve Baker                  http://web2.airmail.net/sjbaker1
> sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
> sj...@ht...      (work)
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

Re: [Plib-devel] ssgVtxTable and SSG Import/Export modules

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

Dave McClurg wrote:

> >The lack of import/export functions in the past blinded me to the
> >need to do this - but with PPE demanding lots of these, it's
> >starting to make sense.
> 
> I believe that CrystalSpace has a SCF (shared class facility) that is
> portable and handles DLL or SO files.  It is their second attempt at
> implementing a portable wrapper and they are happy with it.

Hmmm - it doesn't sound hard (at least for Windoze and Linux/UNIX).
Dunno what's entailed on getting a MacOS version going though.
 
> For now, I'll just add import/export functions into SSG proper.

Yes.  It won't be hard to retro-fit a DLL/DSO loader-manager after
these loaders are written.  Right now, let's concentrate on the
urgent task of getting the loaders done.

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

RE: Re: [Plib-devel] ssgVtxTable and SSG Import/Export modules

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

Dave McClurg writes:
>
>>> I'd like to incorporate most of IVCON 
>(http://www.psc.edu/~burkardt/ivcon.html)
>>> into SSG.  Would that be a good thing?

I think so.

Norman

Re: Re: [Plib-devel] ssgVtxTable and SSG Import/Export modules

[Dave M. <dp...@ef...>]

>> I'd like to incorporate most of IVCON (http://www.psc.edu/~burkardt/ivcon.html)
>> into SSG.  Would that be a good thing?
>> 
>> Before these import/export modules bloat out SSG,
>> what type of wrapper should we use?
>> Should import/export modules just be linked in or should we have
>> a more formal plugin type of arrangement?
>
>Well, I guess this is a case for dynamic linking. DSO's under Linux
>and DLL's under Windoze.   Step #1 will be to write a portable
>dynamic linker wrapper.
>
>The lack of import/export functions in the past blinded me to the
>need to do this - but with PPE demanding lots of these, it's
>starting to make sense.
>

I believe that CrystalSpace has a SCF (shared class facility) that is
portable and handles DLL or SO files.  It is their second attempt at
implementing a portable wrapper and they are happy with it.

For now, I'll just add import/export functions into SSG proper.

Re: [Plib-devel] SL playMusic() callbacks don't work

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

"Vallevand, Mark K" wrote:
> 
> The playMusic() in slScheduler allows a callback to be specified,
> but the callback is never called.  Is this a known restriction?

No - it should work.  I looked (briefly) at the code and the
callback is actually passed down to the lower level slPlayer
class.  That's the common base class for MOD music and sound
effects - and I *know* the sound effects callbacks work because
I've used them.

It's possible that this has never been tested though - I probably
just assumed that the base class would handle it - and for some
reason it can't.  I can't think of any code that I've written
that didn't simply set the music track to loop indefinitely
until I decide to tell it to stop.

You have tried this and know it doesn't work or were you
just looking at the sources and wondering when it gets
called?

If so then you've found a bug and I'll have to go and track
it down because this is important functionality.

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

Re: [Plib-devel] ssgVtxTable and SSG Import/Export modules

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

Dave McClurg wrote:
> 
> Could we add an optional index array to ssgVtxTable so that a CUBE takes
> 8 vertices and not 36 vertices (with GL_TRIANGLES) ?

Well, hopefully you'd use two GL_TRIANGLE_STRIPs (just 16 vertices) or
two GL_TRIANGLE_FAN's (only 14 vertices) - but your point is a valid one.

> Or is there a reason for not doing so?

There is good reason to develop another ssgLeaf class that can do that - but
I'd like to keep ssgVtxTable the way it is right now because it's the fastest
for simple glBegin/glVertex.../glEnd rendering. But I want to build new leaf
nodes that are more appropriate for compiled vertex arrays - which are the
fastest way to render stuff under most PC-based systems. 

It's really just a matter of my time for doing this stuff.

I also need to think about how to deal with multi-texture (which entails
multiple glTexCoord arrays) and glTexGen (which uses a mapping "rule"
instead of texture coordinates.

In each case, a class derived from ssgLeaf will be the way to go.

> I'd like to incorporate most of IVCON (http://www.psc.edu/~burkardt/ivcon.html)
> into SSG.  Would that be a good thing?
> 
> Before these import/export modules bloat out SSG,
> what type of wrapper should we use?
> Should import/export modules just be linked in or should we have
> a more formal plugin type of arrangement?

Well, I guess this is a case for dynamic linking. DSO's under Linux
and DLL's under Windoze.   Step #1 will be to write a portable
dynamic linker wrapper.

The lack of import/export functions in the past blinded me to the
need to do this - but with PPE demanding lots of these, it's
starting to make sense.

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

[Plib-devel] SL playMusic() callbacks don't work

[Vallevand, M. K <Mar...@UN...>]

The playMusic() in slScheduler allows a callback to be specified,
but the callback is never called.  Is this a known restriction?

Regards.
Mark K Vallevand   ma...@rs...
Outside of a dog, a book is man's best friend.
 Inside of a dog, its too dark to read.  - Groucho

[Plib-devel] ssgVtxTable and SSG Import/Export modules

[Dave M. <dp...@ef...>]

Could we add an optional index array to ssgVtxTable so that a CUBE takes
8 vertices and not 36 vertices (with GL_TRIANGLES) ?
Or is there a reason for not doing so?

I'd like to incorporate most of IVCON (http://www.psc.edu/~burkardt/ivcon.html)
into SSG.  Would that be a good thing?

Before these import/export modules bloat out SSG,
what type of wrapper should we use?
Should import/export modules just be linked in or should we have
a more formal plugin type of arrangement?
Any suggestions?

--Dave

Re: [Plib-devel] ssgLoadVRML and model loaders in general

[Joel U. <joe...@ya...>]

Dave McClurg wrote:

> my current effort is ssgLoadASE.  I'm thinking of writing a
> ssgModelLoader class similar to ssgImageLoader so that you don't have to
> call the specific load routine for the file.  Also, that will let me
> share some common code between the model loaders.  hope that is ok.

I would like this myself, and I think it would help new model format
writers do their job.

Bye - Joel.