plib-devel

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: Re: [Plib-devel] LoadASE problem.

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

>>attached virtual file system proposal (similar to CS vfs)
>
>Sounds good. Perhaps we could have it in lib 1.3 or 1.4 or whatever.
>What happens when you write a file and have a searchpath consisting
>or several directories? What happens when you read and the file
>exists in several places?
>

in CS (crystal space) where i took VFS from--

  // Look through all RPathV's for file or directory
  for (int i = 0; i < RPathV.Length (); i++)

so it goes through the real paths in mount order until
the operation succeeds.

this handles read-only archives (write fails) and multiple copies
of same file (takes first one).

Steve will design something he is comfortable with for PLIB
but I do think something like VFS is needed functionality

--Dave

Re: [Plib-devel] LoadASE problem.

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

Dave McClurg wrote:

> Steve will design something he is comfortable with for PLIB
> but I do think something like VFS is needed functionality

Ehem?!?  Steve wasn't planning on doing anything of the sort!

I'm really not too keen on going to all the trouble of
writing a full-blown file-system-inside-a-file, it's
more work than I want to do - and I wouldn't use it because
I'm utterly unconvinced that it's needed.

What I would *consider* doing would be:

1) Write a file name mangling function that converts UNIX-style
   file names to the 'native' file name format.

2) Write wrappers for fopen/dirent to use that standard that
   give the appearance of all systems accepting either UNIX-style
   or native file name/path conventions.

That's maybe an evening's work with very little maintenance needed
after that - versus a fairly major chunk of effort.

If I *was* going to write a file-system-in-a-file, I'd use
the existing 'tar' format since all the issues of storing
everything necessary for a file system into a single byte
stream has already been solved.  It would also allow you
to create and extract files from these virtual file systems
using 'tar' and have things like file permissions and ownerships
preserved.  The sources for tar are out there - and they port
onto absolutely every platform and address things like
byte ordering between heterogeneous machine 'endianness'.

I *certainly* wouldn't attempt to invent a new 'tarball'-like
format.

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

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)