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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Steve,

As a Plib/SSG enthusiast I'm happy to hear such very good news from you for
the next-gen Plib.
The revamp you have depicted was infact really needed.

I'd like you could spend some more words on formats:

- will the SSG native binary dump still live? It's very efficient in loading
and I'd dislike for it to "go away";

- what about your position to avoid dependencies on external libraries? I
refer in particular to 3D data loaders from other formats. IMHO we should
open to specialized libraries for reliably loading e.g. VRML2/X3D (CyberX3D)
or 3DS (lib3ds), then walking their scene graph to translate it into
SSG-equivalent.

- the new XML-based one: is it a scene format? Does it point to (reference)
external files for large data sets, or will it include the actual geometry
in it? Or both?

- what do you think about Collada? If the new plib-XML isn't far from it why
don't bet on Collada support from the beginning?

Thanks againg for your valuable commitment to Plib,

Paolo Leoncini

> -----Messaggio originale-----
> Da: pli...@li... 
> [mailto:pli...@li...] Per conto 
> di Steve Baker
> Inviato: venerdì 7 marzo 2008 2.28
> A: PLIB Developers
> Oggetto: [Plib-devel] Release 1.8.5....and a glimpse of the future.
> 
> I guess I have no excuses left then!
> 
> I'll get to it at the weekend.
> 
> Actually, I've been doing work on "Son of PLIB" in odd idle 
> moments - I have a version that'll work with OpenGL 3.0 (or 
> whatever they are going to call it) that uses 100% shaders - 
> no standard pipeline at all.  As with OpenGL, my main effort 
> is to slim-down, simplify and provide more flexibility for 
> data formats and plugins for algorithmic flexibility.
> 
> But I'm not making any effort on backwards, forwards or 
> sideways compatibility...anything I need to change, or merely 
> feel like changing
> - I'll change.
> 
> Multitextures and decent multipass, bucket sorting and a 
> 'posteffects' 
> mechanism are all there - plus Java scripting and XML-based 
> configuration files.  Bulk vertex data can have 
> user-specified data types and you can add your own per-vertex 
> attributes to feed data to your shaders - so stuff like 
> normal-mapping is now easy.
> 
> But I'm developing it for a rather specific purpose and I 
> don't plan to do the work collaboratively because I have a 
> clear vision of what I need and I don't want to cloud it with 
> other people's needs until I'm ready - I will, however 
> OpenSource it under LGPL when it's done.
> 
> The myriad of SSG node types has been slimmed down to just 
> two - "Leaf" 
> and "Branch" - the Leaf will hide the data transfer 
> mechanisms to the GPU and the Branch will use plugins that 
> operate at cull-time to simulate the old ssgTransform, 
> ssgRangeSelector, etc.  ssgTexture gets some love and care so 
> it can do 1D, 2D, 3D and Cube maps - ssgState becomes a 
> container for ssgShaderPair and a bunch of ssgUniform 
> variables that can (of course) be bool, int, half-float or 
> float...or ssgTexture handles - all of the messy lazy state 
> switching code 'goes 
> away' (thank God for that!).   The SG math library supports 
> every data 
> type from char to short to int to halffloat to float to 
> double with almost all of the usual functions - and to keep 
> it all up to date, it's mostly auto-generated code.
> 
> What mostly needs to be done is to have the PUI library "go 
> away" and be implemented as a layer on top of SSG - and the 
> SL audio code "go away" 
> and be replaced with an OpenAL wrapper...I'll probably 
> release what I have before I attack those things.  Sadly, 
> none of the file loaders will survive intact and it's too 
> much work to rewrite them all.  My son is Blender fanatic 
> (<sigh>) and I have a blender plugin that writes files in a 
> ".plib" format (which is XML).
> 
> Anyway - this is off in the future somewhere - I'm not making 
> promises or commitments.
> 
> 
> Jan Reucker wrote:
> > Hello,
> >
> > here's a patch to take away the last excuses not to release 
> PLIB-1.8.5.
> > It sets the version information in configure.in and ul.h to 
> 1.8.5 and
> > contains all necessary changes to the web site.
> >
> > Needless to say that PLIB SVN passes "make distcheck" 
> without errors.
> > And there hasn't been a bug report or submitted patch for a 
> while, so
> > a new release is overdue.
> >
> > What's left to do (from my point of view):
> >
> > - Someone with SVN access should apply the patch.
> > - Someone has to run "make dist" to create the 1.8.5 tarball
> > - Someone with SSH and SVN access must update the web site
> >   (emulate the transferCvs2WebSite script)
> > - Someone with file release privileges must upload the tarball
> >   to SF.net
> > - "make distcheck" fails for the examples, at least on my PC,
> >   but I don't know how to fix it.
> >
> > Did I forget something?
> >
> > Kind regards,
> > Jan R.
> >
> >   
> > 
> --------------------------------------------------------------
> ----------
> >
> > 
> --------------------------------------------------------------
> -----------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > 
> --------------------------------------------------------------
> ----------
> >
> > _______________________________________________
> > plib-devel mailing list
> > pli...@li...
> > https://lists.sourceforge.net/lists/listinfo/plib-devel
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel
> 