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