Re: [Plib-devel] Release 1.8.5....and a glimpse of the future.

[Steve B. <st...@sj...>]

Jan Reucker wrote:
> Am Thu, 06 Mar 2008 22:11:49 -0600 schrieb Steve Baker <st...@sj...>:
> 
>> However, the new, improved SSG will be PERFECT for that stuff.  If it 
>> has 'plugin' capability as I'm planning - then PUI simply builds an SSG 
>> scene graph and plugs in it's own culling mechanisms.   SSG provides the 
>> geometry maintenance, shader services, etc.  It's a good match.
> 
> Steve,
> 
> all that you wrote about "PLIB-2.0" or however it will be called sounds
> very interesting. And I hope that someone will implement something like
> PUI on top of it. PUI was one of the main reasons why I chose PLIB for
> CRRCsim - originally I was only looking for an OpenGL font library to
> implement my own GUI, then I discovered PUI, and then the rest of PLIB.
> 
> And right now the references to PUI are the main reason why I stick
> with PLIB-1.8.x although other SceneGraph libs are offering more features.
> Using a different scene graph for model rendering would be an easy task,
> but rewriting all the GUI code would be impossible. And I'm quite happy
> with it, so why change it? I hope that we still can get a PLIB-1.8.x
> release every now and then even after PLIB-2.0 is born, just in case bad
> bugs have been fixed.

The reason to change is that OpenGL is changing.

There was to have been a radically simplified OpenGL coming out this 
year called "OpenGL 3.0" - although they are now talking in terms of an 
intermediate 2.something release appearing first.

The change is one that I've long felt was necessay.   OpenGL has a 
wildly complicated feature set - everything from drawing dotted lines to 
  multi-textured polygons that are lit differently on the front and back 
faces.  There are at least three or four ways to send polygons to the 
graphics card...the list goes on.

However, with the advent of shader technology - you really don't need 
all of those features.  There are now just a few core concepts: Bulk 
data transfer to the graphics card - textures, shaders and uniform 
variables...and that's about it.

All of the other OpenGL features can be implemented using just a handful 
of basic concepts.

The trouble with OpenGL as it is today is that all that wild and 
complicated stuff MUST be implemented and tested in every single OpenGL 
driver - and that's a huge cost to the graphics card manufacturers. 
Worse still - we have one of OpenGL's biggest markets being in the 
embedded device arena - cellphones, PDA's, MP3 players, etc.  Those 
devices have to be lean and mean - low power consumption, not much 
memory, etc.  So they NEED a radically slimmed down OpenGL.

So - the next major revisions rips out all of that dusty old junk and 
leaves only ONE mechanism for sending polygons to the GPU - and all of 
the complicated polygon lighting and structured line stuff vanishes - 
the API shrinks to less than half it's former size!  The present 
features get added back in via an obscelescence package that implements 
the old features on top of the new streamlined API - but those features 
don't have to run very fast because they are on the way out.

This is a very good thing - it lets the card manufacturers concentrate 
on optimising the heck out of the core, modern features - and they don't 
have to worry about maintaining increasingly obscure features like the 
old lighting code anymore when no new software will use it.

Eventually the obscelescence library will be quietly dropped too.

So - in the light of that, it's highly appropriate that PLIB change to 
fit the new paradigm - and that means that we HAVE to rewrite it sooner 
or later or it will simply stop working.

Meanwhile - if we could slim it down sooner rather than later - we could 
have PLIB programs running on cellphones.

So - PUI (which uses all those old dusty features) *MUST* be rewritten 
sometime in the next year or two.  Ditto the font library.

Putting it on top of the new SSG makes a lot of sense, structurally.

Since PLIB-2 (or whatever we call it) is NOT going to be compatible with 
PLIB-as-it-is-now (nor would you want it to be) - the current PLIB will 
continue to be maintained - and possibly new versions will need to be 
released for a few more years...but sooner or later it'll be running on 
the obscelescence library of OpenGL - and at that point we should 
probably let it die.

Since we are making a HUGE break with the past - we only really want to 
do that very rarely.  So this is a good time to make any other large 
breaks with the past that we might need.  One that is L-O-N-G overdue is 
dumping the sound library ('SL') and placing it as a layer on top of 
OpenAL.  Making OpenAL a requirement for PLIB-2 is a major decision - 
but the benefits it brings are worthwhile.   For example, we could 
arrange to allow SL sound objects to be attached to objects in the SSG 
scene graph and have them be culled and "rendered" in a special audio 
rendering pass.  This would make it ridiculously easy to attach noises 
to 3D objects such that as you move around in the virtual world, you 
heare the sound produced by nearby objects automatically.  OpenAL is a 
3D audio library - it shares a lot of OpenGL features - so the 
integration path is easy.  It implements things like range attenuation, 
stereo or quadrophonic or synthetic-3D sound placement and doppler 
effects - all without intervention from the application code.

With PUI-on-top-of-SSG and with SL nodes being attachable to SSG objects 
- you could even have a GUI where the buttons make sounds as your mouse 
glides past them - or have talking pop-up help - or sliders that make 
upward sounding whistles when you slide them to the right and downward 
sounding whistles as you slide them to the left...well, it all sounds 
perfectly awful to me...but it'll come "for free" and doubtless someone 
will want to use it.



> Kind regards,
> Jan R.
>