plib-devel

Re: [Plib-devel] Collision detection in PLIB/SSG

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

Sam Stickland wrote:

> Is there any support for any form of collision detection in PLIB?  I was
> thinking about maybe integrating it with one of the free ones (V-Collide,
> I-Collide, Rapid etc.).

SSG contains code to test all the polygons in the scene against either
a vector or a bounding sphere - and also a quick way to find polygons
vertically below a given 3D point.

This is a basis for doing efficient collision detection - but since the
needs of games vary greatly, I don't *directly* supply specific collision
detection.

> Does this seem a sensible thing to be doing - or are there any fundamental
> objects as to why this shouldn't be done?

Well, those other libraries won't know about SSG's scene graph structure
and are hence rather unlikely to be able to do as good a job as the
builtin routines.
 
> I also have code (from AMD's website) from 3DNow! acceleration (windows only
> unfortunately), that would be very easy to plug into SG (and I do mean very
> easy - it's just a bunch of function calls).  I'll add this next week some
> time.

Hmmm - be careful.

Taking a single 3D transform (say) and turning that into a 3DNow! instruction
sequence provides a disappointingly tiny speedup.

When Mesa added 3DNow! code like that, they got (barely) a 5% speedup.
Definitiely *NOT* worth the hassle of implementing and (especially)
supporting a machine code insert that can assemble on any machine but
which is only turned on on the right kinds of CPU.

The reason for that disappointing performance is that turning the
3DNow! engine on and off is horribly slow.

The way to get blazing speed out of 3DNow! is to queue up a large buffer
of vertices to be transformed - and to do them all in a batch without
having to turn it on and off again.  Mesa eventually needed significant
restructuring to make 3DNow! actually worthwhile.

However, something like SSG doesn't ever need to do large numbers of
consecutive transforms - most of what it's doing (that consumes
significant CPU time) is culling the database to the field of view
(or to the collision test vector/sphere).  By it's very nature,
this isn't something that is readily batch-able.

In any case, a typical SSG application on a PC without hardware T&L
spends a vast proportion of it's time inside the OpenGL library.
Hence, the only worthwhile place to look for optimisations is
either inside OpenGL - or in more subtle ways of reducing the
amount of stuff we send to OpenGL.

So, I don't think 3DNow is actually worth the maintenance hassle.
Bear in mind that it would have to compile under both Windoze and
Linux (and perhaps BSD UNIX) - that's no easy matter since the
Linux and Windoze assemblers accept different input syntax - and
even withing Windoze, some of the older MSVC versions don't know
about the 3DNow instruction mnemonics (ditto with Linux/gcc I
suspect).   Then you need runtime code to detect whether the code
is *running* on a 3DNow-capable machine.  That code has to work on
all 8086-family CPU's - but not on Alpha's and MIP's and such.

Altogether, it's a large maintenance pain with very little gain,
I think.

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

RE: [Plib-devel] Releasing PLIB 1.2 *soon*.

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

You should be able to write a script to generate a .def file from
the source tree if you really want a dll.  I've been doing this
to use Lua as a win32 dll for a while now.  Lua is pure C though,
so your script would have to be a bit more "interesting."

Paul


-----Original Message-----
From: Dave McClurg [mailto:Dav...@dy...]
Sent: Friday, March 31, 2000 11:16 AM
To: 'pli...@li...'
Subject: RE: [Plib-devel] Releasing PLIB 1.2 *soon*.


Eero wrote: 
> As the LGPL requires that the user must be able to relink 
> the application with a modified version of the library, 
> I for one will not use any LGPL libraries with my application, 
> unless they can be used as dynamically loadable libraries. 
> (which will trivially allow for the "relinking") 
> 
exactly. -sigh-. but i understand steve's point of view 
and will continue to contribute to plib. 
my choices are: 
1) supply all my object files with my release 
2) do a last minute branch of plib with DLL support 
both are not ideal but it's worth it to use PLIB 
any other suggestions? 
thanks--Dave McClurg 

RE: [Plib-devel] Releasing PLIB 1.2 *soon*.

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

Eero wrote:
> As the LGPL requires that the user must be able to relink
> the application with a modified version of the library,
> I for one will not use any LGPL libraries with my application,
> unless they can be used as dynamically loadable libraries.
> (which will trivially allow for the "relinking")
> 
exactly. -sigh-. but i understand steve's point of view
and will continue to contribute to plib.
my choices are:
1) supply all my object files with my release
2) do a last minute branch of plib with DLL support
both are not ideal but it's worth it to use PLIB
any other suggestions?

thanks--Dave McClurg

RE: [Plib-devel] Releasing PLIB 1.2 *soon*.

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

Steve Baker says:
>
> I'm really opposed to this.
> 
> 1) It makes an ugly mess of the source code.
> 
> 2) There is no sense in using PLIB as a shared library and encouraging
>    people to do so will greatly increase my maintenance burden.
> 
> Please don't add it to the CVS.

 
I agree with Steve on this.  Making shared libraries out of C++
class libraries is asking for a large amount of hurt.  Especially
with all of the SSG_API (or other) preprocessor macros that would
be required.

Paul

Re: [Plib-devel] Releasing PLIB 1.2 *soon*.

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

Steve Baker wrote:
> 
> I wanted to mention that I'd like to release PLIB 1.2 (a stable
> release) sometime soon.  I have a couple of mods of my own to
> put in - if anyone else needs to commit anything or knows of
> any significant problems that need fixing - please let me know
> so that we can arrange to catch all of these prior to release.

I'd like to add a bit of functionality to SG. I think I write it up in
no-time (but not compile it as my box is in major reordering at the
moment). Is it still possible that it makes it to 1.2?

It'd be 

void sgProjectOnVector3           ( sgVec3 dst, sgVec3 src1, sgVec3 src3
);
void sgProjectOnNormalizedVector3 ( sgVec3 dst, sgVec3 src1, sgVec3 src3
);

that projects one vector on the other and

void sgProjectOnNormal3           ( sgVec3 dst, sgVec3 src1, sgVec3 src3
);
void sgProjectOnNormalizedNormal3 ( sgVec3 dst, sgVec3 src1, sgVec3 src3
);

that maps the vector onto a plane.

I can also supply the functions for 'sgd' and perhaps other dimensions
(if that makes sense...). If the names could be differenet if that makes
more sense...

CU,
Christian

Re: [Plib-devel] Collision detection in PLIB/SSG

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

Sam Stickland wrote:
> 
> Hi,
> 
> Is there any support for any form of collision detection in PLIB?  I was
> thinking about maybe integrating it with one of the free ones (V-Collide,
> I-Collide, Rapid etc.).
> 
> Does this seem a sensible thing to be doing - or are there any fundamental
> objects as to why this shouldn't be done?

Collsion detecting was supposed to go into an additional library (e.g.
like GLU <-> OpenGL). If this additional library is SimGear (have a look
at the FlightGear project for it) or an yet to come library isn't
decided yet. But AFAIK threr's already code for it in the TUX_AQFH game.

> I also have code (from AMD's website) from 3DNow! acceleration (windows only
> unfortunately), that would be very easy to plug into SG (and I do mean very
> easy - it's just a bunch of function calls).  I'll add this next week some
> time.

This (MMX, 3DNow!, Altivec(?)... support) is something that I also want
to see... But I dunno how easy that could be handled so that it still
stays protable and readable.

CU,
Christian

[Plib-devel] Collision detection in PLIB/SSG

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

Hi,

Is there any support for any form of collision detection in PLIB?  I was
thinking about maybe integrating it with one of the free ones (V-Collide,
I-Collide, Rapid etc.).

Does this seem a sensible thing to be doing - or are there any fundamental
objects as to why this shouldn't be done?

I also have code (from AMD's website) from 3DNow! acceleration (windows only
unfortunately), that would be very easy to plug into SG (and I do mean very
easy - it's just a bunch of function calls).  I'll add this next week some
time.

Sam

Re: [Plib-devel] Releasing PLIB 1.2 *soon*.

[Eero P. <epa...@ko...>]

Steve Baker wrote:
> 
> > Dave McClurg wrote:
> 
> > Sam Stickland Wrote:
> > >The DLL changes simply require a:
> > >
> > >#ifdef WIN32
> > >    #define PU_EXPORT __dllspec(dllexport)
> > >#else
> > >    #define PU_EXPORT
> > >#endif
> 
> > I would really like to see the patch for DLL stuff make it into PLIB 1.2
> > Can I go ahead and add that?  I'll use PLIB_EXPORT instead of PU_EXPORT and
> > apply the change to all of PLIB.  Each header file would have the following:
> 
> I'm really opposed to this.
> 
> 1) It makes an ugly mess of the source code.
> 
> 2) There is no sense in using PLIB as a shared library and encouraging
>    people to do so will greatly increase my maintenance burden.
> 
> Please don't add it to the CVS.
> 
> > This is the only way i know of that a non-opensource app
> > can use PLIB under BeOS or WIN32 without creating a branch
> > which would be a headache to maintain.
> 
> That's certainly not the case.  Read the LGPL license.
> (Notice this is *L*GPL not regular GPL).
> 

As the LGPL requires that the user must be able to relink
the application with a modified version of the library,
I for one will not use any LGPL libraries with my application,
unless they can be used as dynamically loadable libraries.
(which will trivially allow for the "relinking")

If the library license is there just inorder to get
updates/fixes back to the main distribution, I presonally
don't think that LGPL is the best way of doing that.

Notice, that I am still using the old "free" version of PUI,
because I can simply compile it in. (and I did submit
at least one bug fix for it...) 



		Eero

Re: [Plib-devel] Releasing PLIB 1.2 *soon*.

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

> Dave McClurg wrote:

> Sam Stickland Wrote:
> >The DLL changes simply require a:
> >
> >#ifdef WIN32
> >    #define PU_EXPORT __dllspec(dllexport)
> >#else
> >    #define PU_EXPORT
> >#endif


> I would really like to see the patch for DLL stuff make it into PLIB 1.2
> Can I go ahead and add that?  I'll use PLIB_EXPORT instead of PU_EXPORT and
> apply the change to all of PLIB.  Each header file would have the following:

I'm really opposed to this.

1) It makes an ugly mess of the source code.

2) There is no sense in using PLIB as a shared library and encouraging
   people to do so will greatly increase my maintenance burden.

Please don't add it to the CVS.

> This is the only way i know of that a non-opensource app
> can use PLIB under BeOS or WIN32 without creating a branch
> which would be a headache to maintain.

That's certainly not the case.  Read the LGPL license.
(Notice this is *L*GPL not regular GPL).

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

Re: [Plib-devel] Releasing PLIB 1.2 *soon*.

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

> Dave McClurg wrote:

> I checked in the MSVC project files for PLIB.
> The project files I sent you are for plib_examples
> since I didn't have CVS access to that.

Ah! That explains it.

I really need to get around to putting the example progs
on CVS.  Maybe for 1.3.

> i'd like to update a few of the model loaders before the freeze.
> i'll try to wrap them up this week.

OK.  That'll be perfect.

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

RE: [Plib-devel] Releasing PLIB 1.2 *soon*.

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

Steve Baker Wrote:
> I wanted to mention that I'd like to release PLIB 1.2 (a stable
> release) sometime soon.  I have a couple of mods of my own to
> put in - if anyone else needs to commit anything or knows of
> any significant problems that need fixing - please let me know
> so that we can arrange to catch all of these prior to release.
> 

Sam Stickland Wrote:
>The DLL changes simply require a:
>
>#ifdef WIN32
>    #define PU_EXPORT __dllspec(dllexport)
>#else
>    #define PU_EXPORT
>#endif
>
>in a common header file, and then PU_EXPORT has to be added to every
>function and variable prototype/declaration (after the return type, but
>before the prototype).  And, of course, some matches project files to
>generate the DLLs (I can supply VC++ version 6) (although it's probably
best
>to supply all new project files VC++ being what it is).
>
>I can supply a patch for the DLL and .so stuff - I'm not sure if it's worth
>it for the interface resizing stuff.
>

I would really like to see the patch for DLL stuff make it into PLIB 1.2
Can I go ahead and add that?  I'll use PLIB_EXPORT instead of PU_EXPORT and
apply the change to all of PLIB.  Each header file would have the following:


/* Some compilers use a special export keyword */
#ifndef PLIB_EXPORT
# ifdef __BEOS__
#  if defined(__GNUC__)
#   define PLIB_EXPORT     __declspec(dllexport)
#  else
#   define PLIB_EXPORT     __declspec(export)
#  endif
# else
# ifdef WIN32
#  define PLIB_EXPORT      __declspec(dllexport)
# else
#  define PLIB_EXPORT
# endif
# endif
#endif


This is the only way i know of that a non-opensource app
can use PLIB under BeOS or WIN32 without creating a branch
which would be a headache to maintain.

--Dave McClurg

Re: [Plib-devel] DXF R12 Polyline question

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

Dave McClurg <Dav...@dy...> wrote:

>chair should load fine now wolfram.

Great! I tried it.
So, all the DXF-bugs I know of (apart from the one in the DXF-writer)
are solved.


Bye bye,
Wolfram

[Plib-devel] OBJ loader

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

Bill Weiland2 wrote:
> 
> Yes, actually I saw Dave's messages about OBJ well after he had
> committed the code; I had some other diversions, but I still need an OBJ
> loader that does textures, so I will do it.  The only question is
> whether I should just dump my version and add textures to Dave's loader,
> or continue with mine.
 
I need an OBJ loader too.  It seems like the easiest way to get a textured
model out of rhino 3d.
 
Should I take a shot at adding textures to ssgLoadOBJ
or are you already part way there?
 
--Dave McClurg

RE: [Plib-devel] DXF R12 Polyline question

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

ack. i was thinking grid = 2d.  ok all fixed now.
DXF changes committed to CVS.
 
chair should load fine now wolfram.

oops. there are 8x4 = 32 vertex entities supplied so i guess i don't
need size or spacing.  still don't know what "closure" means. anyone
want to guess?

I would like to support a special type of DXF POLYLINE entity 
in PLIB called a polygon MxN mesh. 

This is a uniform grid of 3d polygons with optional closure 
of the mesh in the M, N or M&N directions. 

RE: [Plib-devel] DXF R12 Polyline question

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

oops. there are 8x4 = 32 vertex entities supplied so i guess i don't
need size or spacing.  still don't know what "closure" means. anyone
want to guess?

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Dave McClurg
Sent: Wednesday, March 29, 2000 10:52 AM
To: 'pli...@li...'
Subject: [Plib-devel] DXF R12 Polyline question



I would like to support a special type of DXF POLYLINE entity 
in PLIB called a polygon MxN mesh. 

This is a uniform grid of 3d polygons with optional closure 
of the mesh in the M, N or M&N directions. 

The following fragment is from a chair DXF file that Wolfram 
gave me and defines a 8 x 4 polygon mesh closed in the M direction. 

Can anyone tell me how to determine the spacing and size of the grid. 
I'm not sure how to generate triangles from this. 

VPORT defines 

 15 
0.1 
 25 
0.1 

which could indicate grid spacing but does that apply to all grids 
in the file?  even so, what is the size of the grid? are the vertex 
coords in the polyline the center or side of the grid?  what does 
closed mean?  hmmmm. 

I can send you the entire DXF if interested.  I've looked through 
several DXF specs online but I'm kind of stumped right now. 

Thanks, 
--Dave McClurg 

POLYLINE 
  8 
LEG 
 66 
     1 
 10 
0.0 
 20 
0.0 
 30 
0.0 
 70 
    17 
 71 
     8 
 72 
     4 
  0 
VERTEX 
  8 
LEG 
 10 
-1.623306 
 20 
12.662745 
 30 
-16.954128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.623306 
 20 
12.514997 
 30 
-16.954128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.623306 
 20 
12.514997 
 30 
-17.454128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.623306 
 20 
12.662745 
 30 
-17.454128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.623306 
 20 
12.662745 
 30 
-16.954128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.727779 
 20 
12.558272 
 30 
-16.954128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.727779 
 20 
12.558272 
 30 
-17.454128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.623306 
 20 
12.662745 
 30 
-17.454128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.623306 
 20 
12.662745 
 30 
-16.954128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.771053 
 20 
12.662745 
 30 
-16.954128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.771053 
 20 
12.662745 
 30 
-17.454128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.623306 
 20 
12.662745 
 30 
-17.454128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.623306 
 20 
12.662745 
 30 
-16.954128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.727779 
 20 
12.767218 
 30 
-16.954128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.727779 
 20 
12.767218 
 30 
-17.454128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.623306 
 20 
12.662745 
 30 
-17.454128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.623306 
 20 
12.662745 
 30 
-16.954128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.623306 
 20 
12.810492 
 30 
-16.954128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.623306 
 20 
12.810492 
 30 
-17.454128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.623306 
 20 
12.662745 
 30 
-17.454128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.623306 
 20 
12.662745 
 30 
-16.954128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.518833 
 20 
12.767218 
 30 
-16.954128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.518833 
 20 
12.767218 
 30 
-17.454128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.623306 
 20 
12.662745 
 30 
-17.454128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.623306 
 20 
12.662745 
 30 
-16.954128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.475559 
 20 
12.662745 
 30 
-16.954128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.475559 
 20 
12.662745 
 30 
-17.454128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.623306 
 20 
12.662745 
 30 
-17.454128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.623306 
 20 
12.662745 
 30 
-16.954128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.518833 
 20 
12.558272 
 30 
-16.954128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.518833 
 20 
12.558272 
 30 
-17.454128 
 70 
    64 
  0 
VERTEX 
  8 
LEG 
 10 
-1.623306 
 20 
12.662745 
 30 
-17.454128 
 70 
    64 
  0 
SEQEND 

[Plib-devel] DXF R12 Polyline question

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

I would like to support a special type of DXF POLYLINE entity
in PLIB called a polygon MxN mesh.

This is a uniform grid of 3d polygons with optional closure
of the mesh in the M, N or M&N directions.

The following fragment is from a chair DXF file that Wolfram
gave me and defines a 8 x 4 polygon mesh closed in the M direction.

Can anyone tell me how to determine the spacing and size of the grid.
I'm not sure how to generate triangles from this.

VPORT defines

 15
0.1
 25
0.1

which could indicate grid spacing but does that apply to all grids
in the file?  even so, what is the size of the grid? are the vertex
coords in the polyline the center or side of the grid?  what does
closed mean?  hmmmm.

I can send you the entire DXF if interested.  I've looked through
several DXF specs online but I'm kind of stumped right now.

Thanks,
--Dave McClurg

POLYLINE
  8
LEG
 66
     1
 10
0.0
 20
0.0
 30
0.0
 70
    17
 71
     8
 72
     4
  0
VERTEX
  8
LEG
 10
-1.623306
 20
12.662745
 30
-16.954128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.623306
 20
12.514997
 30
-16.954128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.623306
 20
12.514997
 30
-17.454128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.623306
 20
12.662745
 30
-17.454128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.623306
 20
12.662745
 30
-16.954128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.727779
 20
12.558272
 30
-16.954128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.727779
 20
12.558272
 30
-17.454128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.623306
 20
12.662745
 30
-17.454128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.623306
 20
12.662745
 30
-16.954128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.771053
 20
12.662745
 30
-16.954128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.771053
 20
12.662745
 30
-17.454128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.623306
 20
12.662745
 30
-17.454128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.623306
 20
12.662745
 30
-16.954128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.727779
 20
12.767218
 30
-16.954128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.727779
 20
12.767218
 30
-17.454128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.623306
 20
12.662745
 30
-17.454128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.623306
 20
12.662745
 30
-16.954128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.623306
 20
12.810492
 30
-16.954128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.623306
 20
12.810492
 30
-17.454128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.623306
 20
12.662745
 30
-17.454128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.623306
 20
12.662745
 30
-16.954128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.518833
 20
12.767218
 30
-16.954128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.518833
 20
12.767218
 30
-17.454128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.623306
 20
12.662745
 30
-17.454128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.623306
 20
12.662745
 30
-16.954128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.475559
 20
12.662745
 30
-16.954128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.475559
 20
12.662745
 30
-17.454128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.623306
 20
12.662745
 30
-17.454128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.623306
 20
12.662745
 30
-16.954128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.518833
 20
12.558272
 30
-16.954128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.518833
 20
12.558272
 30
-17.454128
 70
    64
  0
VERTEX
  8
LEG
 10
-1.623306
 20
12.662745
 30
-17.454128
 70
    64
  0
SEQEND

RE: [Plib-devel] Releasing PLIB 1.2 *soon*.

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

> > I am a bit confused about this..
> > The MSVC project files in CVS work well.
> 
> Oh?  Now I'm puzzled.  Maybe Dave checked in those files himself.
> 
> I'll check *carefully* before I mess with it.
> 
Hi Steve,
I checked in the MSVC project files for PLIB.
The project files I sent you are for plib_examples
since I didn't have CVS access to that.

> > You will base 1.2 on what is in CVS, wont you?
> 
> Absolutely...but since it's a CVS and can potentially be changed
> right up to the last 10 seconds before I make an official 1.2
> release out of it - I need to be sure that everyone can agree on
> a short-term "feature" freeze while the last few wrinkles are
> ironed out.
>
i'd like to update a few of the model loaders before the freeze.
i'll try to wrap them up this week.

--Dave McClurg

Re: [Plib-devel] Releasing PLIB 1.2 *soon*.

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

Wolfram Kuss wrote:
> 
> Steve Baker <sjb...@ai...> wrote:
> 
> >- we got
> >away without any damage at all -
> 
> Good!
> 
> >The things I *know* I have to do for 1.2 are all pretty
> >minor:
> >
> >* Add Dave McClurgs' Windoze/MSVC project files.
> 
> I am a bit confused about this..
> The MSVC project files in CVS work well.

Oh?  Now I'm puzzled.  Maybe Dave checked in those files himself.

I'll check *carefully* before I mess with it.

> You will base 1.2 on what is in CVS, wont you?

Absolutely...but since it's a CVS and can potentially be changed
right up to the last 10 seconds before I make an official 1.2
release out of it - I need to be sure that everyone can agree on
a short-term "feature" freeze while the last few wrinkles are
ironed out.

> Daves newest additions to the CVS repository regarding DXF-files are
> cool.

Yes - I was using it to view the plans of my house in PPE!
(Our architect kindly provided the CAD files)  I need to get
PPE's extrude code working so I can turn them into a 3D model :-)

> >* If I have time, I'll try to do something about the
> >  GL_COLOR_MATERIAL problem that Curt has been concerned
> >  about...
> 
> This is the same problem that PPE has sometimes with the grid looking
> shaded/lighted, is it not?
> On my home system with new Voodoo-3-drivers this problem is
> reproducable. It depends on the mode you are in, wireframe or filled.

Yes - it shows up in a few places in my Tux game too.

I think these are all symptoms of the same problem.

The problem is that all these cases are too complex to track down
what's going on.  I really need to write some stand-alone OpenGL
programs that do essentially what I think SSG is doing and see
if those work.  That'll help me to see if I have a misunderstanding
of the OpenGL Spec, or if one or more implementations are broken,
or whether there is a simple bug in SSG such that it isn't doing
what I think it is.

The glColorMaterial API isn't all that well described and quite a
few of the OpenGL Guru's out there cannot agree on what it's *supposed*
to do under some of the situations that can arise in SSG.  If the
guys who wrote the OpenGL spec can't agree then there is little chance
of all the implementations out there getting it right.

As always, if Quake doesn't use it - all bets are off.

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

Re: [Plib-devel] Releasing PLIB 1.2 *soon*.

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

Per Liedman wrote:

> Well, the 3ds-stuff is still broken when it comes to textures, but
> currently I can't work on it since my system refuses to display textures
> in *any* OpenGL program - I'm really starting to hate this nvidia/glx
> stuff. I will try to fix it as soon as I get my system working, but if
> anyone else want to look at it before the release, go ahead.
> 
> (If somebody has any clue to why I get a GLXBadRenderRequest in
> GLXRenderLarge, even after reinstalling my old XF86_SVGA, glx.so and
> libGL.so.1.0, which seemed to work fine before, would you please mail
> me? I should have known better than installing new untested drivers...)

I have no clue about *that* - if I were you, I'd restore the X-win version
of Mesa rather than messing with the SVGA version - which isn't exactly
well maintained these days.

I did get this encouraging message about nVidia drivers a couple of
weeks ago.  Dunno if it's of any help:

> ---------- Forwarded message ----------
> Date: Tue, 7 Mar 2000 21:58:18 -0000
> From: Allen <al...@cl...>
> Reply-To: me...@iq...
> To: me...@iq...
> Subject: [mesa] GeForce256 X GLX
> 
> For all those who have tried to get this to work (both the Nvidia binaries
> and building from source), you can try the version I built, it does work,
> but as they said it ain't about to set any new speed records. It was built
> on a RH6.1 system. Give it a shot. I would like to know if it works with the
> Riva128,TNT and TNT2. I think it should.
> 
> www.clarke-aj.freeserve.co.uk
> 
> Allen.

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

Re: [Plib-devel] Releasing PLIB 1.2 *soon*.

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

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

>- we got
>away without any damage at all - 

Good!

>The things I *know* I have to do for 1.2 are all pretty
>minor:
>
>* Add Dave McClurgs' Windoze/MSVC project files.

I am a bit confused about this..
The MSVC project files in CVS work well.
You will base 1.2 on what is in CVS, wont you?
Daves newest additions to the CVS repository regarding DXF-files are
cool.


>* If I have time, I'll try to do something about the
>  GL_COLOR_MATERIAL problem that Curt has been concerned
>  about...

This is the same problem that PPE has sometimes with the grid looking
shaded/lighted, is it not?
On my home system with new Voodoo-3-drivers this problem is
reproducable. It depends on the mode you are in, wireframe or filled.

Bye bye,
Wolfram.

Re: [Plib-devel] Releasing PLIB 1.2 *soon*.

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

Steve Baker wrote:
> I wanted to mention that I'd like to release PLIB 1.2 (a stable
> release) sometime soon.  I have a couple of mods of my own to
> put in - if anyone else needs to commit anything or knows of
> any significant problems that need fixing - please let me know
> so that we can arrange to catch all of these prior to release.

Well, the 3ds-stuff is still broken when it comes to textures, but
currently I can't work on it since my system refuses to display textures
in *any* OpenGL program - I'm really starting to hate this nvidia/glx
stuff. I will try to fix it as soon as I get my system working, but if
anyone else want to look at it before the release, go ahead.

(If somebody has any clue to why I get a GLXBadRenderRequest in
GLXRenderLarge, even after reinstalling my old XF86_SVGA, glx.so and
libGL.so.1.0, which seemed to work fine before, would you please mail
me? I should have known better than installing new untested drivers...)

Best regards,
Per Liedman

-- 
===========================================================================
Per Liedman                                       
md...@md...
Nilssonsberg 7                       
http://www.mdstud.chalmers.se/~md6pl/
411 43 Göteborg                               tel: 031-825659 /
0705-520455
===========================================================================

[Plib-devel] Releasing PLIB 1.2 *soon*.

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

Well, the tornado(s) that took out downtown FortWorth earlier this
evening passed about four miles to the North of my home - we got
away without any damage at all - pretty awesome stuff though.

I wanted to mention that I'd like to release PLIB 1.2 (a stable
release) sometime soon.  I have a couple of mods of my own to
put in - if anyone else needs to commit anything or knows of
any significant problems that need fixing - please let me know
so that we can arrange to catch all of these prior to release.

Pretty much as soon as PLIB 1.2 is out, I'll make a 1.3
(unstable/development) release for ongoing changes.

The only changes to 1.2 after release will be bug fixes.

The things I *know* I have to do for 1.2 are all pretty
minor:

* Add Dave McClurgs' Windoze/MSVC project files.
* If I have time, I'll try to do something about the
  GL_COLOR_MATERIAL problem that Curt has been concerned
  about...but I don't have a lot of time - so we may be
  out of luck right now for 1.2.0 - that doesn't preclude
  a fix in 1.2.1 if we find that problem after 1.2.0 the
  release.
* Loring Holden's fix to enable things to compile on
  Solaris and AIX.
* Darrell Walisser's fixes for CodeWarrior on MacOS.

Ah - the Joys of Portability!   :-)

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

[Plib-devel] dxf polyline support

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

I did a PLIB cvs commit to fix dxf polyline support.
 
Wolfram- that 550.dxf model looks right now.
looks like a building just like in 3d Explorer.
also, i found a dolphin with polyline that looks
correct too.
 
Let me know if there are any DXF bugs/issues remaining.
 
--Dave McClurg
 

Re: [Plib-devel] Importers/Exporters

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

Wolfram Kuss wrote:
> 
> 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 ;

Yep - good idea.

You still need to check the return result and pop up a dialog box
if it returns FALSE though.

I've just committed that change...go grab a copy from CVS.

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

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

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

Hi,


>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.


Yes, that's what I was hoping to do.  It's just a pet-project of mine that I
would open source but as it's a multi-player network game I fear there could
be issues with security on the network.  (Yes, I know all the arguments
about security through obsurity is no security is no security at all, et
all.. I'd be happy to discuss the situation with people but it's not really
on topic for this list).

>> 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.


It's not actually that much.  Here's the changes for the interface scaling:

Make puGetWindowHeight(...) and puGetWindowWidth(...) return puWindowHeight
and puWindowWidth (rather than using glutGet().  This is like the
PU_NOT_USING_GLUT version.

Put a puSetWindowSize(...) in prototype in pu.h.

And that's it.  Make sure you can puSetWindowSize before you do any
puDisplay calls and you're away.  (I skip puDisplay completely and setup the
opengl state myself)

Minimal changes that should probably be wrapped up into #ifdef
PU_INTERFACE_RESIZING or something.

The DLL changes simply require a:

#ifdef WIN32
    #define PU_EXPORT __dllspec(dllexport)
#else
    #define PU_EXPORT
#endif

in a common header file, and then PU_EXPORT has to be added to every
function and variable prototype/declaration (after the return type, but
before the prototype).  And, of course, some matches project files to
generate the DLLs (I can supply VC++ version 6) (although it's probably best
to supply all new project files VC++ being what it is).

I can supply a patch for the DLL and .so stuff - I'm not sure if it's worth
it for the interface resizing stuff.

I can't seem to get anonymous access (for read-only), on the plib cvs store
btw.  Wincvs reports no recognised user "anonymous".  Any ideas?

Sam