plib-devel

RE: [Plib-devel] texture support for ssgLoadOBJ

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

> >I added texture support to the Wavefront OBJ loader.

Wolfram wrote:
> I tried it on some files of my own, but due to lots of problems,
> (most ?) unrelated to the *.obj-loader didnt succeed (yet).
send me any OBJ files that don't work

> - I had a texture with a size that is not a power of two.
> plib complained (map is not a power-of-two in size)
> and exits the program!
i'll track that down if you want to send me the texture

--
Dave McClurg

Re: [Plib-devel] texture support for ssgLoadOBJ

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

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

>I added texture support to the Wavefront OBJ loader.
>OBJ is a nice simple ascii format that glTron uses
>Wolfram-- it loads testq.obj/testq.mtl

Great!

I tried it on seom files of my own, but due to lots of problems,
(most ?) unrelated to the *.obj-loader didnt succeed (yet).
- PPE seems to render everything white now?
- PPE doesnt seem to light anymore?
- Has somebody changed the workings of the keyflyer?
Its seems to me, that it used to rotate around local axis,
but now rotates around global axis.
- I had a texture with a size that is not a power of two.
plib complained (map is not a power-of-two in size)
and exits the program!


>Anyone need 3DSMAX ASE parent/anim support
>before 1.2 is released?

I agree with Steve that this isnt as important as texture-support.
For me personally, parent support (=hierchies?) sounds good,
anim support is not important for me.

>--Dave McClurg

Bye bye,
Wolfram.

[Plib-devel] ROAM for plib

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

Hi,

There's a good article on www.gamasutra.com on Adaptive LOD terrian using
ROAM.  Up until now my program has been using a naff quadtree implementation
written by me, and I'm convinced enough to move to this implementation.

I'm almost certainly going to move my project over to SSG (since it doesn't
use any Scene graph at all at the moment).

So I'm thinking that I could rework ROAM landscape's into the SSG API as a
couple of extra classes.  Would this be useful, or do you want this sort of
extra complexity kept out of it?

Sam

Re: [Plib-devel] Double-sided material fix to 3DS loader for

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

> Per Liedman writes:
> > By the way, I use a modified version of the tux_example to test the
> > 3ds-loader, and have stumbled across something I think is sort of
> > odd. If I load one of the models supplied by Wolfram Kuss (550.3ds),
> > it looks what I think it should look like (a large building), but if
> > I also load the pedestal model from the original tux_example, the
> > whole building turns white (no lighting or anything)!  Any
> > suggestions to what might cause this? (The loader does not use
> > GL_COLOR_MATERIAL, if that is of any interest.)

Curtis L. Olson writes:
> I've noticed similar behavior with ssg ... I've never been able to get
> an ssgSimpleState to work consistantly if it doesn't use
> gl_color_material and if it doesn't have a texture.  I've seen this
> enough times to speculate that either:
> 
> a) there is some state changing bug in ssg
> 
> b) there is some non-obvious thing that needs to get done to make this
> work right

Just in case what I wrote was confusing.  If I'm trying to create a
simplestate that sets material properties without enabling
gl_color_material and at the same time doesn't have a texture applied,
then I see really inconsistant results ... it will work at times and
not work at times depending on view direction and position.  Work
being defined as I get what I think I should get, and not-work being
defined as I get an all white shaded surface.  My guess is that as
various objects are culled or drawn, this has a side effect on the
objects in question so that sometimes they are rendered correctly, and
sometimes not.

Curt.
-- 
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] Double-sided material fix to 3DS loader for

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

1.2
In-Reply-To: <00040323290000.00283@agnes>
References: <01B...@nt...>
        <00040323290000.00283@agnes>
X-Mailer: VM 6.75 under Emacs 19.34.1

Per Liedman writes:
> By the way, I use a modified version of the tux_example to test the
> 3ds-loader, and have stumbled across something I think is sort of
> odd. If I load one of the models supplied by Wolfram Kuss (550.3ds),
> it looks what I think it should look like (a large building), but if
> I also load the pedestal model from the original tux_example, the
> whole building turns white (no lighting or anything)!  Any
> suggestions to what might cause this? (The loader does not use
> GL_COLOR_MATERIAL, if that is of any interest.)

I've noticed similar behavior with ssg ... I've never been able to get
an ssgSimpleState to work consistantly if it doesn't use
gl_color_material and if it doesn't have a texture.  I've seen this
enough times to speculate that either:

a) there is some state changing bug in ssg

b) there is some non-obvious thing that needs to get done to make this
work right

Curt.
--
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt
http://www.flightgear.org

Re: [Plib-devel] Double-sided material fix to 3DS loader for 1.2

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

On Mon, 03 Apr 2000, Paolo Leoncini wrote:
> 
> Dear Steve & Per,
> 
> hoping to be in time for 1.2, here is the result of further bug-fixing on the 3DS loader.
> This fixes the management of double-sided material tris:
> [...]

Nice to see that someone else is also looking into this. I still haven't got
textures on my "real" machine, so I'm stuck with my old P166 for debugging
the 3ds-loader, and for some reason I never get around to boot it... ;-) (It's
amazing how fast you become used to a P3-500.)

By the way, I use a modified version of the tux_example to test the 3ds-loader,
and have stumbled across something I think is sort of odd. If I load one of the
models supplied by Wolfram Kuss (550.3ds), it looks what I think it should look
like (a large building), but if I also load the pedestal model from the
original tux_example, the whole building turns white (no lighting or anything)!
Any suggestions to what might cause this? (The loader does not use
GL_COLOR_MATERIAL, if that is of any interest.)

The other models Wolfram sent to me doesn't work at all, so I should be doing
lots of work now! :-)

Regards,
Per Liedman

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

Re: Vertex submission (was Re: [Plib-devel] Re: 3DNow! acceleration)

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

-----Original Message-----
From: Steve Baker <sjb...@ai...>
To: pli...@li... <pli...@li...>
Date: 04 April 2000 00:18
Subject: Re: Vertex submission (was Re: [Plib-devel] Re: 3DNow!
acceleration)


>Sam Stickland wrote:
>
>> How about how the vertexes are submitted?  Am I right in thinking that
>> currently ssgVTable simply does glBegin's and glEnd's on the vertex
>> information?  I assume there could be some big wins here if we started
using
>> CVA's (or even just vertex arrarys?) ?.
>>
>> Or is the idea for people to create subclasses of VTable to fix the
>> situations as neccessary?
>
>I intend to write a CVA or VA class at some time in the future - but I'm
>just so short of free time right now that it's not going to happen for a
>while.


Well I have some time :)

>I don't think it's hard to do though - if you'd like to contribute a
>suitable class, I'd be VERY happy to accept it.
>
>Since CVA's are only an extension to OpenGL, we'd have to conditionally
>fall back on VA's on platforms that don't support them.  That being the
>case, we probably only need one class - I don't think there are many
>cases where people would want simple VA's if CVA's are available.


Makes sense.

To get the best speed out of CVA's won't it need some adjustment to the
scene graph traversal?  Say we had this structure:


             Transform Node                    Transform Node
                           |                                            |
                           +------- CVA Node ---------+

Then you'd want to lock the arrarys, draw the CVA Node in both positions and
then unlock it - rather than locking it twice.

I guess this might start to get a little to complex, particulary if you
start to factor in different states.

Sam

Re: Vertex submission (was Re: [Plib-devel] Re: 3DNow! acceleration)

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

> Dave McClurg wrote:

> Vertex arrays would be very helpful!!!

Well, they'll speed things up somewhat.
 
> i need vertex arrays for the loaders i'm working on
> if someone writes ssgVArrayTable, I can update the loaders

Yep.
 
> OBJ and ASE always use vertex arrays.
> DXF polyface meshes use them too

AC3D does too...and SSG doesn't care.

> vertex arrays will make the scene graphs generated by
> these loaders more efficient to render.  right now,
> i create 24 vertices for a cube when i should only
> create 8 (with vertex array support).

Well, you don't need 24 vertices - 16 is enough if
you build it with two triangle strips.

The current ssgVtxTable comes pretty close to storing
the data you need for CVA's - so deriving a CVA class
from it should be really easy.

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

Re: [Plib-devel] texture support for ssgLoadOBJ

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

> Dave McClurg wrote:
> 
> I added texture support to the Wavefront OBJ loader.
> OBJ is a nice simple ascii format that glTron uses
> Wolfram-- it loads testq.obj/testq.mtl
> 
> Anyone need 3DSMAX ASE parent/anim support
> before 1.2 is released?

I need 1.2 to be stable.  So, I think we should leave
out any new FEATURES at this stage.  Getting texture
working was really necessary - but I think the rest
can wait for 1.3.

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

RE: Vertex submission (was Re: [Plib-devel] Re: 3DNow! accelerati on)

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

Vertex arrays would be very helpful!!!

i need vertex arrays for the loaders i'm working on
if someone writes ssgVArrayTable, I can update the loaders

OBJ and ASE always use vertex arrays.
DXF polyface meshes use them too

vertex arrays will make the scene graphs generated by
these loaders more efficient to render.  right now,
i create 24 vertices for a cube when i should only
create 8 (with vertex array support).

--Dave McClurg

Re: [Plib-devel] Double-sided material fix to 3DS loader for 1.2

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

Paolo Leoncini wrote:

> hoping to be in time for 1.2...

Yep - you made it in time (courtesy of the sgMultMat4 panic!)

>, here is the result of further bug-fixing on the 3DS loader.
> This fixes the management of double-sided material tris:
> 
> function parse_face_materials():
> ...
>       if (is_ds) {
>         num_texcrds = 6;
>         sgCopyVec2( texcrds[texcrd_count + 3], texcrd_list[ vertex_index[v1] ] );
>         sgCopyVec2( texcrds[texcrd_count + 4], texcrd_list[ vertex_index[v3] ] );
>         sgCopyVec2( texcrds[texcrd_count + 5], texcrd_list[ vertex_index[v2] ] );
>       }
> ...
> instead of the index sequence v1, v2, v3. This is now in agreement with what
> done to vertices/normals some code line below.


Is anyone else committing this?   If not, I'll do it.

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

Re: Vertex submission (was Re: [Plib-devel] Re: 3DNow! acceleration)

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

Sam Stickland wrote:

> How about how the vertexes are submitted?  Am I right in thinking that
> currently ssgVTable simply does glBegin's and glEnd's on the vertex
> information?  I assume there could be some big wins here if we started using
> CVA's (or even just vertex arrarys?) ?.
> 
> Or is the idea for people to create subclasses of VTable to fix the
> situations as neccessary?

I intend to write a CVA or VA class at some time in the future - but I'm
just so short of free time right now that it's not going to happen for a
while.

I don't think it's hard to do though - if you'd like to contribute a
suitable class, I'd be VERY happy to accept it.

Since CVA's are only an extension to OpenGL, we'd have to conditionally
fall back on VA's on platforms that don't support them.  That being the
case, we probably only need one class - I don't think there are many
cases where people would want simple VA's if CVA's are available.

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

Re: [Plib-devel] Sorting transparent polygons front to back?

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

Sam Stickland wrote:

> Are transparent or translucsant polygons sorted front to back in SSG?

No.

The only thing I do is to render all translucent polygons after all opaque
ones.

The problem is that there is no way to sort polygons front-to-back without
potentially having to chop them into pieces:

               /\    /\
              /  \  /  \
              \   \/   /
               \   \  /
                \   \/
                /\   \
               /  \   \
              /   /\   \
          ___/   /__\___\___
         |  /   /           |
         |_/   /____________|
          /___/       \___\

Ha!!  Sort *that*!

It's really even deeper than that.  Sorting by depth tends to cause
much more ssgState switching - which does bad things to performance.
It may also require me to split triangle strips and fans into triangles,
do multiple calls to the same Draw callbacks...it's gets VERY ugly.

So, since I can't do a great job, I decided to do nothing...sorry.

There are a number of things that simple games can do to eliminate
transparency ordering issues...but I'm afraid PLIB doesn't do much
to help.

On the bright side, look at my Tux_AQFH game - you almost never notice
hidden surface errors - despite numerous shadows, trees, herring,
lightning bolts, translucent ocean, translucent flippers on Tux, etc.

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

[Plib-devel] texture support for ssgLoadOBJ

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

I added texture support to the Wavefront OBJ loader.
OBJ is a nice simple ascii format that glTron uses
Wolfram-- it loads testq.obj/testq.mtl

Anyone need 3DSMAX ASE parent/anim support
before 1.2 is released?

--Dave McClurg

[Plib-devel] Double-sided material fix to 3DS loader for 1.2

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

Dear Steve & Per,

hoping to be in time for 1.2, here is the result of further bug-fixing on the 3DS loader.
This fixes the management of double-sided material tris:

function parse_face_materials():
...
      if (is_ds) {
        num_texcrds = 6;
        sgCopyVec2( texcrds[texcrd_count + 3], texcrd_list[ vertex_index[v1] ] );
        sgCopyVec2( texcrds[texcrd_count + 4], texcrd_list[ vertex_index[v3] ] );
        sgCopyVec2( texcrds[texcrd_count + 5], texcrd_list[ vertex_index[v2] ] );
      }
...
instead of the index sequence v1, v2, v3. This is now in agreement with what done to vertices/normals some code line below.


-----------------------------------------------------------------------------
Paolo Leoncini				phone:  +39 (0823) 623134
Scientific Visualization Group			fax:    +39 (0823) 623126
CIRA - Italian Center for Aerospace Research	e-mail: p.l...@ci...
Via Maiorise - 81043 Capua (CE) Italy		http://www.cira.it/research/vis

Vertex submission (was Re: [Plib-devel] Re: 3DNow! acceleration)

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

-----Original Message-----
From: Steve Baker <sjb...@ai...>
To: pli...@li... <pli...@li...>
Date: 02 April 2000 21:00
Subject: Re: [Plib-devel] Re: 3DNow! acceleration


>Sam Stickland wrote:
>
>> Surely to do the field of view cull you have to transform every vertex in
>> the scene by the modelview matrix?
>
>No - I only cull using bounding spheres - and only at the level of
>entire ssgLeaf nodes.
>
>There is no point in culling down to the individual polygon level
>because OpenGL is already doing that - and possibly can use hardware
>to accellerate that process.


Yes, that makes a lot of sense now I actually stop to think about it.. :)

>>  Isn't this the sort of thing that 3DNow!
>> could really speed up?
>
>If I did that - then you'd be right - and 3DNow! would be important.
>
>...but I don't so you aren't and it isn't.  :-)


Heh..

>> AMD provide code to detect whether 3DNow! acceleration is supported (this
>> works on all x86 processors), as well as code to detect MMX and SSE
>> instructions.  Turning it off on non x86 processors could be easily done
as
>> a compile time option, although I'm sure there are ways of detecting this
at
>> run-time (but that's probably a bit of a kludge).
>
>But there is still the issue of how to assemble that code portably.
>
>There are two different (and incompatible) assemblers for Linux/x86 and
>yet a different syntax for Windoze - then some of the older versions of
>those assemblers don't know about the 3DNow mnemonics.   I see the hassles
>Mesa has been having with this - and I don't want to follow in their
>footsteps unless there is a HUGE benefit in so doing.


OK...

How about how the vertexes are submitted?  Am I right in thinking that
currently ssgVTable simply does glBegin's and glEnd's on the vertex
information?  I assume there could be some big wins here if we started using
CVA's (or even just vertex arrarys?) ?.

Or is the idea for people to create subclasses of VTable to fix the
situations as neccessary?

Sam

[Plib-devel] Sorting transparent polygons front to back?

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

Hi,

Are transparent or translucsant polygons sorted front to back in SSG?  I dug
through the source a bit and came across the SetTranslucant (sic) and the
Get method but they didn't appear to be called anyway else, so?

I suppose I really ought to knock up a quick test program, but I'm at work
at the moment, and I supposed to be writing some PHP instead....

Sam

Re: [Plib-devel] Re: 3DNow! acceleration

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

Sam Stickland wrote:

> Surely to do the field of view cull you have to transform every vertex in
> the scene by the modelview matrix?

No - I only cull using bounding spheres - and only at the level of
entire ssgLeaf nodes.

There is no point in culling down to the individual polygon level
because OpenGL is already doing that - and possibly can use hardware
to accellerate that process.

>  Isn't this the sort of thing that 3DNow!
> could really speed up?

If I did that - then you'd be right - and 3DNow! would be important.

...but I don't so you aren't and it isn't.  :-)

> AMD provide code to detect whether 3DNow! acceleration is supported (this
> works on all x86 processors), as well as code to detect MMX and SSE
> instructions.  Turning it off on non x86 processors could be easily done as
> a compile time option, although I'm sure there are ways of detecting this at
> run-time (but that's probably a bit of a kludge).

But there is still the issue of how to assemble that code portably.

There are two different (and incompatible) assemblers for Linux/x86 and
yet a different syntax for Windoze - then some of the older versions of
those assemblers don't know about the 3DNow mnemonics.   I see the hassles
Mesa has been having with this - and I don't want to follow in their
footsteps unless there is a HUGE benefit in so doing.

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

[Plib-devel] Re: 3DNow! acceleration

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

----- Original Message -----
From: Steve Baker <sjb...@ai...>
To: <pli...@li...>
Sent: Saturday, April 01, 2000 6:07 AM
Subject: Re: [Plib-devel] Collision detection in PLIB/SSG


> Sam Stickland wrote:

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

Surely to do the field of view cull you have to transform every vertex in
the scene by the modelview matrix?  Isn't this the sort of thing that 3DNow!
could really speed up? (You can just leave the modelview matrix in the
required registers and push through all the vertices really quick).

Or perhaps this kind of approach isn't suited to PLIB?

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

AMD provide code to detect whether 3DNow! acceleration is supported (this
works on all x86 processors), as well as code to detect MMX and SSE
instructions.  Turning it off on non x86 processors could be easily done as
a compile time option, although I'm sure there are ways of detecting this at
run-time (but that's probably a bit of a kludge).

Sam

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

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

Steve Baker wrote:
> 
> A not-normalized normal is a vector and a normalized vector is
> a normal - so I find the names a bit confusing.

A normal is a vector that decribes the 'direction' of a plane. So if
  you have got a 4th number you could write the plane equation 
  (A x1 + B x2 + C x3 + D = 0 with A, B and C defining the normal)

A normalized vector is a unit vector (i.e. legth == 1.0).

This was that I thought of. But you are right it's confusing, it
should be e.g. sgProjectOnUnitVector3

> I'm not quite sure what you intend these to do

With this misunderstanding it's obvious that you don't know it...

> but how about
> 
> sgProjectVec3OntoPlane

this would be the sgProjectOnNormal3 as the normal is defining the plane

> sgProjectNormal3OntoPlane

this wouldn't make sense as the resuld would be a zero vector...

Yesterdy I've sent you the code (+ a patch a short time after I've sent
the code) privately. It comes with descriptions of the functions. But
please change the names to something less confusing (and update the
CVS as I don't have SSH). For the interested here are the descriptions:

// sgProjectOn[Normalized]VecX ( sgVecX dst, const sgVecX src1, const
sgVecX src2 )
// 
// calculate the projection of src2 onto src1:
//         _ 
//         /|
//  src2 /  :
//     /    :
//   /      :
//  -------->-------------->
//     dst      src1
//
//        src1 o src2
//  dst = ----------- * src1
//        ( src1 )^2


// sgProjectOnNormal3 ( sgVec3 dst, const sgVec3 src1, const sgVec3 src2
)
//
// calculate the projection of src2 onto a plane that is specified by
src1,
// its normal vector
//
// This works by calculating temp, a vector that lies on the plane and
has the
// direction of the projected vector and then do the same stuff as above
//
//                                      temp o src2
// temp = ( src1 x src2 ) x src1; dst = ----------- * temp
//                                      ( temp )^2

CU,
Christian

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

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

Steve Baker wrote:
> 
> Eero Pajarre wrote:
> >
> > Steve Baker wrote:
> > >
> >
> > > So, if the library is a DLL, he can do that - but there is a
> > > good chance that if he does, the program will crash because
> > > of the C++ issues.
> > >
> >
> > I really don't yet know if this would work. Almost certainly
> > it would only work within a certain family of compilers.
> 
> The problem is with C++ and DLL's (or '.so's in UNIX/Linux)
> is that any slight change to the C++ header file will generally
> result in a new library module that will die when linked to
> a program that was compiled with the old header.
> 
> That causes endless problems for the poor library maintainer
> because he'll get lots of emails of the form "PLIB sucks -
> it keeps crashing."...the problem being that someone upgraded
> PLIB (either accidentally whilst installing something else
> or on purpose) - and didn't recompile *all* the programs
> that refer to it.
> 
> I'm absolutely adamant that I'm not going there.  PLIB support
> already takes up *WAY* too much of my time.
> 
> You are at liberty (of course) to take a copy of PLIB, change it
> to create DLL's, call it something slightly different (PLIBDLL
> or something) and deal with the maintenance calls for that new
> package yourself.
> 

I am in the "lucky" position that I expect that my program will
have a small distribution. (And thus it will be expensive).
The typical client will also get an maintenance package. 

Obviously the client is not allowed to mess with those
application files which are not specifically allowed.
"Recovery services available at $100/hour"

So if I bundle PLIB then I am not worried about possible
dll problems ;-)

In any case this still speculation, Currently I only use 
the old "very free" PUI, not so much for license reasons,
but because my feature requirements wree satisfied with that
version.


		Eero

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

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

Eero Pajarre wrote:
> 
> Steve Baker wrote:
> >
> 
> > So, if the library is a DLL, he can do that - but there is a
> > good chance that if he does, the program will crash because
> > of the C++ issues.
> >
> 
> I really don't yet know if this would work. Almost certainly
> it would only work within a certain family of compilers.

The problem is with C++ and DLL's (or '.so's in UNIX/Linux)
is that any slight change to the C++ header file will generally
result in a new library module that will die when linked to
a program that was compiled with the old header.

That causes endless problems for the poor library maintainer
because he'll get lots of emails of the form "PLIB sucks -
it keeps crashing."...the problem being that someone upgraded
PLIB (either accidentally whilst installing something else
or on purpose) - and didn't recompile *all* the programs
that refer to it.

I'm absolutely adamant that I'm not going there.  PLIB support
already takes up *WAY* too much of my time.

You are at liberty (of course) to take a copy of PLIB, change it
to create DLL's, call it something slightly different (PLIBDLL
or something) and deal with the maintenance calls for that new
package yourself.

> Anyways I think it would satisfy at least the letter
> of the LGPL. (And it would not be any worse than
> distributing application .o files).

> Btw I am not
> 100% sure how inline functions behave regarding
> LGPL. Certainly they cannot be updated if the
> "client program" is not distributed as source code.
> (I know the license mentions inline funcs)

LGPL says:

  "If such an object file uses only numerical parameters, data
structure layouts and accessors, and small macros and small inline
functions (ten lines or less in length), then the use of the object
file is unrestricted, regardless of whether it is legally a derivative
work."

...so you shouldn't have a problem here.

> Assuming that this could be implemented for WIN32
> with an external .def file, would you include the
> .def file into plid distribution?

If I do that, Windoze users will build DLL's and I'll
get into the whole support rat's nest.

I'm sorry to seem unhelpful about this - but I'm absolutely
not going to do anything to PLIB that makes it harder to
maintain.

But really, you should stick with a staticly linked PLIB
and offer the '.o'/'.obj' files for your application.

Look at the problem carefully:

The relevent section of the LGPL says:

  "...linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library".  The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables."

...and section 6 says:

  "6. As an exception to the Sections above, you may also compile or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications."

  "You must give prominent notice with each copy of the work that the
Library is used in it and that the Library and its use are covered by
this License.  You must supply a copy of this License." ....

Then, it goes on to say that you must provide source for the library
along with either .o/.obj's for the application - or the source code
for the application....although you can either:

* Distribute those files with the application ...OR...
* "Accompany the work with a written offer, valid for at least
  three years, to give the same user the {object files or source code}, for
  a charge no more than the cost of performing this distribution.
* Give access to those files on a web site or something but only if
  that's how the application was originally distributed.
* Mention that the user already has all those files (eg in the case
  of the GNU math library or something).

It seems to me that all you *really* need to do is to put a note in
the manual or 'README' file that says something to the effect of:

  "This package makes use of 'PLIB' - which is licensed under the
   Library GNU Public License.  Under the terms of that license,
   you are entitled to request certain materials that would allow
   you to re-link this package using a modified version of PLIB.
   This offer is valid for three years only - and you will be
   charged for the cost of distributing those materials.  Please
   write to the address below if you would like to take advantage
   of this facility."

...then you make a pile of about 50 floppies with the .o files and
PLIB sources, put them in a cupboard somewhere and forget about them.
The nebulous "cost of distributing" will put off the idly curious
and if someone really does want a copy - charge them whatever it costs
you to get an employee to answer the mail, pick up a floppy from the
cupboard and post it to the customer.  You can charge the actual
cost of doing this - so if your internal hourly rate for your staff
is $45 per hour and the cost of the floppy is $1 and the postage
$2 then you can demand $50 for this service.  If a ton of people
decide to take you up on it for some arcane reason, you won't lose
out.

I think you are making way to big a deal about this - it's a
no-brainer, really.

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

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

Steve Baker wrote:
> 

> So, if the library is a DLL, he can do that - but there is a
> good chance that if he does, the program will crash because
> of the C++ issues.
> 

I really don't yet know if this would work. Almost certainly
it would only work within a certain family of compilers.
Anyways I think it would satisfy at least the letter
of the LGPL. (And it would not be any worse than
distributing application .o files). Btw I am not
100% sure how inline functions behave regarding
LGPL. Certainly they cannot be updated if the
"client program" is not distributed as source code.
(I know the license mentions inline funcs)


Assuming that this could be implemented for WIN32
with an external .def file, would you include the 
.def file into plid distribution?



		Eero

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

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

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

The basic requirement is that your end user can (hypothetically)
replace the PLIB you ship with a newer version if he wants
to at some time in the future without having to buy a new
copy of your code or ask you to do it, etc, etc.

The rule is stated like that for a VERY good reason. It wants
to ensure that anyone who has the OpenSourced library (even
if it's a part of a commercial product) can still fix bugs
in it for themselves using the source code.  I need that
because I expect a continuing benefit to me of all those
commercial product users fixing my bugs for me for free.

So, if the library is a DLL, he can do that - but there is a
good chance that if he does, the program will crash because
of the C++ issues.

One alternative is to provide all the '.o' files ('.obj' for
Windoze) and let the user rerun the linker to change out
the PLIB library.   This still won't work in practice because
of the C++ issues.

The only *useful* alternative is to ship the entire source code -
but for a commercial product, this isn't generally acceptable.

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

Christian Mayer wrote:
> 
> 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...

That sounds pretty non-contentious - I don't see a problem with
popping that stuff into the SG lib.

A not-normalized normal is a vector and a normalized vector is
a normal - so I find the names a bit confusing.

I'm not quite sure what you intend these to do but how about

sgProjectVec3OntoPlane
sgProjectNormal3OntoPlane

etc.

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