plib-devel

RE: R: [Plib-devel] Update on 3ds loader

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

> We *need* a protable file I/O library that also can handle 
> directories!
>
yes. can you point me to another opensource project to take from?

> Then we could have something like 
>   f = fuOpen( "image.bmp", FU_IGNORE_CASE | FU_READ | FU_BINARY );
>
yes. i've already got a utility library (UL_) started. perhaps the
io stuff should go in there?

-- Dave McClurg

RE: [Plib-devel] key frame animation approach - aka Dance Moves

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

> > In order to implement key frame animation from ASE files 
> > (TM_ANIMATION samples) I need a selector that can choose 
> > between ssgTransforms.
>
ugh. my first approach was rather un-weildy.  it is also confusing
how ssgSelector can select several kids at the same time.  is that
used much and could branch entities have taken care of that?

> You'd also (presumably) want to use some keyframe interpolation
> - surely the file doesn't store a matrix for every frame of an animation?
>
actually the ASE exporter allows you to force a sample every frame.
interpolation between keys is not always linear and forcing a
sample every frame is guaranteed to give the same result as the
3d artist sees in max without the heavy duty math.  no need to
figure out spline paths or acceleration from coefficients in the
ASE file.

> Perhaps this is the kind of thing that would be better left 
> to the application, but if you want to do it in SSG, I think
> we need a new node type (derived from ssgTransform I guess)
> which knows how to do this.
>
i really think the entities for transform and mesh animation
should be in SSG.  the ASE format has animation in a nice format
and the standard SSG/ASE loader should be able to handle it.

a ssgTransformSelector dervied from ssgTransform does sound like
the best way to handle this.  for mesh (deformation) animation,
the ssgSelector should be fine.

one more point regarding animation.  there doesn't seem to be a
way to synchronize several timed selectors (ssgTimedSelector).
for a complex animation with parent heirarchy imported from MAX,
all the entities are animating relative to a "time" value.  If
we could have some kind of "time" branch that established a "time"
value for all its kids, then changing that single "time" value in
the branch could elegantly control the animation of the whole.
Please share your thoughts.

I have a question about ssgTimedSelector.  Is calling setLimits()
the only way to set the current time/frame/selection?

--Dave McClurg

Re: R: [Plib-devel] Update on 3ds loader

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

Steve Baker wrote:
> 
> > Couldn't the loader convert each filename to (say) uppercase internally?
> 
> 2) If you can't get an exact match, THEN you'll have to search the current
>    directory looking for files whose names (when converted to uppercase)
>    match the given filename (when converted to uppercase).  Whether you
>    pick the first match or flag an error if there are multiple possible
>    matches is an interesting question.

Thake the first one and throw a warning IMHO.

> Since searching the directory that way is painful to do in a portable
> manner, this isn't going to be very nice to code, however, you don't
> know whether IMAGE.BMP is really stored as IMAGE.BMP, image.bmp, Image.bmp
> or iMaGe.Bmp - so there is no way to find the right filename to 'fopen'
> without doing a search.

We *need* a protable file I/O library that also can handle directories!

Then we could have something like 

  f = fuOpen( "image.bmp", FU_IGNORE_CASE | FU_READ | FU_BINARY );

CU,
Christian

Re: [Plib-devel] key frame animation approach - aka Dance Moves

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

> Dave McClurg wrote:
> 
> In order to implement key frame animation from ASE files (TM_ANIMATION samples) I need a selector that can choose between ssgTransforms.  I am considering the following approach:
> 
> use a ssgSelector (or derived class) branch.  the branch would have ssgTransform kids all sharing a single ssgVtxTable kid.  the selection would cull the correct transform to be applied to the kid.
> 
> The problem with this approach is the limit of 32 total selections.  The selector branch may easily have hundreds of transform keys to guide a camera around the scene or a bird in it's flight path.  I'm trying to get a humanoid figure to do a single dance move and it takes around 70 keys to finish the spin.

I think that if you are storing a LARGE chunk of matrix-type stuff, you
wouldn't want to use an ssgSelector at all I think.  If you have dozens of
keys, the amount of memory consumed by all those SSG nodes would get out
of hand pretty quickly.

You'd also (presumably) want to use some keyframe interpolation - surely
the file doesn't store a matrix for every frame of an animation?

Pushing the actual matrices one level down from the selection mechanism
makes doing this interpolation impossible in an elegantly structured
manner.

Perhaps this is the kind of thing that would be better left to the application,
but if you want to do it in SSG, I think we need a new node type (derived from
ssgTransform I guess) which knows how to do this.

> my approach is to create a ssgBaseSelector to remove the limit of 32 total selections.  the constructor will take a count 'ns' and i'll use a flag array to keep track of the selections for culling.  This should not impact any existing code.  ssgBranch will construct a ns=32 ssgBaseSelector.  This change will not happen until 1.3 development gets underway.
> 
> Any comments or suggestions?

This seems a little unwieldy.

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

Re: [Plib-devel] PLIB problems

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

Wolfram Kuss wrote:
> 
> Here are some problems in PPE that I think are due to plib:
> 
> - The keyflyer works differently than it used to.
> Pressing enter USED to mean move forward in
> local coordinates (camera coordinates), now it means
> move forward in global coordinates.
> I tested old *.exes.
> An exe from the 4.4. showed the old behaviour, one from
> today the new one. I prefer the old behaviour.

I may have broken that when I fixed sgMultMatrix - I'll go
back and check more carefully.

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

Re: R: [Plib-devel] Update on 3ds loader

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

Christian Mayer wrote:
> 
> Paolo Leoncini wrote:
> >
> > This group of code lines avoid loading twice (or more times!) the same texture. As far as I understood, 3DS stores texture file names as uppercase strings, so a possible problem of this mechanism could be on non-PC systems that are instead case-sensitive. On such a platform a texture stored as "IMAGE.BMP"could erroneously refer to an image file "Image.bmp".
> > Should it be the problem, let's remember that 3DS (and Max too) is not supposed to run on platforms with a case-sensitive file system, so to read such a file on UNIX a manual renaming of texture files is necessary.
> 
> Couldn't the loader convert each filename to (say) uppercase internally?

I think the best policy is:

1) Test the filename as given in the file to see if it exists in that
   case.  If there are multiple files in various cases, then the exact
   match should be the one to work reliably.

2) If you can't get an exact match, THEN you'll have to search the current
   directory looking for files whose names (when converted to uppercase)
   match the given filename (when converted to uppercase).  Whether you
   pick the first match or flag an error if there are multiple possible
   matches is an interesting question.

Since searching the directory that way is painful to do in a portable
manner, this isn't going to be very nice to code, however, you don't
know whether IMAGE.BMP is really stored as IMAGE.BMP, image.bmp, Image.bmp
or iMaGe.Bmp - so there is no way to find the right filename to 'fopen'
without doing a search.

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

[Plib-devel] need more details on BMP loader errors

[Michael K. <mk...@fu...>]

I added a routine to my own bitmap loader to be able to read in the paletted
bitmaps last night and I am able to display both of the bitmaps that Per and
Wolfram sent me. What kind of errors are people getting with bitmaps using
the plib loader? Descriptions of errors you are getting would be very
helpful.

Thanks,

-Michael Kurth

Re: [Plib-devel] Update on 3ds loader

[Michael K. <neg...@ea...>]

RE: [Plib-devel] Update on 3ds loaderI'm afraid that "just doesnt like =
this file" is a little vague. Does it crash when loading? Does it load =
but not display? Does it load and display garbage?

-mike

  ----- Original Message -----=20
  From: Dave McClurg=20
  To: 'pli...@li...'=20
  Sent: Friday, April 07, 2000 8:38 AM
  Subject: RE: [Plib-devel] Update on 3ds loader


  Mike wrote:=20
  > Can you send me the snoo-cat.bmp so I can look at it's=20
  > format? Maybe I can=20
  > find out what is wrong with it or the BMP loader.=20
  >=20
  http://www.pond.net/~davem/stuff/snoo-cat.bmp=20

  ssg just doesn't like this file=20

  thanks,=20
  -- Dave McClurg=20

RE: [Plib-devel] key frame animation approach - aka Dance Moves

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

> ssgBranch will construct a ns=32 ssgBaseSelector.
i meant...
    ssgSelector will construct a ns=32 ssgBaseSelector.
 

[Plib-devel] key frame animation approach - aka Dance Moves

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

In order to implement key frame animation from ASE files (TM_ANIMATION
samples) I need a selector that can choose between ssgTransforms.  I am
considering the following approach:

use a ssgSelector (or derived class) branch.  the branch would have
ssgTransform kids all sharing a single ssgVtxTable kid.  the selection would
cull the correct transform to be applied to the kid.

The problem with this approach is the limit of 32 total selections.  The
selector branch may easily have hundreds of transform keys to guide a camera
around the scene or a bird in it's flight path.  I'm trying to get a
humanoid figure to do a single dance move and it takes around 70 keys to
finish the spin.

my approach is to create a ssgBaseSelector to remove the limit of 32 total
selections.  the constructor will take a count 'ns' and i'll use a flag
array to keep track of the selections for culling.  This should not impact
any existing code.  ssgBranch will construct a ns=32 ssgBaseSelector.  This
change will not happen until 1.3 development gets underway.

Any comments or suggestions?

--Dave McClurg

RE: [Plib-devel] PLIB problems

[Paul B. <pbl...@di...>]

Windows 9x, NT, and 2k all seem to allow "/" (we use
it regularly for our filesystem stuff).  Note that command.com
and cmd.exe do not support it.  The underlying APIs
do.

paul


-----Original Message-----
From: Dave McClurg [mailto:Dav...@dy...]
Sent: Friday, April 07, 2000 12:20 PM
To: 'pli...@li...'
Subject: RE: [Plib-devel] PLIB problems


> - ssSetTexturePath doesnt work for me. 
> To load textures, I have to have the textures in the current path. 
> I think there is one bug in plib preventing this from working. 
> 
found a bug in ssgLoadOBJ and fixed it.  other loaders look fine. 
> There are probably also two bugs in PPE regarding this 
> ("/" instead of "\" on Windo$ and no ending "\"). 
> 
win98 doesn't mind "\".  it will take "\" or "/" i think 
i have code from Curt (flightgear) that deals with fixing paths 
but it only deals with mac vs unix seperators (: and /) and doesn't 
seem to worry about "\".  Curt? 
we should pull some code out of another opensource project and 
use it.  anyone have some path fixing code lying around? 
--Dave McClurg 

RE: [Plib-devel] PLIB problems

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

> - ssSetTexturePath doesnt work for me.
> To load textures, I have to have the textures in the current path.
> I think there is one bug in plib preventing this from working.
>
found a bug in ssgLoadOBJ and fixed it.  other loaders look fine.

> There are probably also two bugs in PPE regarding this
> ("/" instead of "\" on Windo$ and no ending "\").
> 
win98 doesn't mind "\".  it will take "\" or "/" i think

i have code from Curt (flightgear) that deals with fixing paths
but it only deals with mac vs unix seperators (: and /) and doesn't
seem to worry about "\".  Curt?

we should pull some code out of another opensource project and
use it.  anyone have some path fixing code lying around?

--Dave McClurg

Re: R: [Plib-devel] Update on 3ds loader

[Per L. <li...@ho...>]

On Fri, 07 Apr 2000, Christian Mayer wrote:
> Paolo Leoncini wrote:
> > 
> > This group of code lines avoid loading twice (or more times!) the same texture. As far as I understood, 3DS stores texture file names as uppercase strings, so a possible problem of this mechanism could be on non-PC systems that are instead case-sensitive. On such a platform a texture stored as "IMAGE.BMP"could erroneously refer to an image file "Image.bmp".
> > Should it be the problem, let's remember that 3DS (and Max too) is not supposed to run on platforms with a case-sensitive file system, so to read such a file on UNIX a manual renaming of texture files is necessary.
> 
> 
> Couldn't the loader convert each filename to (say) uppercase internally?

The problem, as I understand it, is that the file may be named "Image.bmp" in
the file system, but will be called "IMAGE.BMP" in the 3ds model, so there is
no gain in converting the filename to upper case.

Regards,
Per Liedman

-- 
   / Per Liedman
  / li...@ho...
 / www.mdstud.chalmers.se/~md6pl
/ 031-825659 / 0705-520455

Re: R: [Plib-devel] Update on 3ds loader

[Per L. <li...@ho...>]

On Fri, 07 Apr 2000, Wolfram Kuss wrote:
> I am working under (on??) Windows NT.
> It crashes while loading chevy.3ds because it tries to
> reference an undefined pointer (the hex address is cdcdcdcd,
> which is Visual C++ way of saying bad pointer).

Ok, perhaps it is that the loader does a pointer == NULL test, but perhaps we
never initialize it to NULL, and it's just a coincidence that it works on my
system? I have to check it out...

> I set a break point in parse_material and another one in 
> parse_mapname.
> The first three times it finds a breakpoint is in
> parse_material. Then it goes into parse_mapname.
> num_materials is three.
> 
> mat_tfnames is obviously a array of pointers. The array is defined.
> However, the pointers are not.
> 
> MAYBE the first three materials are un-textured,
> the texturenames are therefore not defined and when it 
> finds the first mapname it tries to compare it to the undefined,
> previous ones?

Sounds plausible, but I haven't really looked at this part of the code, since
it seemed to work on my system - obviously I will have to look into it now.

> Are you (Per/Paolo) working under Windo$?
> 
> Paolo, shall I send you the file?
> 
> Per, have you looked at the newest CVS-code, perhaps 
> it is different from the code you have? Do you use MSVC 6?
> Do you do a debug build?

No, I work under Linux (SuSE 6.3), and as mentioned before, I don't have any
trouble with this. Loading chevy.3ds produces a model of a car standing on a
large square. Some texture coordinates are missing though.

Thanks for the error report, I will have a look at it.

Regards,
Per Liedman

-- 
   / Per Liedman
  / li...@ho...
 / www.mdstud.chalmers.se/~md6pl
/ 031-825659 / 0705-520455

Re: R: [Plib-devel] Update on 3ds loader

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

Paolo Leoncini wrote:
> 
> This group of code lines avoid loading twice (or more times!) the same texture. As far as I understood, 3DS stores texture file names as uppercase strings, so a possible problem of this mechanism could be on non-PC systems that are instead case-sensitive. On such a platform a texture stored as "IMAGE.BMP"could erroneously refer to an image file "Image.bmp".
> Should it be the problem, let's remember that 3DS (and Max too) is not supposed to run on platforms with a case-sensitive file system, so to read such a file on UNIX a manual renaming of texture files is necessary.


Couldn't the loader convert each filename to (say) uppercase internally?

CU,
Christian

[Plib-devel] PLIB problems

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

Here are some problems in PPE that I think are due to plib:

- The keyflyer works differently than it used to.
Pressing enter USED to mean move forward in
local coordinates (camera coordinates), now it means
move forward in global coordinates.
I tested old *.exes. 
An exe from the 4.4. showed the old behaviour, one from 
today the new one. I prefer the old behaviour.

- When I load a DXF-file, it doesnt look lighted/shaded.
Maybe the normals are missing? 

- ssSetTexturePath doesnt work for me.
To load textures, I have to have the textures in the current path.
I think there is one bug in plib preventing this from working.
There are probably also two bugs in PPE regarding this
("/" instead of "\" on Windo$ and no ending "\").


Bye bye,
Wolfram.

Re: R: [Plib-devel] Update on 3ds loader

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

My problem is not that something is loaded too often
or some texture is not found, but that it crashes because it is 
dereferencing an invalid pointer.

I am working under (on??) Windows NT.
It crashes while loading chevy.3ds because it tries to
reference an undefined pointer (the hex address is cdcdcdcd,
which is Visual C++ way of saying bad pointer).

I set a break point in parse_material and another one in 
parse_mapname.
The first three times it finds a breakpoint is in
parse_material. Then it goes into parse_mapname.
num_materials is three.

mat_tfnames is obviously a array of pointers. The array is defined.
However, the pointers are not.

MAYBE the first three materials are un-textured,
the texturenames are therefore not defined and when it 
finds the first mapname it tries to compare it to the undefined,
previous ones?

Are you (Per/Paolo) working under Windo$?

Paolo, shall I send you the file?

Per, have you looked at the newest CVS-code, perhaps 
it is different from the code you have? Do you use MSVC 6?
Do you do a debug build?

Bye bye,
Wolfram.

RE: [Plib-devel] Update on 3ds loader

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

Mike wrote:
> Can you send me the snoo-cat.bmp so I can look at it's 
> format? Maybe I can
> find out what is wrong with it or the BMP loader.
> 
http://www.pond.net/~davem/stuff/snoo-cat.bmp

ssg just doesn't like this file

thanks,
-- Dave McClurg

R: [Plib-devel] Update on 3ds loader

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

This group of code lines avoid loading twice (or more times!) the same =
texture. As far as I understood, 3DS stores texture file names as =
uppercase strings, so a possible problem of this mechanism could be on =
non-PC systems that are instead case-sensitive. On such a platform a =
texture stored as "IMAGE.BMP"could erroneously refer to an image file =
"Image.bmp".
Should it be the problem, let's remember that 3DS (and Max too) is not =
supposed to run on platforms with a case-sensitive file system, so to =
read such a file on UNIX a manual renaming of texture files is =
necessary.

Should it not answer the question, I would like to better understand the =
problem on that test case by Wolfram.

-----Messaggio originale-----
Da:	Per Liedman [SMTP:li...@ho...]
Inviato:	venerd=EC 7 aprile 2000 16.18
A:	pli...@li...
Oggetto:	Re: [Plib-devel] Update on 3ds loader

On Fri, 07 Apr 2000, Wolfram Kuss wrote:
> I just got the newest stuff from CVS and the chevy doesn't load for me
> :-(. The problem is in the function parse_mapname in the lines:
>   =20
> // since texture path is in common, just store (and compare) tex file
> name
>     if ( mat_tfnames[mat_num] !=3D (char *)NULL && strcmp( texname,
> mat_tfnames[mat_num] ) =3D=3D 0 ) {
>=20
> mat_tfnames seems to be defined, mat_num is 0, but
> mat_tfnames[0] is not defined.

Huh!? No problem on my system... Perhaps Paolo has some idea what the =
problem
might be, since these lines belong to his modifications.

--=20
   / Per Liedman
  / li...@ho...
 / www.mdstud.chalmers.se/~md6pl
/ 031-825659 / 0705-520455

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

Re: [Plib-devel] Update on 3ds loader

[Per L. <li...@ho...>]

On Fri, 07 Apr 2000, Wolfram Kuss wrote:
> I just got the newest stuff from CVS and the chevy doesn't load for me
> :-(. The problem is in the function parse_mapname in the lines:
>    
> // since texture path is in common, just store (and compare) tex file
> name
>     if ( mat_tfnames[mat_num] != (char *)NULL && strcmp( texname,
> mat_tfnames[mat_num] ) == 0 ) {
> 
> mat_tfnames seems to be defined, mat_num is 0, but
> mat_tfnames[0] is not defined.

Huh!? No problem on my system... Perhaps Paolo has some idea what the problem
might be, since these lines belong to his modifications.

-- 
   / Per Liedman
  / li...@ho...
 / www.mdstud.chalmers.se/~md6pl
/ 031-825659 / 0705-520455

Re: [Plib-devel] Update on 3ds loader

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

Per Liedman <li...@ho...> wrote:

> [...] SNOO-CAT.BMP. I never got this texture to show in plib, which I hope
>  is because the BMP image loader does something weird (I think Steve has said
>  several times that the bmp format isn't to be trusted) - I can get it to work
>  if I replace it with another texture (rgb, for example).

Great! That means the *.3ds-loader works.

>* A bit worse: The model chevy.3ds seems to miss some texture coordinates - at

This model has quite a lot of materials, but only two include
textures. Therefore, I would guess that some polys are textured and
some are just given a rgb-colour. Maybe its only those that don't have
texture coordinates?

I just got the newest stuff from CVS and the chevy doesn't load for me
:-(. The problem is in the function parse_mapname in the lines:
   
// since texture path is in common, just store (and compare) tex file
name
    if ( mat_tfnames[mat_num] != (char *)NULL && strcmp( texname,
mat_tfnames[mat_num] ) == 0 ) {

mat_tfnames seems to be defined, mat_num is 0, but
mat_tfnames[0] is not defined.

>Regards,
>Per Liedman

Bye bye,
Wolfram Kuss.

Re: [Plib-devel] Update on 3ds loader

[Michael K. <neg...@ea...>]

The snoo-cat.bmp is just a palleted bitmap, and the header format looks
fine. I had a BMP loader I had written before, but it didn't support
palletes - until 2 minutes ago. I can load the snoo-cat up in my code, so
when I get home tomorrow I'll look over the plib loader and see where the
differences are.

-mike

----- Original Message -----
From: Steve Baker <sjb...@ai...>
To: <pli...@li...>
Sent: Thursday, April 06, 2000 7:30 PM
Subject: Re: [Plib-devel] Update on 3ds loader


> Michael Kurth wrote:
>
> > Can you send me the snoo-cat.bmp so I can look at it's format? Maybe I
can
> > find out what is wrong with it or the BMP loader.
>
> I'll lay good odds that it's the loader.  The BMP format is really
> a horrible mess - and the documentation I could get without a
> Microsoft developer's license was rather sketchy.
>
> --
> 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] Update on 3ds loader

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

Michael Kurth wrote:
 
> Can you send me the snoo-cat.bmp so I can look at it's format? Maybe I can
> find out what is wrong with it or the BMP loader.

I'll lay good odds that it's the loader.  The BMP format is really
a horrible mess - and the documentation I could get without a
Microsoft developer's license was rather sketchy.

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

Re: [Plib-devel] Update on 3ds loader

[Michael K. <neg...@ea...>]

Can you send me the snoo-cat.bmp so I can look at it's format? Maybe I can
find out what is wrong with it or the BMP loader.

Thanks,

 Mike

----- Original Message -----
From: Per Liedman <li...@ho...>
To: <pli...@li...>
Sent: Thursday, April 06, 2000 2:14 PM
Subject: [Plib-devel] Update on 3ds loader


> I sat down and did some work on the 3ds loader this evening, and it works
> better now. However, I have discovered some major weirdness that I'm not
happy
> about:
>
> * One of the models Wolfram Kuss sent me, testquader.3ds, includes a
texture
>   called SNOO-CAT.BMP. I never got this texture to show in plib, which I
hope
>   is because the BMP image loader does something weird (I think Steve has
said
>   several times that the bmp format isn't to be trusted) - I can get it to
work
>   if I replace it with another texture (rgb, for example).
>
> * A bit worse: The model chevy.3ds seems to miss some texture
coordinates - at
>   least my loader can't find them. There are some texture coordinates
specified,
>   but for some parts they just seem to be missing. Anyone who knows if
there is
>   another chunk than CHUNK_MAPLIST (0x4140) which is used by 3ds for
storing
>   map coordinates? Perhaps there is some intelligent default behaviour?
For now,
>   I just don't give any coords to ssg if they're missing, and display a
warning.
>
> The latest version of ssgLoad3ds.cxx can be downloaded from
>
>   http://www.mdstud.chalmers.se/~md6pl/ssgLoad3ds.cxx
>
> This version also includes the improvments made by Paolo Leoncini (a lot
of
> texture stuff), and all long integers are replaced by int. Even if not
> perfect, the models come out looking ok, and it doesn't crash any longer
(quite
> an improvment, if you ask me :)
>
> Regards,
> Per Liedman
>
> --
>    / Per Liedman
>   / li...@ho...
>  / www.mdstud.chalmers.se/~md6pl
> / 031-825659 / 0705-520455
>
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
>

RE: [Plib-devel] Update on 3ds loader

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

> * One of the models Wolfram Kuss sent me, testquader.3ds, 
> includes a texture called SNOO-CAT.BMP. ...
>
this texture gave me problems too.  i used xnview to load/save
it and got it to work finally.

> The latest version of ssgLoad3ds.cxx can be downloaded from
>   http://www.mdstud.chalmers.se/~md6pl/ssgLoad3ds.cxx
> 
thanks Per. i commited that to CVS for you

-- Dave McClurg