plib-devel

Re: Re: [plib-devel] ASE load/save

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

>> Using the save.cxx SSG example with loading the tuxedo.ac and saving it
>> then as tuxedo.ase I get
>> 
>> ...
>> *MATERIAL_AMBIENT -431602080.000000 -431602080.000000 -431602080.000000
>> *MATERIAL_DIFFUSE -431602080.000000 -431602080.000000 -431602080.000000
>> ...
>> 
>> in all materials. This doesn't lok right (it looks like some unitialized
>> floats). Is that correct?
>
>Doesn't look good to me - I think the problem is rather subtle.  Those
>certainly are uninitialised variables - but I think the REASON is that
>the ssgState probably had those colours set with a "don't care" flag -
>implying that the ambient and diffuse colours are coming from the
>polygon colour (using glColorMaterial) - meaning that those colours
>are just plain WRONG.
>
>What the correct fix is - I'm not sure - depends on the ASE file format.

ASE supports vertex colors and ssgLoadASE passes them to ssgVtxTable
if they are found.  But vertex colors are optional and may not be present.

So... is a fix needed and if so what should be done?

Re: [Plib-devel] PLIB/PPE loaders/writers

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

Dave McClurg wrote:
> 
> Steve Wrote:
> 
> >I agree about VRML - VRML-1 was a great disappointment to me - VRML-2/97
> >made it all a lot worse.  However, it is the ONLY independent standard
> >format that I can think of - and it is pretty widely supported as an
> >import/export format.  Every other format on the planet is based
> >on the native format of some specific toolkit or modeller (AFAIK).
> >
> >Of course VRML-1 was essentially just SGI's Inventor '.iv' native
> >format...so in that sense, it too is just the native format of an
> >existing tool.
> >
> 
> Nichimen has something called the "game exchange" format.
> We should support that (http://www.nichimen.com/gamex/index.shtml)
> 

Something also should consider is supporting the X format - the native
Direct3D format... perhaps in a one way direction only ;-) 

CU,
Christian

Re: [Plib-devel] LoadASE problem.

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

Dave McClurg wrote:
> 
> Christian wrote:
> 
> >I tried to compile a new plib checkout, but MSVC complaind about a few
> >parts in the ASE load/save routines
> 
> Thanks for checking this out.  I added the fixed to other changes i'm making.
> I noticed the plib.dsw/dsp in CVS is missing the new files and ssgContext.cxx.
> i'll send Steve the changes for a commit later today

Yes - I don't posess a single byte of Microsoft software - so I can't maintain
the MSVC build setup...or any other non-Makefile-based scheme for that
matter.

However, if someone wants to send me those project files, I'll be happy
to commit them.

> >Using the save.cxx SSG example with loading the tuxedo.ac and saving it
> >then as tuxedo.ase I get
> >
> >*MATERIAL_AMBIENT -431602080.000000 -431602080.000000 -431602080.000000
> >*MATERIAL_DIFFUSE -431602080.000000 -431602080.000000 -431602080.000000
> >
> >in all materials. This doesn't lok right (it looks like some unitialized
> >floats). Is that correct?
> >
> 
> correct.  AC format specifies rgb,amb,emis,and spec where as ASE specifies amb,diff,spec.

Emission isn't used much anyway - most of the time it's just
easier to disable GL_LIGHTING - which has much the same effect.

> ssgLoadAC does this:
> 
>   st -> setMaterial ( GL_SPECULAR, mat -> spec ) ;
>   st -> setMaterial ( GL_EMISSION, mat -> emis ) ;
> 
> and ssgLoadASE does this:
> 
>   st -> setMaterial ( GL_AMBIENT, mat -> amb ) ;
>   st -> setMaterial ( GL_DIFFUSE, mat -> diff ) ;
>   st -> setMaterial ( GL_SPECULAR, mat -> spec ) ;
> 
> therefore, when you load AC and save ASE you get undefined amb and diff.
> before i fix this, i'd like to understand it more fully.  anyone want to comment on
> how the state should be initialized for unknown properties?

It's messy because of glColorMaterial.

Personally, my application software sets glColorMaterial to pick up the
diffuse/ambient colours from the glColor() call and I totally ignore
the emission/specular from the file - forcing them to black and white
respectively.

Added to which, I code the entire ssgSimpleState into the application and
use the texture map name from the model file to find the material in the
application.

This means that I can't just pick up any random model off the web and
toss it (unmodified) into my game - but that's a pretty silly thing
to expect anyway.  Games have to manage how much texture they consume
and stuff like that - so anything more complex than the very simplest
game will need to do something similar to this.

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

Re: Re: [Plib-devel] PLIB/PPE loaders/writers

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

Steve Wrote:

>I agree about VRML - VRML-1 was a great disappointment to me - VRML-2/97
>made it all a lot worse.  However, it is the ONLY independent standard
>format that I can think of - and it is pretty widely supported as an
>import/export format.  Every other format on the planet is based
>on the native format of some specific toolkit or modeller (AFAIK).
>
>Of course VRML-1 was essentially just SGI's Inventor '.iv' native
>format...so in that sense, it too is just the native format of an
>existing tool.
>

Nichimen has something called the "game exchange" format.
We should support that (http://www.nichimen.com/gamex/index.shtml)
The documentation is nice and it seems like they are trying to create
a standard.  Nendo is the best IMO "cheap" modeler I know of.
If nobody wants to do that import/export module, i'll get to it.

--Dave McClurg

Re: [Plib-devel] PLIB/PPE loaders/writers

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

Devrim Erdem wrote:
> 
> > I don't think it would be hard to write a large pile of #define's
> > to make SSG look like Performer (at least to the degree needed by
> > Performer's loaders).
> >
> > #define pfGroup  ssgBranck
> > #define addChild addKid
> >
> > ...and so on.  There are 'political' reasons why I'll never do
> > this - but someone else could easily do so.
> 
> Unfortunately source code for the most important loader OpenFlight ( in my opinion ) lacks. I don't beileve that other formats ( 3ds, obj etc ) would
> work like OpenFlight. And VRML is a neverending story.

We dumped the OpenFLight loader and wrote our own - but I can't opensource it.

At one time, there were TWO OpenFlight loaders - one was from Multigen
and the other was from the Performer team themselves.  Once Multigen put
effort into their (binary-only) loader, the Performer team seem to have
stopped working on theirs - but it was released as source code at one
stage.

I agree about VRML - VRML-1 was a great disappointment to me - VRML-2/97
made it all a lot worse.  However, it is the ONLY independent standard
format that I can think of - and it is pretty widely supported as an
import/export format.  Every other format on the planet is based
on the native format of some specific toolkit or modeller (AFAIK).

Of course VRML-1 was essentially just SGI's Inventor '.iv' native
format...so in that sense, it too is just the native format of an
existing tool.

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

Re: Re: [Plib-devel] LoadASE problem.

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

Christian wrote:

>I tried to compile a new plib checkout, but MSVC complaind about a few
>parts in the ASE load/save routines

Thanks for checking this out.  I added the fixed to other changes i'm making.
I noticed the plib.dsw/dsp in CVS is missing the new files and ssgContext.cxx.
i'll send Steve the changes for a commit later today

>Using the save.cxx SSG example with loading the tuxedo.ac and saving it
>then as tuxedo.ase I get
>
>*MATERIAL_AMBIENT -431602080.000000 -431602080.000000 -431602080.000000
>*MATERIAL_DIFFUSE -431602080.000000 -431602080.000000 -431602080.000000
>
>in all materials. This doesn't lok right (it looks like some unitialized
>floats). Is that correct?
>

correct.  AC format specifies rgb,amb,emis,and spec where as ASE specifies amb,diff,spec.
ssgLoadAC does this:

  st -> setMaterial ( GL_SPECULAR, mat -> spec ) ;
  st -> setMaterial ( GL_EMISSION, mat -> emis ) ;

and ssgLoadASE does this:

  st -> setMaterial ( GL_AMBIENT, mat -> amb ) ;
  st -> setMaterial ( GL_DIFFUSE, mat -> diff ) ;
  st -> setMaterial ( GL_SPECULAR, mat -> spec ) ;

therefore, when you load AC and save ASE you get undefined amb and diff.
before i fix this, i'd like to understand it more fully.  anyone want to comment on
how the state should be initialized for unknown properties?

thanks,
--Dave

Re: [Plib-devel] LoadASE problem.

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

Dave McClurg wrote:
> 
> attached virtual file system proposal (similar to CS vfs)
> 

Looks good.

PLIB really needs an OS independant file and *directory* handling!

CU,
Christian

Re: [Plib-devel] LoadASE problem.

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

attached virtual file system proposal (similar to CS vfs)

--Dave

Re: [Plib-devel] LoadASE problem.

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

Steve Wrote :

>  Your ssgParser/ssgLoadASE/ssgSaveASE code is a bit brutal when
>it finds an error.  If I try to load or save a file that does not
>exist, it does an 'exit(1)'!!! Eeeekkkk!
>
>  That's kinda brutal when you've just spent 3 hours building a
>model in PPE - and when you try to save it and accidentally open
>a write-protected file or a non-existant directory *KABLOOIE*!!!
>
>  Please have ssgLoadASE return NULL if it can't load a file
>for *any* reason - and have ssgSaveASE return FALSE if it can't
>save.
>
>  This is kinda urgent!
>

understood. i'll work on that today

>  Also, the _ssgMakePath function chops off the leading path
>information or something...we need ssgModelPath to be applied
>consistantly across all loaders.  What ssgLoadAC does is:
>
>  * If the path starts with a slash - use it as-is.
>  * If the path starts with anything else, prepend _ssgModelPath
>    and a slash.
>
>  I'm not sure if that's the *perfect* rule - but it's what existing
>applications expect.
>
 
this is an argument for the file system wrapper
different OSes use different seperators and also i get ASE files
with texture names that all start with backslashes and i don't want
to recreate the directory structure on the modeler's machine.

i'm attaching a spec proposal for a PLIB virtual file system.  It is very similar
to what is used in crystal space.  Feedback?

--Dave

Re: [Plib-devel] LoadASE problem.

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

> Steve Baker wrote:
> > 
> >   Also, the _ssgMakePath function chops off the leading path
> > information or something...we need ssgModelPath to be applied
> > consistantly across all loaders.  What ssgLoadAC does is:
> > 
> >   * If the path starts with a slash - use it as-is.
> >   * If the path starts with anything else, prepend _ssgModelPath
> >     and a slash.
> > 
> >   I'm not sure if that's the *perfect* rule - but it's what existing
> > applications expect.

Steve, does ssg and it's loaders consider MacOS paths that use ":" as
their delimeters?

BTW, does anyone know what affect MacOS X (bsd unix based) will have
on future path delimiter and ascii line delimiter choices on the mac
platform?

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] LoadASE problem.

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

Steve Baker wrote:
> 
>   Also, the _ssgMakePath function chops off the leading path
> information or something...we need ssgModelPath to be applied
> consistantly across all loaders.  What ssgLoadAC does is:
> 
>   * If the path starts with a slash - use it as-is.
>   * If the path starts with anything else, prepend _ssgModelPath
>     and a slash.
> 
>   I'm not sure if that's the *perfect* rule - but it's what existing
> applications expect.

It's definitely not perfect. If I want to load
c:\project\my_game\model.ssg but my path is set to d:\files\3d_models\ I
get a big problem as d:\files\3d_models\c:\project\my_game\model.ssg
doesn't exist.

Couldn't we feed the loader with the whole absolute path and the loader
gets all the files from the dir that the specified file is in? Perhaps
we need a texture modifier. 

(Hypothetic) Example:
Texture modifier is: '../textures'
Path is:             'd:/files/3d_models/objects/model.ssg'

This would load the model

d:/files/3d_models/objects/model.ssg

and the the textures

d:/files/3d_models/textures/model_texture_0.rgb
d:/files/3d_models/textures/model_texture_1.png
d:/files/3d_models/textures/model_texture_2.rgb

CU,
Christian

Re: [Plib-devel] PLIB/PPE loaders/writers - Authors README!

[Devrim E. <de...@in...>]

> I don't think it would be hard to write a large pile of #define's
> to make SSG look like Performer (at least to the degree needed by
> Performer's loaders).
>
> #define pfGroup  ssgBranck
> #define addChild addKid
>
> ...and so on.  There are 'political' reasons why I'll never do
> this - but someone else could easily do so.

Unfortunately source code for the most important loader OpenFlight ( in my opinion ) lacks. I don't beileve that other formats ( 3ds, obj etc ) would
work like OpenFlight. And VRML is a neverending story.

/*===============================================
M. Devrim Erdem            de...@in...
                  Simulation Software Development
                              info(+)TRON, Turkey
Tel: +90 216 4921002
Fax: +90 216 3432132
Http://www.infotron-tr.com
Http://abone.turk.net/mderdem
===============================================*/

[Plib-devel] LoadASE problem.

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

Dave:

  Your ssgParser/ssgLoadASE/ssgSaveASE code is a bit brutal when
it finds an error.  If I try to load or save a file that does not
exist, it does an 'exit(1)'!!! Eeeekkkk!

  That's kinda brutal when you've just spent 3 hours building a
model in PPE - and when you try to save it and accidentally open
a write-protected file or a non-existant directory *KABLOOIE*!!!

  Please have ssgLoadASE return NULL if it can't load a file
for *any* reason - and have ssgSaveASE return FALSE if it can't
save.

  This is kinda urgent!

  Also, the _ssgMakePath function chops off the leading path
information or something...we need ssgModelPath to be applied
consistantly across all loaders.  What ssgLoadAC does is:

  * If the path starts with a slash - use it as-is.
  * If the path starts with anything else, prepend _ssgModelPath
    and a slash.

  I'm not sure if that's the *perfect* rule - but it's what existing
applications expect.
 
-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

[Plib-devel] New ASE loader/saver.

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

FYI:  The latest CVS version of PLIB contains Dave McClurg's ASE loader
and saver.  PPE users should find it "just works" - for other programs,
if you use the new ssgLoad and ssgSave routines then you'll get ASE
formats without changing your code at all - if you load or save files
by type explicitly then 'ssgLoadASE' and 'ssgSaveASE' work just like
all the other loaders/writers.

Dave tells me that the ssgParser.cxx/h should be useful to other loader
writers - I havn't looked at it yet.

He also says:

> The only thing remaining for ase support is key/mesh
> animation but any model should load (sans animation).

This is great news for PPE.

The bad news is that this is a pretty significant addition, and
I should probably make a new 1.1.xx series release of PLIB before
going to a stable 1.2.0 version...this is too good to leave out
of 1.2.

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

Re: [Plib-devel] PLIB/PPE loaders/writers - Authors README!

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

Devrim Erdem wrote:
> 
> Steve Baker wrote:
> 
> > Devrim Erdem wrote:
> >
> > > Steve, I have discontinued my effort to build a link between performer scene graph
> > > and ssg scene graph due to the problems in ssgSaveSSG. I may restart it soon, if I
> > > feel that there is a need.
> >
> > I'm not aware of any current problems with the latest ssgSaveSSG - what's up now?
> 
> I haven't compiled ssg for a while. I will check it soon. The bad thing about this sort of tool
> is that user has to have a properly installed performer. The good thing is that performer loads
> nearly everything and so ssg by this way.

You get source code for the Performer loaders though.

I don't think it would be hard to write a large pile of #define's
to make SSG look like Performer (at least to the degree needed by
Performer's loaders).


#define pfGroup  ssgBranck
#define addChild addKid

...and so on.  There are 'political' reasons why I'll never do
this - but someone else could easily do so.

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

Re: [Plib-devel] PLIB/PPE loaders/writers - Authors README!

[Devrim E. <de...@in...>]

Steve Baker wrote:

> Devrim Erdem wrote:
>
> > Steve, I have discontinued my effort to build a link between performer scene graph
> > and ssg scene graph due to the problems in ssgSaveSSG. I may restart it soon, if I
> > feel that there is a need.
>
> I'm not aware of any current problems with the latest ssgSaveSSG - what's up now?

I haven't compiled ssg for a while. I will check it soon. The bad thing about this sort of tool
is that user has to have a properly installed performer. The good thing is that performer loads
nearly everything and so ssg by this way.

--
/*===============================================
M. Devrim Erdem            de...@in...
                  Simulation Software Development
                              info(+)TRON, Turkey
Tel: +90 216 4921002
Fax: +90 216 3432132
Http://www.infotron-tr.com
Http://abone.turk.net/mderdem
===============================================*/

Re: [Plib-devel] PLIB/PPE loaders/writers - Authors README!

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

Devrim Erdem wrote:

> Steve, I have discontinued my effort to build a link between performer scene graph
> and ssg scene graph due to the problems in ssgSaveSSG. I may restart it soon, if I
> feel that there is a need.

I'm not aware of any current problems with the latest ssgSaveSSG - what's up now?

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

Re: [Plib-devel] PLIB/PPE loaders/writers - Authors README!

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

Steve Baker wrote:
> 
> OK, OK!  My head is spinning.

Why's your head spinning? Your whole body should spin due to the joy
dances(??) you are performing... :-)

> ...so - someone help me fill in the blanks!  If you are only
> "thinking about" writing a loader/writer rather than "definitely"
> writing one, let me know that too.

.pov: Author: Christian Mayer
      IMPORT Status: never - considered impossible
      EXPORT Status: started, but currently on hold while I'm trying
                     to figure out how to write a writer for SSG as
                     the example code that I used didn't work.
      Description:   PovRay is a well known freeware raytracer.
      Note:          You'll probably need at least MegaPov or the yet
                     to come PovRay 3.5 (=> I'll use mesh2)

Re: [Plib-devel] PLIB/PPE loaders/writers - Authors README!

[Devrim E. <de...@in...>]

>

Steve, I have discontinued my effort to build a link between performer scene graph
and ssg scene graph due to the problems in ssgSaveSSG. I may restart it soon, if I
feel that there is a need.

--
/*===============================================
M. Devrim Erdem            de...@in...
                  Simulation Software Development
                              info(+)TRON, Turkey
Tel: +90 216 4921002
Fax: +90 216 3432132
Http://www.infotron-tr.com
Http://abone.turk.net/mderdem
===============================================*/

Re: [Plib-devel] PLIB/PPE loaders/writers - Authors README!

[Christopher K. S. J. <cs...@qu...>]

Dave McClurg wrote:
> 
> .ase : Author: Dave McClurg dp...@ef...
>         IMPORT Status: 80% complete & functional
>         EXPORT Status: complete
>         Description: ASCII Export format of 3DSMAX.
>         Todo: need to support mesh animations and sub materials fully
>         but works well for most models
> 
> I am interested in writing a VRML 1.0 ascii loader if that makes sense.
> Anyone else  actively working on VRML support?  Does anyone have an
> issue with only supporting VRML 1.0 ascii ?
> 

 I've got a partially finished VRML97 loader. However, VRML97 and
VRML 1.0 are different enough so that having two different loaders
is probably reasonable.


-cks

[Plib-devel] Quaternion Usage Question

[Negative0 <neg...@ea...>]

I have seen demos of Quaternions where rotation by an axis uses a more
logical view point axis than the actual objects axis for rotation. I can't
find any guides on how to use the simple geometry quaternion routines so I
have tried the following:

sgMakeIdentQuat( &Q );
sgRotQuat( &Q, 90.0, 1.0, 0.0, 0.0 );

At this point I have tried using:
sgMakeRotMat4( rotation, &Q );
sgXformVec3( point, rotation )

and:
sgMakeRotMat4( rotation, &Q );
glMultMatrixf( rotation )

as well as:
sgQuatToAngleAxis(...)
glRotatef(...)

These don't produce any meaningful output. One combination I made actually
rotated the 90 along the X axis, but drifted 30 degrees along the Z axis as
well. I would greatly appreciate any examples, pointers, or descriptions on
how to properly setup, rotate, and use the quaternion transformations.


Thanks in advance,

-negative0

Re: [Plib-devel] PLIB/PPE loaders/writers - Authors README!

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

.ase : Author: Dave McClurg dp...@ef...
        IMPORT Status: 80% complete & functional
        EXPORT Status: complete
        Description: ASCII Export format of 3DSMAX.
        Todo: need to support mesh animations and sub materials fully
        but works well for most models

I am interested in writing a VRML 1.0 ascii loader if that makes sense.
Anyone else  actively working on VRML support?  Does anyone have an
issue with only supporting VRML 1.0 ascii ?

--Dave

Re: [Plib-devel] ASE import/export

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

Dave McClurg wrote:
> 
> 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.

Cool!

> however, i'm having trouble using cvs on sourceforge.  i'm getting
> authorization failed messages.  i'm a cvs newbie.

Yep - me too I'm afraid.  You are listed as a developer for PLIB and you
have write-access to the CVS I believe.

>  i read the cvs howto and faqs but still having trouble.  could
> someone send me their cvs scripts/commands for login sans password?

What I do is to create a directory '/home/plib_cvs' and then
use a bunch of shell scripts:

1) Get the latest CVS from the archive:

  #! /usr/bin/csh
  #
  #
  echo "Checking out a fresh copy of PLIB."
  setenv CVS_RSH ssh
  cd /home/plib_cvs
  cvs -ds...@cv...:/cvsroot/plib co plib

  (This won't scribble over changes you've done locally).

2) Commit any edits you made locally so they are in the CVS archive:

  #! /usr/bin/csh
  #
  #
  echo "Committing in PLIB changes to Web."
  setenv CVS_RSH ssh
  cd /home/plib_cvs
  cvs -ds...@cv...:/cvsroot/plib commit

  (You should probably grab the latest stuff from CVS and do a
  trial compile/run test before you do this - if you create a CVS
  version that won't compile then you WILL NOT BE POPULAR!)

3) If you add a new file that wasn't there before, run this for
   each file before you do your commit.

  #! /usr/bin/csh
  #
  #
  echo "Adding new file(s) to PLIB's CVS."
  setenv CVS_RSH ssh
  cvs -ds...@cv...:/cvsroot/plib add $*

4) If you have to delete a file from the CVS archive, do this
   before you do your commit:

  #! /usr/bin/csh
  #
  #
  echo "Removing files from PLIB on the Web."
  setenv CVS_RSH ssh
  cvs -ds...@cv...:/cvsroot/plib remove $*

**DON'T FORGET TO CHANGE 'sjbaker' to your SourceForge account name
  in the scripts above.

...oh - yes - and you DO need to type in your SourceForge password
for each of those operations - and for some of them you'll need to
type in a one or two line human-readable explanation of what you are
changing and why.

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

[Plib-devel] PLIB/PPE loaders/writers - Authors README!

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

OK, OK!  My head is spinning.

For some reason after about a year of me begging for people to
write loaders/writers for SSG, we seem to be utterly deluged
in offers to write these things.

I'm really concerned that there may be people duplicating effort
here, so could I ask everyone who is writing either a loader or
a writer for PPE/SSG 3D formats to email me personally in the
next day or two.

I'll put together a coherent list of who is working on what and
post it to both PPE and PLIB developers' lists.

Just so everyone knows, the *CURRENT* list of really solidly
working loaders and writers that are distributed with PLIB are:

.ssg: Author: Steve Baker  sjb...@ai...
      IMPORT Status: Complete and tested.
      EXPORT Status: Complete and tested.
      Description: The 'native' format for SSG
      that saves a scene graph exactly - with
      every last field read and written perfectly.

.ac : Author: Steve Baker  sjb...@ai...
      IMPORT Status: Complete and tested.
      EXPORT Status: Not complete.
      Description: The native format of the
      'AC3D' shareware modeller

.3ds: Author: Per Liedman  li...@ho...
      IMPORT Status: Seems to be complete.
      EXPORT Status: Not attempted.
      Description: One of the formats provided by 3D Studio.

.wrl: Author: Various
      IMPORT Status: Several people have offered loaders, but
                     so far, none of them seem to work reliably.
      EXPORT Status: Not attempted.
      Description: VRML - the 'official' format for 3D models
      on the WWW. Comes in two flavors 'VRML' and 'VRML-2'
      (aka VRML-97).

...so - someone help me fill in the blanks!  If you are only
"thinking about" writing a loader/writer rather than "definitely"
writing one, let me know that too.

If you want to add your code to the PLIB CVS archive, please sign
up for an account at SourceForge.net and I'll give you write-access
to the PLIB CVS site.

If you are only subscribed to the PPE developers list, then please
subscribe to the PLIB developer's list and keep loader/writer
questions on that list so we can all compare notes.

One thing we'll want to look at is the current SSG Optimiser and
triangle-stripper.  They are both currently part of the AC3D loader,
but I know for sure that most (if not all) of the other loaders
would benefit from such a service.  Those functions could do with
some work though - neither of them are exactly perfect yet.

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

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

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

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)
> 
> Is anybody working on such a thing already?

Not that I'm aware of - but there are a TON of people offering to do
loaders recently.

...which is also my cue to plead on bended knees for an ssgSaveMDL (which
would allow you to build MDL natively in PPE.

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

Yep - that's the plan right now.

As was mentioned a couple of days ago, if the number of loaders gets beyond
a half dozen or so we'll need to resort to dynamic linkage in order to
keep the active code set down to a reasonable size.

Also, if MDL requires specific texture image file formats then we'll need
to consider how to approach that.  I'd like to keep the number of dependancies
to an absolute minimum - so if you're going to need libjpeg or something
then we'll need to dynamically load that too.
 
> 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.

When you *first* autoconf a new project, you are supposed to say:

   aclocal
   automake --add-missing
   autoconf 
   ./configure
 
> Am I doing this wrong or has install.sh been missed somewhere along the line?

The '--add-missing' part does the necessary magic.

(I need to put that up on the web site somewhere)

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