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