plib-devel

[Plib-devel] errors when compiling plib: autogen.sh problems with automake 1.8.0

[Oliver C. <kre...@gm...>]

Hello,


i upgraded my linux distribution to Slackware 10.0 that
ships with automake version 1.8.0 and tried to compile
the cvs version of plib but i get the following errors after 
running ./autogen.sh   



************************************************************
$ ./autogen.sh
Running aclocal
/usr/share/aclocal/xmms.m4:17: warning: underquoted definition of 
XMMS_TEST_VERSION
  run info '(automake)Extending aclocal'
  or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal
/usr/share/aclocal/xmms.m4:62: warning: underquoted definition of AM_PATH_XMMS
/usr/share/aclocal/vorbis.m4:9: warning: underquoted definition of 
XIPH_PATH_VORBIS
/usr/share/aclocal/pkg.m4:5: warning: underquoted definition of 
PKG_CHECK_MODULES
/usr/share/aclocal/pilot-link.m4:1: warning: underquoted definition of 
AC_PILOT_LINK_HOOK
/usr/share/aclocal/ogg.m4:8: warning: underquoted definition of XIPH_PATH_OGG
/usr/share/aclocal/nspr.m4:8: warning: underquoted definition of AM_PATH_NSPR
/usr/share/aclocal/libmikmod.m4:11: warning: underquoted definition of 
AM_PATH_LIBMIKMOD
/usr/share/aclocal/libOggFLAC.m4:7: warning: underquoted definition of 
AM_PATH_LIBOGGFLAC
/usr/share/aclocal/libOggFLAC++.m4:8: warning: underquoted definition of 
AM_PATH_LIBOGGFLACPP
/usr/share/aclocal/libIDL.m4:6: warning: underquoted definition of 
AM_PATH_LIBIDL
/usr/share/aclocal/libFLAC.m4:7: warning: underquoted definition of 
AM_PATH_LIBFLAC
/usr/share/aclocal/libFLAC++.m4:8: warning: underquoted definition of 
AM_PATH_LIBFLACPP
/usr/share/aclocal/imlib.m4:9: warning: underquoted definition of 
AM_PATH_IMLIB
/usr/share/aclocal/imlib.m4:167: warning: underquoted definition of 
AM_PATH_GDK_IMLIB
/usr/share/aclocal/gtk.m4:7: warning: underquoted definition of AM_PATH_GTK
/usr/share/aclocal/gnet-2.0.m4:8: warning: underquoted definition of 
AM_PATH_GNET_2_0
/usr/share/aclocal/glib.m4:8: warning: underquoted definition of AM_PATH_GLIB
/usr/share/aclocal/gimpprint.m4:8: warning: underquoted definition of 
AM_PATH_GIMPPRINT
/usr/share/aclocal/gdk-pixbuf.m4:12: warning: underquoted definition of 
AM_PATH_GDK_PIXBUF
/usr/share/aclocal/audiofile.m4:12: warning: underquoted definition of 
AM_PATH_AUDIOFILE
/usr/share/aclocal/ao.m4:9: warning: underquoted definition of XIPH_PATH_AO
/usr/share/aclocal/ac_find_motif.m4:21: warning: underquoted definition of 
AC_FIND_MOTIF
/usr/share/aclocal/ac_find_motif.m4:223: warning: underquoted definition of 
AC_FIND_LIBXP
/usr/share/aclocal/aalib.m4:12: warning: underquoted definition of 
AM_PATH_AALIB
/usr/share/aclocal/ORBit.m4:4: warning: underquoted definition of 
AM_PATH_ORBIT
Can't locate object method "path" via package "Request" 
at /usr/share/autoconf/Autom4te/C4che.pm line 69, <GEN1> line 94.
aclocal: autom4te failed with exit status: 1
Running automake
Can't locate object method "path" via package "Request" 
at /usr/share/autoconf/Autom4te/C4che.pm line 69, <GEN1> line 94.
automake: autoconf failed with exit status: 1
Running autoconf
Can't locate object method "path" via package "Request" 
at /usr/share/autoconf/Autom4te/C4che.pm line 69, <GEN1> line 94.
======================================
Now you are ready to run './configure'
======================================
$./configure
configure: error: cannot find install-sh or install.sh in . ./.. ./../..
$
************************************************************


So there seems to be a problem with plib's macro definitions
and the stricter behavior of automake version 1.8.0.
Just read this:


*************************************************************

Writing your own aclocal macros
===============================

The `aclocal' program doesn't have any built-in knowledge of any
macros, so it is easy to extend it with your own macros.

   This can be used by libraries which want to supply their own Autoconf
macros for use by other programs.  For instance the `gettext' library
supplies a macro `AM_GNU_GETTEXT' which should be used by any package
using `gettext'.  When the library is installed, it installs this macro
so that `aclocal' will find it.

   A macro file's name should end in `.m4'.  Such files should be
installed in `$(datadir)/aclocal'.  This is as simple as writing:

     aclocaldir = $(datadir)/aclocal
     aclocal_DATA = mymacro.m4 myothermacro.m4

   A file of macros should be a series of properly quoted `AC_DEFUN''s
(*note Macro Definitions: (autoconf)Macro Definitions.).  The `aclocal'
programs also understands `AC_REQUIRE' (*note Prerequisite Macros:
(autoconf)Prerequisite Macros.), so it is safe to put each macro in a
separate file.  Each file should have no side effects but macro
definitions.  Especially, any call to `AC_PREREQ' should be done inside
the defined macro, not at the beginning of the file.

   Starting with Automake 1.8, `aclocal' will warn about all
underquoted calls to `AC_DEFUN'.  We realize this will annoy a lot of
people, because `aclocal' was not so strict in the past and many third
party macros are underquoted; and we have to apologize for this
temporary inconvenience.  The reason we have to be stricter is that a
future implementation of `aclocal' (*note Future of aclocal::) will
have to temporary include all these third party `.m4' files, maybe
several times, even those which are not actually needed.  Doing so
should alleviate many problem of the current implementation, however it
requires a stricter style from the macro authors.  Hopefully it is easy
to revise the existing macros.  For instance
     # bad style
     AC_PREREQ(2.57)
     AC_DEFUN(AX_FOOBAR,
     [AC_REQUIRE([AX_SOMETHING])dnl
     AX_FOO
     AX_BAR
     ])

should be rewritten as
     AC_DEFUN([AX_FOOBAR],
     [AC_PREREQ(2.57)dnl
     AC_REQUIRE([AX_SOMETHING])dnl
     AX_FOO
     AX_BAR
     ])

   Wrapping the `AC_PREREQ' call inside the macro ensures that Autoconf
2.57 will not be required if `AX_FOOBAR' is not actually used.  Most
importantly, quoting the first argument of `AC_DEFUN' allows the macro
to be redefined or included twice (otherwise this first argument would
be expansed during the second definition).

  If you have been directed here by the `aclocal' diagnostic but are
not the maintainer of the implicated macro, you will want to contact
the maintainer of that macro.  Please make sure you have the last
version of the macro and that the problem already hasn't been reported
before doing so: people tend to work faster when they aren't flooded by
mails.

   Another situation where `aclocal' is commonly used is to manage
macros which are used locally by the package, *Note Local Macros::.


*************************************************************

And read this:
http://sources.redhat.com/automake/automake.html#Extending%20aclocal


Can someone fix these macro definitions shipped with plib's cvs version?


Best Regards,
 Oliver C.

Re: [Plib-devel] Re: [Fwd: Plib 2.0]

[Frederic B. <fr...@wa...>]

Steve Baker wrote:

> > Fortunately one of the developers of FlightGear has improved plib's ssg
> > library in many ways allowing a number of the mentioned requirements
> > already, taking into account many of the other options.
> 
> No - that was a bad idea.
> 
> Rushing off and making a bunch of sweeping changes without significant
> discussion of it on the developer list is a bad idea and likely to get
> your work rejected for inclusion into the package.
> 
> The changes he did are not concordant with the future of OpenGL graphics
> and actually make it harder to transition into the bright new future of
> shaders and such.
> 
> I don't think I want those changes in PLIB.

Let me say something as I am the one who made this. I don't think you 
were thinking about me when you wrote this. So before rejecting totally 
what was done so far, would you mind just spend few minutes to read 
this : http://perso.wanadoo.fr/frbouvi/plib/nsssg.html

if you are still interested, you can even look at the code :
http://perso.wanadoo.fr/frbouvi/plib/nsssg-20040710.tar.gz

As I prefer to exchange ideas on real things rather than just speaking 
in the air, I made this as a proof-of-concept and a draft to generate 
reaction and maybe make things evolve a bit to something more in-line 
with current technology.

Peoples interested in teasers can have a look at these pictures :
> http://perso.wanadoo.fr/frbouvi/plib/nsssg-bld-1.jpg
> http://perso.wanadoo.fr/frbouvi/plib/nsssg-bld-2.jpg
> http://perso.wanadoo.fr/frbouvi/plib/nsssg-bld-3.jpg
Flightgear has been modified to take into account the new 
functionalities of the library, but it compiled unmodified first as the
plib examples do. I have a version of the water demo that do tex gen 
without the need of using straight opengl calls in the application code.
This code is here : http://perso.wanadoo.fr/frbouvi/plib/water.cxx
( search ssgTexGen ).

My personal requirements for an evolution of ssg were source compatibility 
with existing app code and extensibility of the state management classes
to support present and future OpenGL extensions and evolutions.

The result is that I was able to include ARB_vertex_program in few days 
in an unpublished version I am finishing to integrate with FlightGear. 
ARB_fragment_program and ARB_shader_objects are my next targets.

So don't take this code as a requirement from me to being included in 
plib. Just take a look at it, let's decide what is worth keeping and 
worth thrashing and let's design something that works with current 
hardware and that could be future-proof, either for the sake 
of plib, and for the sake of projects that rely on it.

Kind regards,
-Fred

Re: [Plib-devel] Re: [Fwd: Plib 2.0]

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

Fay John F Contr AAC/WMG wrote:

>         I guess Steve's desire to fold PUI into SSG means that I am 
> going to have to learn SSG.

Well, here is the thought:

Let me talk about a hypothetical library 'X'.

X is a library that stores a tree structure of things.  Some things
are leaves of the tree, others are nodes that connect branches together.
There are two basic operations that X does on that tree - it walks
the tree in order to render it to the screen - drawing only the leaf
'things' that are visible.  Another operation is to traverse the scene
finding those nodes that are 'hit' by a particular geometric primitive.
Each of the leaf nodes has a bunch of properties that determine what
the node looks like - these include shape and colour, transparency...
perhaps other things too.

So far, 'X' could either be SSG or PUI.  SSG's leaf nodes are 'ssgLeaf'
classes, PUI's are 'puButton' and such.  SSG's branch nodes are 'ssgBranch'
classes, PUI's are 'puGroup' and such.  The mouse click testing in PUI
is a precise analog of the 'isect' traversal in SSG.  The business of
inheriting 'style' and colour/alpha in PUI is akin to the ssgState
management in SSG.

SSG has 'ssgSelector' nodes that indicate which (if any) of their child
nodes will be isect'ed or rendered.  PUI has a collection of enable/disable
flags that do similar things.

All in all, if we were starting from scratch, we would never have written
PUI and SSG as separate libraries.  They would have been the same library -
but perhaps with some 'wrappers' to make PUI look more like a GUI library
and SSG look more like a 3D renderer.

So, it seems to me that merging the two would be a natural thing to do.

There would be interesting benefits for PUI:

* PUI would gain the ability to use genuine 3D objects as GUI elements.
* You'd be able to use a 3D modeller to design and view GUI pages.
* PUI widgets could be textured, animated, moved around on the screen
   using the same techniques that allow those things to happen in SSG.
* PUI widgets could be applied to 3D objects - or the entire GUI page
   moved off in 3D.
* PUI needs to be moved from absolute screen coordinates to a more
   rational (screen-resolution independent) system.  That would just
   drop out of this change.

I can see lots of possibilities.

 >  One thing I do NOT want for PUI, though, is
> the baggage of all the file readers and writers.

Well, I suppose we could invest the time to make file readers and writers
load dynamically - but I'm not sure that's really necessary.

In an 'un-stripped' binary (ie with all of the symbol table in place),
SSG is 12Mb and PUI is 4.5Mb - that's the amount of extra disk space.

When you strip out the symbols (which gets you closer to the actual
in-memory footprint, SSG is 0.7Mb and PUI is 0.3Mb.

So the most that this 'baggage' is costing you is about 400kbytes.
To put that in context, that's about the same as a single font texture
in PUI.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

RE: [Plib-devel] Re: [Fwd: Plib 2.0]

[Fay J. F C. AAC/W. <joh...@eg...>]

Paolo,

	I am certainly open to ideas--and I daresay Steve is, too--but this
is no guarantee that they will be accepted.  But do please bring them =
on.

	I guess Steve's desire to fold PUI into SSG means that I am going to
have to learn SSG.  One thing I do NOT want for PUI, though, is the =
baggage
of all the file readers and writers.

John F. Fay
joh...@eg...



-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Paolo
Leoncini
Sent: Tuesday, July 13, 2004 10:27 AM
To: pli...@li...
Subject: R: [Plib-devel] Re: [Fwd: Plib 2.0]



Is this a call-for-thoughts around Plib 2.0? Can anyone contribute with
ideas?


> -----Messaggio originale-----
> Da: pli...@li...=20
> [mailto:pli...@li...] Per conto di=20
> Steve Baker
> Inviato: marted=EC 13 luglio 2004 14.34
> A: Erik Hofman; pli...@li...
> Oggetto: [Plib-devel] Re: [Fwd: Plib 2.0]
>=20
>=20
<snip>
> 2) PUI is converging on SSG.
>=20
>     Both API's are tree structured data with branches and=20
> leaves. Leaf nodes
>     cause rendering to happen and branch nodes control=20
> behavior with state
>     nodes doing stuff like colour and texture.  Collision=20
> detection and
>     figuring out which button was clicked are also very=20
> similar activities.
>=20
>     PUI is in dire need of state management to allow it to use =
texture
>     and such like more cleanly.   Merging those two systems=20
> into a single
>     API brings in very interesting possibilities for both=20
> API's and saves
>     us a bunch of maintenance (because both could share the same =
state
>     management and cull routines - you could even do things=20
> like building
>     your GUI pages in a 3D modeller).
>=20
<snip>

Re: R: [Plib-devel] Re: [Fwd: Plib 2.0]

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

Paolo Leoncini wrote:
> Is this a call-for-thoughts around Plib 2.0? Can anyone contribute with
> ideas?

Yes - sure.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

R: [Plib-devel] Re: [Fwd: Plib 2.0]

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

Is this a call-for-thoughts around Plib 2.0? Can anyone contribute with
ideas?


> -----Messaggio originale-----
> Da: pli...@li...=20
> [mailto:pli...@li...] Per conto di=20
> Steve Baker
> Inviato: marted=EC 13 luglio 2004 14.34
> A: Erik Hofman; pli...@li...
> Oggetto: [Plib-devel] Re: [Fwd: Plib 2.0]
>=20
>=20
> Erik Hofman wrote:
>=20
> > Now that the latest changes have ended up in a stable=20
> release of plib=20
> > I was wondering what the developers would think about=20
> working towards=20
> > a 2.0 release.
>=20
> Yes - I think that time is fast-approaching.
>=20
> > Steve has already mentioned he wanted vertex-, and pixel shader=20
> > support, others have mentioned multi-texturing, cube-mapping and=20
> > impostors. Also some developers have worked towards=20
> implementing VBO's=20
> > into plib.
>=20
> The world of interactive 3D graphics has taken a sudden jump=20
> forward in
> the last couple of years with all of this shader stuff.  =20
> Shaders really
> change *everything*.   Thinks like multitexture are handled MUCH more
> cleanly, and the whole business of state management changes=20
> beyond all recognition.
>=20
> However, the standards for Shaders just havn't been there. =20
> Initially, we had a bunch of different and incompatible=20
> machine-code languages, then we had nVidia's Cg (which is=20
> only semi-portable), and then we had a bunch of GLslang=20
> vapourware.  However, now we have GLSL...the fully approved=20
> OpenGL Shader Language...accepted by all three major hardware vendors.
>=20
> GLSL is *finally* going to become an official OpenGL standard=20
> and part of the core API in the next month or so.
>=20
> This (IMHO) offers us the opportunity to make the changes=20
> that PLIB needs
> in a clear, concise and future proofed manner.   For OpenGL=20
> 2.0, we need
> PLIB 2.0.
>=20
> Rewriting (at least) SSG to make use of shaders is a BIG move=20
> and I didn't want to take that step until the standards and=20
> drivers were there to make that change a lasting one.
>=20
> As of today, there are Linux drivers containing GLSL for=20
> nVidia, ATI and 3DLabs.  Only hardware from those three=20
> companies that's less than about a year old is capable of=20
> supporting them though.
>=20
> Hence, this new PLIB 2.0 won't run on a large fraction of the=20
> hardware that's out there.  However, if it's going to take a=20
> while to get it done, we may expect a much larger proportion=20
> of people to have the hardware in place by the time we get to=20
> the end of the work.
>=20
> Clearly, adding shaders will break most applications - and=20
> dropping support for so many graphics cards will break still=20
> more.  However, that is the way of the future.
>=20
> A major version number change means that backwards=20
> compatibility is not guaranteed.  We can't make such changes=20
> very often - but I think the time
> is coming to do that.   However, if you are going to upset=20
> applications people,
> by making a seriously incompatible change, you should do it=20
> all at once rather than piecemeal.
>=20
> Hence, in addition to SSG shader support, there are other=20
> drastic changes that PLIB needs:
>=20
> 1) Rewrite SL.
>=20
>     Sound should be handled through OpenAL.  SL should become
>     a music player and file loader on top of OpenAL.   Audio should be
>     'known' to SSG so that sound sources can automatically be=20
> a part of
>     the 3D world.  We can consider having an 'SL legacy' API=20
> that mimics
>     SL using OpenAL.  I'd like to see an MP3 player (or=20
> probably an Ogg
>     player) inside the new SL.
>=20
> 2) PUI is converging on SSG.
>=20
>     Both API's are tree structured data with branches and=20
> leaves. Leaf nodes
>     cause rendering to happen and branch nodes control=20
> behavior with state
>     nodes doing stuff like colour and texture.  Collision=20
> detection and
>     figuring out which button was clicked are also very=20
> similar activities.
>=20
>     PUI is in dire need of state management to allow it to use texture
>     and such like more cleanly.   Merging those two systems=20
> into a single
>     API brings in very interesting possibilities for both=20
> API's and saves
>     us a bunch of maintenance (because both could share the same state
>     management and cull routines - you could even do things=20
> like building
>     your GUI pages in a 3D modeller).
>=20
> 3) Scripting SSG.
>=20
>     The behavior of nodes in SSG is hard-coded.  These days,=20
> I think that
>     behavior could be scripted.  All of the various types of transform
>     and selector nodes could be reduced to a single node type=20
> with very basic
>     scripting present to control them.  In the end, each node=20
> has a transform
>     and a set of child nodes that may or may not wish to be rendered.
>=20
> 4) Simplifying Leaf Nodes:
>=20
>     We should reduce the variety of ssgLeaf nodes to a single=20
> type - that type
>     should allow arbitary per-vertex data.
>=20
> 5) ssgState nodes should be heavily shader-oriented.
>=20
> 6) Config.
>=20
>     We need some kind of configuration file management=20
> library...this should be
>     capable of providing uniform variables to SSG's shaders. =20
> An interactive
>     'control panel' tool to change these variables on-the-fly=20
> while a game is
>     running would be useful to shader developers.
>=20
> Of course all of this needs considerable discussion - but=20
> this is the vision I have.
>=20
> > Fortunately one of the developers of FlightGear has improved plib's=20
> > ssg library in many ways allowing a number of the mentioned=20
> > requirements already, taking into account many of the other options.
>=20
> No - that was a bad idea.
>=20
> Rushing off and making a bunch of sweeping changes without=20
> significant discussion of it on the developer list is a bad=20
> idea and likely to get your work rejected for inclusion into=20
> the package.
>=20
> The changes he did are not concordant with the future of=20
> OpenGL graphics and actually make it harder to transition=20
> into the bright new future of shaders and such.
>=20
> I don't think I want those changes in PLIB.
>=20
> ---------------------------- Steve Baker -------------------------
> HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
> HomePage : http://www.sjbaker.org
> Projects : http://plib.sf.net    http://tuxaqfh.sf.net
>             http://tuxkart.sf.net http://prettypoly.sf.net=20
> -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$=20
> P--- L++++$ E--- W+++ N o+ K? w--- !O M-
> V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++=20
> h--(-) r+++ y++++ -----END GEEK CODE BLOCK-----
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings &=20
> Training. Attend Black Hat Briefings & Training, Las Vegas=20
> July 24-29 -=20
> digital self defense, top technical experts, no vendor pitches,=20
> unmatched networking opportunities. Visit www.blackhat.com=20
> _______________________________________________
> plib-devel mailing list
> pli...@li...=20
> https://lists.sourceforge.net/lists/listinfo/p> lib-devel
>=20

[Plib-devel] Re: [Fwd: Plib 2.0]

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

Erik Hofman wrote:

> Now that the latest changes have ended up in a stable release of plib I
> was wondering what the developers would think about working towards a
> 2.0 release.

Yes - I think that time is fast-approaching.

> Steve has already mentioned he wanted vertex-, and pixel shader support,
> others have mentioned multi-texturing, cube-mapping and impostors. Also
> some developers have worked towards implementing VBO's into plib.

The world of interactive 3D graphics has taken a sudden jump forward in
the last couple of years with all of this shader stuff.   Shaders really
change *everything*.   Thinks like multitexture are handled MUCH more
cleanly, and the whole business of state management changes beyond all
recognition.

However, the standards for Shaders just havn't been there.  Initially,
we had a bunch of different and incompatible machine-code languages, then
we had nVidia's Cg (which is only semi-portable), and then we had a bunch
of GLslang vapourware.  However, now we have GLSL...the fully approved
OpenGL Shader Language...accepted by all three major hardware vendors.

GLSL is *finally* going to become an official OpenGL standard and part of
the core API in the next month or so.

This (IMHO) offers us the opportunity to make the changes that PLIB needs
in a clear, concise and future proofed manner.   For OpenGL 2.0, we need
PLIB 2.0.

Rewriting (at least) SSG to make use of shaders is a BIG move and I didn't
want to take that step until the standards and drivers were there to make
that change a lasting one.

As of today, there are Linux drivers containing GLSL for nVidia, ATI and
3DLabs.  Only hardware from those three companies that's less than about
a year old is capable of supporting them though.

Hence, this new PLIB 2.0 won't run on a large fraction of the hardware
that's out there.  However, if it's going to take a while to get it
done, we may expect a much larger proportion of people to have the
hardware in place by the time we get to the end of the work.

Clearly, adding shaders will break most applications - and dropping
support for so many graphics cards will break still more.  However,
that is the way of the future.

A major version number change means that backwards compatibility is not
guaranteed.  We can't make such changes very often - but I think the time
is coming to do that.   However, if you are going to upset applications people,
by making a seriously incompatible change, you should do it all at once rather
than piecemeal.

Hence, in addition to SSG shader support, there are other drastic changes
that PLIB needs:

1) Rewrite SL.

    Sound should be handled through OpenAL.  SL should become
    a music player and file loader on top of OpenAL.   Audio should be
    'known' to SSG so that sound sources can automatically be a part of
    the 3D world.  We can consider having an 'SL legacy' API that mimics
    SL using OpenAL.  I'd like to see an MP3 player (or probably an Ogg
    player) inside the new SL.

2) PUI is converging on SSG.

    Both API's are tree structured data with branches and leaves. Leaf nodes
    cause rendering to happen and branch nodes control behavior with state
    nodes doing stuff like colour and texture.  Collision detection and
    figuring out which button was clicked are also very similar activities.

    PUI is in dire need of state management to allow it to use texture
    and such like more cleanly.   Merging those two systems into a single
    API brings in very interesting possibilities for both API's and saves
    us a bunch of maintenance (because both could share the same state
    management and cull routines - you could even do things like building
    your GUI pages in a 3D modeller).

3) Scripting SSG.

    The behavior of nodes in SSG is hard-coded.  These days, I think that
    behavior could be scripted.  All of the various types of transform
    and selector nodes could be reduced to a single node type with very basic
    scripting present to control them.  In the end, each node has a transform
    and a set of child nodes that may or may not wish to be rendered.

4) Simplifying Leaf Nodes:

    We should reduce the variety of ssgLeaf nodes to a single type - that type
    should allow arbitary per-vertex data.

5) ssgState nodes should be heavily shader-oriented.

6) Config.

    We need some kind of configuration file management library...this should be
    capable of providing uniform variables to SSG's shaders.  An interactive
    'control panel' tool to change these variables on-the-fly while a game is
    running would be useful to shader developers.

Of course all of this needs considerable discussion - but this is the
vision I have.

> Fortunately one of the developers of FlightGear has improved plib's ssg
> library in many ways allowing a number of the mentioned requirements
> already, taking into account many of the other options.

No - that was a bad idea.

Rushing off and making a bunch of sweeping changes without significant
discussion of it on the developer list is a bad idea and likely to get
your work rejected for inclusion into the package.

The changes he did are not concordant with the future of OpenGL graphics
and actually make it harder to transition into the bright new future of
shaders and such.

I don't think I want those changes in PLIB.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

[Plib-devel] Re: [Fwd: Plib 2.0]

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

Erik Hofman wrote:

> Now that the latest changes have ended up in a stable release of plib I
> was wondering what the developers would think about working towards a
> 2.0 release.

Yes - I think that time is fast-approaching.

> Steve has already mentioned he wanted vertex-, and pixel shader support,
> others have mentioned multi-texturing, cube-mapping and impostors. Also
> some developers have worked towards implementing VBO's into plib.

The world of interactive 3D graphics has taken a sudden jump forward in
the last couple of years with all of this shader stuff.   Shaders really
change *everything*.   Thinks like multitexture are handled MUCH more
cleanly, and the whole business of state management changes beyond all
recognition.

However, the standards for Shaders just havn't been there.  Initially,
we had a bunch of different and incompatible machine-code languages, then
we had nVidia's Cg (which is only semi-portable), and then we had a bunch
of GLslang vapourware.  However, now we have GLSL...the fully approved
OpenGL Shader Language...accepted by all three major hardware vendors.

GLSL is *finally* going to become an official OpenGL standard and part of
the core API in the next month or so.

This (IMHO) offers us the opportunity to make the changes that PLIB needs
in a clear, concise and future proofed manner.   For OpenGL 2.0, we need
PLIB 2.0.

Rewriting (at least) SSG to make use of shaders is a BIG move and I didn't
want to take that step until the standards and drivers were there to make
that change a lasting one.

As of today, there are Linux drivers containing GLSL for nVidia, ATI and
3DLabs.  Only hardware from those three companies that's less than about
a year old is capable of supporting them though.

Hence, this new PLIB 2.0 won't run on a large fraction of the hardware
that's out there.  However, if it's going to take a while to get it
done, we may expect a much larger proportion of people to have the
hardware in place by the time we get to the end of the work.

Clearly, adding shaders will break most applications - and dropping
support for so many graphics cards will break still more.  However,
that is the way of the future.

A major version number change means that backwards compatibility is not
guaranteed.  We can't make such changes very often - but I think the time
is coming to do that.   However, if you are going to upset applications people,
by making a seriously incompatible change, you should do it all at once rather
than piecemeal.

Hence, in addition to SSG shader support, there are other drastic changes
that PLIB needs:

1) Rewrite SL.

    Sound should be handled through OpenAL.  SL should become
    a music player and file loader on top of OpenAL.   Audio should be
    'known' to SSG so that sound sources can automatically be a part of
    the 3D world.  We can consider having an 'SL legacy' API that mimics
    SL using OpenAL.  I'd like to see an MP3 player (or probably an Ogg
    player) inside the new SL.

2) PUI is converging on SSG.

    Both API's are tree structured data with branches and leaves. Leaf nodes
    cause rendering to happen and branch nodes control behavior with state
    nodes doing stuff like colour and texture.  Collision detection and
    figuring out which button was clicked are also very similar activities.

    PUI is in dire need of state management to allow it to use texture
    and such like more cleanly.   Merging those two systems into a single
    API brings in very interesting possibilities for both API's and saves
    us a bunch of maintenance (because both could share the same state
    management and cull routines - you could even do things like building
    your GUI pages in a 3D modeller).

3) Scripting SSG.

    The behavior of nodes in SSG is hard-coded.  These days, I think that
    behavior could be scripted.  All of the various types of transform
    and selector nodes could be reduced to a single node type with very basic
    scripting present to control them.  In the end, each node has a transform
    and a set of child nodes that may or may not wish to be rendered.

4) Simplifying Leaf Nodes:

    We should reduce the variety of ssgLeaf nodes to a single type - that type
    should allow arbitary per-vertex data.

5) ssgState nodes should be heavily shader-oriented.

6) Config.

    We need some kind of configuration file management library...this should be
    capable of providing uniform variables to SSG's shaders.  An interactive
    'control panel' tool to change these variables on-the-fly while a game is
    running would be useful to shader developers.

Of course all of this needs considerable discussion - but this is the
vision I have.

> Fortunately one of the developers of FlightGear has improved plib's ssg
> library in many ways allowing a number of the mentioned requirements
> already, taking into account many of the other options.

No - that was a bad idea.

Rushing off and making a bunch of sweeping changes without significant
discussion of it on the developer list is a bad idea and likely to get
your work rejected for inclusion into the package.

The changes he did are not concordant with the future of OpenGL graphics
and actually make it harder to transition into the bright new future of
shaders and such.

I don't think I want those changes in PLIB.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

[Plib-devel] This may be of interest

[Ampere K. H. <amp...@sy...>]

Hello,

This link came up on the FlightGear's mailing list a while ago. =A0It seems=
 to=20
be some sort of newly developed rendering library.  May be it will be usefu=
l.
http://graphics.cs.uni-sb.de/RTRT/

This link shows one of the capability of the library: rendering a 350 milli=
on=20
triangles monster (without texture) within a reasonable amount of time.
http://graphics.cs.uni-sb.de/MassiveRT/boeing777.html

Application to games:
http://graphics.cs.uni-sb.de/RTGames/

Regards,
Ampere

[Plib-devel] Have an ATI Radeon? Please help us!

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

The Games-Based Linux Distribution (GBLD) project is seeking someone with an ATI Radeon
card to test the driver install process on their latest "LiveCD".

If you can spare a half hour and a blank CD, please go to:

http://archpollux.no-ip.org:70/~gbld/files/andrew/

...download the file 'LiveCD-07062004.iso.gz', gunzip it and burn it onto a CD. Then reboot
your PC with that CD in the drive. It takes about two minutes to boot up then arrives at a
shell prompt. Type 'startx' to get X started, then right-click on the desktop and select 'xterm'.

At the xterm prompt, type 'glInfo' and write down what it says. Then you can reboot your
machine normally and email me (sjb...@ai...) with the results.

The LiveCD doesn't install anything or even *look* at your hard drive - so there is no
risk of it screwing your machine up whether you are a Linux user or a Windows user.

Many *many* thanks in advance.

----------------------------------------------------------------------------------------------------------

The GBLD project is an effort to put together a bootable CD with a bunch of the very best
OpenSourced Linux games on it so that Windows users can get a taste of Linux gaming just by
stuffing it into their CD drive and hitting the reset button.

At this stage, we are just getting the Linux part working and installing various drivers correctly.
Once that phase is complete, we'll do a nice, clean install of forty or so of the best Linux
games, add basic documentation for each of them and release the LiveCD for free download.

If you want to find out more or to help out beyond this, please go to http://www.gbld.net and
make yourself known on the forums there.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

[Plib-devel] some free wikis

[Simon <sim...@ho...>]

Hey, here are a few wikis that are free to download and use:

=20

http://www.tinyted.net/eddie/wiki/

http://www.wikiweb.com/

http://c2.com/cgi/wiki?WikiFarms

http://www.openwiki.com/ow.asp?OpenWiki%2FDownload

=20

I know I haven't really done anything with plib for about a year and =
that my
current plib project is totally on hold but I know when I start it again =
a
wiki would be really useful.  I don't mind adding the initial data i.e.
taking it straight from the online docs to get it all started.

Re: [Plib-devel] a wiki

[<da...@mi...>]

Steve Baker wrote:

> da...@mi... wrote:
>
>> What is the wiki in question here?  I didnt see that anybody 
>> identifid it, but I dont always get all emails due to an overzealous 
>> spam filter.
>
>
> Sorry - forget it - I sent the message to the wrong mailing list.
>
> ---------------------------- Steve Baker -------------------------
> HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
> HomePage : http://www.sjbaker.org
> Projects : http://plib.sf.net    http://tuxaqfh.sf.net
>            http://tuxkart.sf.net http://prettypoly.sf.net
> -----BEGIN GEEK CODE BLOCK-----
> GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
> V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
> -----END GEEK CODE BLOCK-----
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
> self defense, top technical experts, no vendor pitches, unmatched 
> networking opportunities. Visit www.blackhat.com
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel
>
Oh, sorry. I was hoping there was a wiki. 

If there isnt one I'd be willing to try and set one up if you can see 
any benefit in it. I have the extra server space, so I'd donate the 
space for free because its a good cause.

I dont understand how to set up a lot of the features of a wiki, but 
I've done a very minimal basic setup once before in a galaxy far far 
away.  A domain name to put it under costs about $7.03 per year, I don't 
make any money one that, its my cost passed on.  My server is on a high 
speed backbone so the response time is fairly good. 

-Dave C

Re: [Plib-devel] a wiki

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

da...@mi... wrote:
> What is the wiki in question here?  I didnt see that anybody identifid 
> it, but I dont always get all emails due to an overzealous spam filter.

Sorry - forget it - I sent the message to the wrong mailing list.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-devel] a wiki

[<da...@mi...>]

What is the wiki in question here?  I didnt see that anybody identifid=20
it, but I dont always get all emails due to an overzealous spam filter.


Erik Hofman wrote:

> Simon wrote:
>
>> Hey, a wiki is an information web site where users can directly edit=20
>> the content.  I use one for a game editor I=92m working on.  Its got a=
=20
>> big function list that someone entered ages ago.  Then as time goes=20
>> on and people learn what different functions and arguments do they=20
>> simply click the edit button, update the relevant info and click=20
>> submit.  Then that info is instantly available to everyone else.  The=20
>> one I use is totally open as many others are so they sometimes get=20
>> deleted or mis-edited by irritating people :=AC)
>
>
> Part of the success of a Wiki is that you don't openly accuse editors=20
> for being irritating, otherwise funny things may suddenly start=20
> happening...
> :-D
>
> Erik
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital=20
> self defense, top technical experts, no vendor pitches, unmatched=20
> networking opportunities. Visit www.blackhat.com
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel
>


--=20
"Do not bow your heads but look up so you can see God and ask his blessin=
g on what we are about to do."

President Ronald Reagan, quoting the commander of the paratroopers who we=
re about to launch into the Normandy invasion.

Re: [Plib-devel] Wiki not letting me in anymore.

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

Fay John F Contr AAC/WMG wrote:
> Umm ... what's a Wiki?

Oops!  Looks like I sent this to the wrong mailing list!

(A Wiki is an interactive link-intensive web based documentation system)

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-devel] a wiki

[Erik H. <er...@eh...>]

Simon wrote:
> Hey, a wiki is an information web site where users can directly edit the 
> content.  I use one for a game editor I’m working on.  Its got a big 
> function list that someone entered ages ago.  Then as time goes on and 
> people learn what different functions and arguments do they simply click 
> the edit button, update the relevant info and click submit.  Then that 
> info is instantly available to everyone else.  The one I use is totally 
> open as many others are so they sometimes get deleted or mis-edited by 
> irritating people :¬)

Part of the success of a Wiki is that you don't openly accuse editors 
for being irritating, otherwise funny things may suddenly start happening...
:-D

Erik

[Plib-devel] a wiki

[Simon <sim...@ho...>]

Hey, a wiki is an information web site where users can directly edit the
content.  I use one for a game editor I=92m working on.  Its got a big
function list that someone entered ages ago.  Then as time goes on and
people learn what different functions and arguments do they simply click =
the
edit button, update the relevant info and click submit.  Then that info =
is
instantly available to everyone else.  The one I use is totally open as =
many
others are so they sometimes get deleted or mis-edited by irritating =
people
:=AC)

RE: [Plib-devel] Wiki not letting me in anymore.

[Fay J. F C. AAC/W. <joh...@eg...>]

Umm ... what's a Wiki?

John F. Fay
joh...@eg...



-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Steve Baker
Sent: Wednesday, June 30, 2004 4:50 PM
To: pli...@li...
Subject: [Plib-devel] Wiki not letting me in anymore.


Hmm - the Wiki was working OK for me this morning - but I've just
gone back to it and whenever I try to add information, I just get:

Fatal PhpWiki Error
Editing pages is disallowed on this wiki for user (level: -1).

...so maybe I'm not logged in anymore?   I type 'SteveBaker' into
the box at the bottom right and hit the 'Sign in as' button - but
nothing happens?!?

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] Wiki not letting me in anymore.

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

Hmm - the Wiki was working OK for me this morning - but I've just
gone back to it and whenever I try to add information, I just get:

Fatal PhpWiki Error
Editing pages is disallowed on this wiki for user (level: -1).

...so maybe I'm not logged in anymore?   I type 'SteveBaker' into
the box at the bottom right and hit the 'Sign in as' button - but
nothing happens?!?

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

RE: [Plib-devel] MacOSX/PLIB-PW problem.

[Fay J. F C. AAC/W. <joh...@eg...>]

I'm not a Mac guru, but it does seem that those lines should not be
commented out.  I have found the corresponding parts in "freeglut" and PW(X)
and they are not commented out in those places.

John F. Fay
joh...@eg...



-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Steve Baker
Sent: Saturday, June 26, 2004 1:13 AM
To: pli...@li...
Subject: [Plib-devel] MacOSX/PLIB-PW problem.


MacOSX gurus...

Please look at this:

http://www.cse.unsw.edu.au/~cbro903/tuxkart_mac.jpg

Looks to me like OpenGL didn't get a Z buffer - which would place
the problem in PW.  I took a quick look in plib/src/pw/pwMacOSX.cxx
and saw this (around line 262):


#ifdef UL_MAC_OSX
         if (fullscreen) attrib[i++] = AGL_FULLSCREEN;
#endif
         //attrib[i++] = AGL_DEPTH_SIZE;
         //attrib[i++] = 24;
         //attrib[i++] = AGL_ALL_RENDERERS;
         attrib[i++] = AGL_NONE;

...why was this commented out?  Seems like it's needed!

I checked the CVS repository - and those lines have been commented
out since the MacOSX version was first committed.


---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] MacOSX/PLIB-PW problem.

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

MacOSX gurus...

Please look at this:

http://www.cse.unsw.edu.au/~cbro903/tuxkart_mac.jpg

Looks to me like OpenGL didn't get a Z buffer - which would place
the problem in PW.  I took a quick look in plib/src/pw/pwMacOSX.cxx
and saw this (around line 262):


#ifdef UL_MAC_OSX
         if (fullscreen) attrib[i++] = AGL_FULLSCREEN;
#endif
         //attrib[i++] = AGL_DEPTH_SIZE;
         //attrib[i++] = 24;
         //attrib[i++] = AGL_ALL_RENDERERS;
         attrib[i++] = AGL_NONE;

...why was this commented out?  Seems like it's needed!

I checked the CVS repository - and those lines have been commented
out since the MacOSX version was first committed.


---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-devel] Blender bridge.

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

Norman Vine wrote:

> I haven't used it but there was a Python exporter module
> it appears to be shipped with the latest Blender
> http://www.blender3d.org/cms/Import___Export.5.0.html

Ah - that's it.  I upgraded to Blended 0.33 and it was there.  Obviously
it got added between 0.23 and 0.33.

There seem to be problems with backfacing polygons - and the model
I was given seems to have been built from spline patches - so all
that came through into AC3D was the control points connected into
polygons somehow.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

RE: [Plib-devel] Blender bridge.

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

Steve Baker writes:
> 
> How (if at all) are people getting models out of blender and into
> PLIB?
> 
> I vaguely recall someone talking about a '.ac' exporter - but I can't
> find any references to it on the net.   I tried exporting in DXF
> and re-importing into PLIB - but everything comes out black.  I tried
> exporting in VRML1 and re-importing - but that produced complete garbage.

I haven't used it but there was a Python exporter module
it appears to be shipped with the latest Blender
http://www.blender3d.org/cms/Import___Export.5.0.html

for earlier versions see  < all one URL >
http://www.seedwiki.com/page.cfm?doc=Modeler%20And%20Scenery%20Builder%20Documentation&wikiid=2418&wpid=123390

Cheers

Norman

Re: [Plib-devel] Blender bridge.

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

Steve Baker wrote:
> How (if at all) are people getting models out of blender and into
> PLIB?
> 
> I vaguely recall someone talking about a '.ac' exporter - but I can't
> find any references to it on the net.   I tried exporting in DXF
> and re-importing into PLIB - but everything comes out black.  I tried
> exporting in VRML1 and re-importing - but that produced complete garbage.

(Those both seem to be problems with Blender's exporters because AC3D
shows the DXF and VRML1 files looking exactly the same as they do in
PLIB).

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

[Plib-devel] Blender bridge.

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

How (if at all) are people getting models out of blender and into
PLIB?

I vaguely recall someone talking about a '.ac' exporter - but I can't
find any references to it on the net.   I tried exporting in DXF
and re-importing into PLIB - but everything comes out black.  I tried
exporting in VRML1 and re-importing - but that produced complete garbage.

Help!

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----