plib-devel

Re: [Plib-devel] Importers/Exporters

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

Ok, so now the file writers are actually used and I get an
error-dialog. However, there is still no explanation of the error.

Steve, if its ok by you, as a short or medium term-solution, please
add the line(s):

  fprintf ( stderr,
    "Not saved: There is no writer for the format \"%s\".\n", extn);

into file ssg.cxx, at the end of ssgSave, just before the:
  return FALSE ;

Bye bye,
Wolfram Kuss.

Re: [Plib-devel] Win32 DLLs and some co-ordinate adjustment

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

Sam Stickland wrote:
> 
> Hi,
> 
> Some of the projects I hope to use PLIB in are unfortunately not open
> source - so to maintain the LGPL license agreement PLIB needs to be
> distributed as either shared libraries on *nix or DLL's on Win32 - which
> requires some change to the automake system on *nix, and the changing of
> some function prototypes on Win32.

Well, you don't have to distribute PLIB unless you make changes to it.

The contract implied between you and me by the LGPL is just that I'll give
you the software for free so long as you promise to give me back any
improvements you make to it...which you are just about to do. Woohoo! The
system works!

It also implies a requirement that your users be able to re-link your code
against some hypothetical future PLIB without having to get you to do it.
You can meet that requirement by shipping the '.o' files for your application.
I doubt that anyone ever made use of that feature in practice - but that's
what LGPL requires.

As an alternative, you *could* recompile PLIB as a DLL/.so - but that's not
how I distribute it normally.
 
> Also, I needed PUI to resize it's interface when the window resizes, so I
> made a couple of trivial changes to the source to allow this.

Cool!
 
> I'd like to submit these changes (to the current stable release).  How do I
> go about this?

If it's a simple patch, just email it to me - if you feel you need CVS access
to do major stuff, then I'll do it - but I'd like a better idea of what you
plan to change.

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

Re: [Plib-devel] C++ Philosophy Question

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

Christian Mayer wrote:

> <hiding mode=";-)">
> To open the discussion: AFAIK does Steve hate the '//' comments...
> </hiding>

#define PI 3.14159  // Yes, Steve does hate these comments

 ...150 lines of code later...

   x = PI + 1 + 2 + 3
          + 4 + 5 + 6 ;

...this really happened to me once.  :-(

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

Re: [Plib-devel] Another stumper ...

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

On Tue, 21 Mar 2000, Curtis L. Olson wrote:
> > I think a comprehensive test program is needed - something that
> > we could ask a bunch of people to test on different implementations.
> 
> What I ought to do is just try to draw a simple object with
> glColorMaterial() off and trying to see if I can get anything sensible
> on the screen.

The 3ds-loader does not use glColorMaterial, so it definitely works to some
degree. But then again, people have been complaining about the 3ds-loader...
but that's mostly texture related.

(Regarding my project to fix the textures in my loader, Wolfram Kuss was kind
enough to send me the models, but now it turns out that I have broken something
in my X-server/NVidia/glx setup, so using textures of any kind *completely
hangs* my machine! I hate this stuff!)

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

RE: [Plib-devel] Importers/Exporters

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

snipped from
http://www3.autodesk.com/adsk/item/0,,193961,00.html

Core features of 3D Studio MAX R3.1 whose source code
will be released include the following:

Flex Modifier—spring-based, soft-body dynamics
Bezier Patch technology—Bezier patch tessellation code
Skin Modifier—mesh-to-bone binding
ASCII "ASC" Export and Import

see
http://www.discreet.com/gamezone

I haven't been able to connect assumedly because
of slashdot effect

Norman

Re: [Plib-devel] Win32 DLLs and some co-ordinate adjustment

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

Sam Stickland wrote:
> 
> Hi,
> 
> Some of the projects I hope to use PLIB in are unfortunately not open
> source - so to maintain the LGPL license agreement PLIB needs to be
> distributed as either shared libraries on *nix or DLL's on Win32 - which
> requires some change to the automake system on *nix, and the changing of
> some function prototypes on Win32.
> 
> Also, I needed PUI to resize it's interface when the window resizes, so I
> made a couple of trivial changes to the source to allow this.
> 
> I'd like to submit these changes (to the current stable release).  How do I
> go about this?

Either get write access for the CVS (Steve'll give it to you) or send
him the changed files.

CU,
Christian

Re: [Plib-devel] Importers/Exporters

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

Wolfram Kuss wrote:
> 
> Also, most *.bmp-files are not compressed at all, not even by RLE.
> So, they are very large. I know that bmps can use RLE-encoding, but
> obviously it is not the default or not used by painting-programs.
>

It depends. Paint Shop Pro can use and write it AFAIK.

CU,
Christian

Re: [Plib-devel] Win32 DLLs and some co-ordinate adjustment

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

Sam wrote:
>Some of the projects I hope to use PLIB in are unfortunately not open
>source - so to maintain the LGPL license agreement PLIB needs to be
>distributed as either shared libraries on *nix or DLL's on Win32 - which
>requires some change to the automake system on *nix, and the changing of
>some function prototypes on Win32.
>
>Also, I needed PUI to resize it's interface when the window resizes, so I
>made a couple of trivial changes to the source to allow this.
>
i'm interested in those changes too since i'm working on a commercial
game for windoze using PLIB

Re: [Plib-devel] Importers/Exporters

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

Steve Baker <sjb...@ai...> wrote:

>The documentation for BMP files is so patchy - and there are so
>many weird and wonderful varients with multiple (sometimes
>contradictory) header blocks, that reading BMP files using
>portable code is virtually impossible.
>
>Microsoft - we *love* you!

Absolutely correct.

Also, most *.bmp-files are not compressed at all, not even by RLE.
So, they are very large. I know that bmps can use RLE-encoding, but
obviously it is not the default or not used by painting-programs.

Bye bye,
Wolfram.

Re: [Plib-devel] Importers/Exporters

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

Dave McClurg <dp...@ef...> wrote:

>ssgLoadDXF now supports LINE, 3DFACE, and POLYLINE (VERTEX,SEQEND)
>hopefully that is all we need for DXF support
>let me know if there are any more bugs

Great! Quads work. Meshes that werent displayed at all are now 
displayed as lines. If these are displayed as (filled) faces, then
it would be even better. 
Does anbody know what DXF means by Polyline? Is this filled?

>I have a question about testq.obj
>it refers to a file called testq.mtl
>do you have that file?

I didnt know it was needed for the *.obj-file. I did send it to you
now.

Bye bye,
Wolfram.

Re: [Plib-devel] Importers/Exporters

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

Steve Baker <sjb...@ai...> wrote:

>I think a formal error handler is needed because SSG gets used
>for full-screen graphics where a printout to stderr isn't going
>to be noticed.  For a program like PPE, you'd like to stuff the
>error message into a dialog box.

Yes, that would be nice. I normally have the console-window behind the
other two windows. 
However, I think if there is one error in a dialog and all the details
are in the console window, that is good enough for a long time.

But in reality, no error message comes in either a dialog nor in the
console. All the *.3ds, *.wrl, *.obj etc that are saved have exactly
the same size.

I found the error!

In PPE, it read
if ( ! ssgSaveSSG ( last_fname, model ) )
instead of
if ( ! ssgSave ( last_fname, model ) )

I just committed the fix.

So, it is not surprising that all the exporters didnt seem to work,
since everything was saved in ssg-format.
Also, I found a new program (3D exploration on Windo$), which among
other things, allows me to test *.ase.
The new results for the file-writers are very good:
*.obj: I saw no bug.
*.dxf: I saw no bug.
*.ase: Works quite well, but seems to exchange frontfaces and
backfaces.

Bye bye,
Wolfram.

[Plib-devel] Win32 DLLs and some co-ordinate adjustment

[Sam S. <sa...@sp...>]

Hi,

Some of the projects I hope to use PLIB in are unfortunately not open
source - so to maintain the LGPL license agreement PLIB needs to be
distributed as either shared libraries on *nix or DLL's on Win32 - which
requires some change to the automake system on *nix, and the changing of
some function prototypes on Win32.

Also, I needed PUI to resize it's interface when the window resizes, so I
made a couple of trivial changes to the source to allow this.

I'd like to submit these changes (to the current stable release).  How do I
go about this?

Sam

Re: Re: [Plib-devel] Importers/Exporters

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

Steve wrote:
>I think a formal error handler is needed because SSG gets used
>for full-screen graphics where a printout to stderr isn't going
>to be noticed.  For a program like PPE, you'd like to stuff the
>error message into a dialog box.
>
povray has a console. could we store error messages in a
multi-line console buffer and then when PPE gets an error
return it pops up a console window?  the "last" error found
string might not be enough information.

doesn't matter to me how you want to handle it.  just let me
know and i'll make the loaders conform.

Re: [Plib-devel] C++ Philosophy Question

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

Steve Baker wrote:
> 
> The thing I *really* dislike about ref parameters is that it's
> possible to see this in the header for a library somewhere:
> 
>    void some_funtion ( int x ) ;
> 
> ...you go and write code to use 'some_function' *knowing* for
> sure that:
> 
>    x = 6 ;
>    some_function ( x ) ;
> 
> *CANNOT* change the value of 'x'.

But you should have written then

  void some_function ( const int x );

instead. This showes the programmer that the function won't change x in
any circumstances. And when you've got a const you are also able to use
a ref as it won't change the variable - the compiler guarantees it. But
when you use a pointer there's no guarantee that the function won't
change the value - even if it's using the pointer only for the reason
that the parameter is too big to be copied efficiently. E.g.:

class foo
{
private:
  long big_array[10000];

public:
  /* ... */
};

void my_func1 ( foo x );	//can't change x. X will be copied
				//which is extremly unefficient.

void my_func2 ( foo& x );	//can change x, x won't be copied
				//=> fast but dangerous

void my_func3 ( foo* x );	//can change x, x won't be copied
				//=> fast but dangerous

void my_func4 ( const foo& x );	//can't change x, x won't be copied
				//=> fast and secure
> 
> What's nasty about 'ref' arguments is that some subsequent
> version of that library can change the parameter of
> 'some_function' to be 'ref' and then change the value of x
> inside the function without the author of the application
> code being aware that the libraries' policy has changed.
> The old call to some_function still compiles!  Eeeekkkkk!
> 
> Also, I like to be able to look at some complex code
> that uses 'some_function' and *know* that the parameter
> isn't altered by the the function just by looking at the
> call.  I don't even have to go off and read the manual
> for 'some_function' in order to know that.
> 
> The nice thing about good old fashioned C-style pointers
> is that when you see:
> 
>    x = 6 ;
>    some_function ( & x ) ;
> 
> ...that '&' shouts loudly to you to bear in mind that x may
> well have been changed by the call.  If you don't see an '&'
> then you don't need to know much about some_function in order
> to see that it doesn't change 'x'.
> 
> That makes code MUCH more readable.
> 
> I think 'ref' is *EVIL* because its syntax doesn't make it
> obvious.

IMHO you should use refs only in combination with const to increase the
speed and decrease the required memory. If you want to modify an object
you should use pointers. That the best of the two worlds - IMHO.

> > Anyway, that's it for religion, time to write some code.
> 
> Indeed.

That's programming style always. But this discussion makes at least
sense at it's about the code. It gets much more religious if people
start to discuss diferent styles of comments. 

<hiding mode=";-)">
To open the discussion: AFAIK does Steve hate the '//' comments...
</hiding>

CU,
Christian

Re: [Plib-devel] I'm outta here.

[Philippe C.D. R. <ro...@ia...>]

On Sun, 19 Mar 2000, Christian Mayer wrote:
> I'm not reading the 'unofficial' sites with the rumors, but the official
> nVidia Linux driver site
> (http://www.nvidia.com/Products.nsf/htmlmedia/software_drivers.html)
> says:
> 
>   ... The upcoming XFree86 X server 4.0 will use the Direct
>   Rendering Infrastructure required to take full advantage of the
>   RIVA processors. ...
> 
> This tells me that they'll use DRI. (Currently they aren't. But their
> current drivers crash with even the most simplistic OpenGl applications
> very badly)

nVidia won't use DRI. There drivers will be written by SGI, they will be binary
only and offer sth similar to DRI - but NOT DRI due to licensing reasons!
  
sweet dreams, Phil
-- 
Philippe C.D. Robert | http://www.iam.unibe.ch/~robert/

Research Group on Computational Geometry and Graphics
Institute of Computer Science and Appl. Mathematics (IAM), Office 205
Neubrueckstrasse 10, CH-3012 Bern Switzerland, phone: +41 31 6313321

Re: [Plib-devel] Importers/Exporters

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

Dave McClurg wrote:

> > SSG really needs a comprehensive ssgGetError() system.
> 
> i'm using a few printfs sprinkled through ssgLoadASE
> to give detailed information.

Ditto.
 
>         ssgGetError() => SSG_ERR_MALFORMED_VERTEX
> 
> is less helpful than
> 
>         foo.ASE, line 6: missing z coordinate
> 
> on the console.  but if you want to spec something out
> i don't mind implementing a more formal error handling method.

I think a formal error handler is needed because SSG gets used
for full-screen graphics where a printout to stderr isn't going
to be noticed.  For a program like PPE, you'd like to stuff the
error message into a dialog box.

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

RE: [Plib-devel] Importers/Exporters

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

Steve wrote:
> The only problem (at present) is that when something goes wrong with
> the file load/save process, you know that it went wrong - but there
> is no way to tell WHY it went wrong.
> 
> SSG really needs a comprehensive ssgGetError() system.

i'm using a few printfs sprinkled through ssgLoadASE
to give detailed information.

	ssgGetError() => SSG_ERR_MALFORMED_VERTEX

is less helpful than

	foo.ASE, line 6: missing z coordinate

on the console.  but if you want to spec something out
i don't mind implementing a more formal error handling method.

Re: [Plib-devel] C++ Philosophy Question

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

Bill Weiland wrote:

> references are more precise/less error prone than pointers
> when e.g. a function arg. or member cannot/should not be
> NULL (and cannot/should not be changed dynamically)...

The thing I *really* dislike about ref parameters is that it's
possible to see this in the header for a library somewhere:

   void some_funtion ( int x ) ;

...you go and write code to use 'some_function' *knowing* for
sure that:

   x = 6 ;
   some_function ( x ) ;

*CANNOT* change the value of 'x'.

What's nasty about 'ref' arguments is that some subsequent
version of that library can change the parameter of
'some_function' to be 'ref' and then change the value of x
inside the function without the author of the application
code being aware that the libraries' policy has changed.
The old call to some_function still compiles!  Eeeekkkkk!

Also, I like to be able to look at some complex code
that uses 'some_function' and *know* that the parameter
isn't altered by the the function just by looking at the
call.  I don't even have to go off and read the manual
for 'some_function' in order to know that.

The nice thing about good old fashioned C-style pointers
is that when you see:


   x = 6 ;
   some_function ( & x ) ;

...that '&' shouts loudly to you to bear in mind that x may
well have been changed by the call.  If you don't see an '&'
then you don't need to know much about some_function in order
to see that it doesn't change 'x'.

That makes code MUCH more readable.

I think 'ref' is *EVIL* because its syntax doesn't make it
obvious.

> Anyway, that's it for religion, time to write some code.

Indeed.

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

Re: [Plib-devel] Importers/Exporters

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

Dave McClurg wrote:

> for the file snoo-cat.bmp
> at first the PLIB image loader complained about an unexpected EOF
> then i converted it to a 24 bit BMP and still wouldn't load
> i'll have to look into that.

The documentation for BMP files is so patchy - and there are so
many weird and wonderful varients with multiple (sometimes
contradictory) header blocks, that reading BMP files using
portable code is virtually impossible.

Microsoft - we *love* you!

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

Re: [Plib-devel] Importers/Exporters

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

Wolfram Kuss wrote:
> 
> Per Liedman <li...@ho...> wrote:
> 
> >On Mon, 20 Mar 2000, Wolfram Kuss wrote:
> >
> >> *.3ds writer: Polytrans says about the object:
> >> not 3ds file or version not recognized.
> >
> >Hmmm...AFAIK there is no plib 3ds-writer, and that's one plausible reason for
> >this error :-)

Not really.

> :-)
> So PolyTrans is absolutely right. Well, it shows again that there
> should be a warning: When you tell PPE to write test.3ds, it does.
> So, you think, it is a *.3ds-file :-).

No - the writer function returns TRUE if it saved the file sucessfully,
FALSE otherwise.  If there is no writer for a particular format, it
won't create the output file.

Applications MUST check the error return from both ssgLoad and ssgSave.

The only problem (at present) is that when something goes wrong with
the file load/save process, you know that it went wrong - but there
is no way to tell WHY it went wrong.

SSG really needs a comprehensive ssgGetError() system.

So much work - so few hours  :-(

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

Re: Re: [Plib-devel] Importers/Exporters

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

>>550.dxf has only VERTEX and POLYLINE sections.
>>no LINE or 3DFACE sections are present.
>

i did a commit which adds POLYLINE support
i used 550.dxf to test it
the load result looks the same as in AC3D

ssgLoadDXF now supports LINE, 3DFACE, and POLYLINE (VERTEX,SEQEND)
hopefully that is all we need for DXF support
let me know if there are any more bugs

I have a question about testq.obj
it refers to a file called testq.mtl
do you have that file?

Thanks again for the testing Wolfram!

Re: Re: [Plib-devel] Importers/Exporters

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

Wolfram wrote:
>>FACE.dxf has only one face
>
>Yes, exactly, so it should be easy to debug.
>
>>i did a commit which should add quad support
>
>Great! Did you test it with face.dxf?
>

oic. thanks
i checked face.dxf, made a fix, did another commit
and now quads should work fine

i'm looking into adding polyline support for 550.dxf
AC3D loads 550.dxf and so should we

--Dave

Re: [Plib-devel] C++ Philosophy Question

[Loring H. <ls...@cs...>]

> >So far, nothing in STL seems worth the hassle. There are
> >still too many incompatible versions floating around out
> >there - and systems that don't have it installed, etc.
> >
> >I watched the L-O-N-G thread that went on in the FGFS
> >mailing list when STL was first used.  It convinced me
> >that I can do without it.
> >
> 
> There _are_ problems with STL across implementations (even using Visual C++
> 6.0, you'd better be using Service Pack 3).  This is unfortunate, because
> you can write a lot of nice, concise code quickly using the STL containers.
> I've come to like STL, but I agree that portability is a problem (which I
> sort of realized as soon as I posted the question).  Oh well...

My biggest issue with STL is that it has been hard to debug various STL data
structures...

In addition to STL being inconsistent, sometimes it isn't natively available
for some platforms.  I've used STLport to deal with this - I have gotten
STLport 3.2.2 beta 3 (http://www.stlport.org/) working with the native
compilers under AIX and Solaris, and it should work for many other platforms
as well.

Loring

Re: [Plib-devel] Importers/Exporters

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

Dave wrote:

>i received two dxf files:
>550.dxf
>FACE.DXF
>
>not sure how useful they are
>550.dxf has only VERTEX and POLYLINE sections.
>no LINE or 3DFACE sections are present.

Hmm, I will look at 550,dxf again tomorrow at work, where I have
PolyTrans. However, I am no expert at DXF-files. 550.dxf was created
by saving an object with faces.

>FACE.dxf has only one face

Yes, exactly, so it should be easy to debug.

>i did a commit which should add quad support

Great! Did you test it with face.dxf?

>--Dave

Bye bye,
Wolfram.

Re: [Plib-devel] Importers/Exporters

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

>I tested some importers and exporters.
>*.dxf loader: Always reads exactly one triangle :-).
>*.dxf writer: Polytrans thought, it would be an ASCII file, which it
>wasn't.
i received two dxf files:
550.dxf
FACE.DXF

not sure how useful they are
550.dxf has only VERTEX and POLYLINE sections.
no LINE or 3DFACE sections are present.

FACE.dxf has only one face

i used AC3D to create test models in DXF format for me

>Besides these three objects, I tried two *.dxf files. Both loaded, but
>all polygons were converted into triangles by ignoring the rest of the
>vertices, so one quad became one triangle. In one of the files, there
>was also a nonsense triangle, probably with wrong vertex coordinates.
>
i did a commit which should add quad support

>Lastly, I tested a simple textured box. I wasn't able to load it
>textured into PPE with any format. That maybe due to problems with
>either polytrans or the texture-path or the texture-format, or maybe
>with the file loaders.
>
for the file snoo-cat.bmp
at first the PLIB image loader complained about an unexpected EOF
then i converted it to a 24 bit BMP and still wouldn't load
i'll have to look into that.


--Dave