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