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

[Paolo L. <p.l...@ci...>]

> -----Messaggio originale-----
> Da: pli...@li... 
> [mailto:pli...@li...] Per conto 
> di Steve Baker
> Inviato: venerdì 7 marzo 2008 13.12
> A: PLIB Developers
> Oggetto: Re: [Plib-devel] R: Release 1.8.5....and a glimpse 
> of the future.
> 
> Paolo Leoncini wrote:
> > 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.
> >   
> Yes - sadly, until recently I didn't have the time to work on 
> PLIB - so it's lagged seriously behind the technology.  
> That's why such massive change is needed.  There is now too 
> much to do for slow incremental change - hence a disconnect 
> from the past is needed.

No problem, it'll worth the effort.

> > I'd like you could spend some more words on formats:
> >   
> I havn't thought too much about file readers and writers - I 
> certainly don't have the time to rewrite all of the loaders 
> and savers that we currently have.

We should select among these which one to support in Plib-2. Once the new
API will be pre-released we could share the porting load.

> > - will the SSG native binary dump still live? It's very 
> efficient in 
> > loading and I'd dislike for it to "go away";
> >   
> Some sort of binary dump will exist - but it won't be 
> compatible with the present format.  The trouble with these 
> super-efficient binary formats is that they are hard to 
> change in a compatible way and still retain that highly 
> desirable efficiency.
> 
> I've added an XML load/dump feature which should provide a 
> way to keep files current in the future.

Is this the same as the one of the Blender exporter? Or is it a more
low-level one?

> > - what about your position to avoid dependencies on 
> external libraries?
> That most certainly doesn't change.  Right now - I depend on 
> OpenGL and the 'tinyXML' library - but I intend to distribute 
> tinyXML as a part of
> PLIB-2 so that's not an external dependency.  When we change 
> the audio 
> library - we'll add a dependency on OpenAL.   Aside from that 
> - no new 
> dependencies.
> >  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.
> >   
> For that kind of thing we need to use plugins that are linked 
> at runtime.  Treating foreign format loaders as 
> runtime-plugins allows people who don't want those 
> dependencies for their software to simply never load a file 
> of that format and thereby not have the dependency.

A plug-in facility in Plib. Sounds good. Have you anything already in mind?
Or is it a "just in case" sort of thing to came later? Should anybody work
on this in the meanwhile?

> > - 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?
> >   
> I'm still working on that - my current loader (for which I 
> have a blender exporter) ".plib" allows external files - but 
> the blender 
> exporter doesn't use that feature.   In practical use - I have "level 
> files" (one for each "level" of the game) that pull in 
> geometry files.  
> You can refer to non-.plib files from within .plib files - 
> and the format is nice enough that you can hand-edit your 
> "level" files in a text editor or a generic XML editor.
> 
> The tricky part is that I don't intend to load 
> material/shader descriptions from ".plib" files - the 3D 
> modellers out there just don't save the information OpenGL 
> needs in a shader-rich environment.  So I do what all of my 
> previous games have done which is to have an external 
> "material file" that links the name of the primary texture 
> map in the geometry file to the name of a material - which in 
> turn pulls in a vertex and a fragment shader, and a bunch of 
> uniform variables...which 
> can (of course) be texture maps.   So in practical use - you 
> sit in your 
> modeller - you apply a simple brick texture  
> ("textures/brick.png" say) and the loader sees that a 
> particular polygon mesh uses that map - strips the directory 
> and suffix from the filename (so now, we have
> "brick") - then searches the material file for a material 
> with that name.  The material "brick" may or may not refer to 
> the file "textures/brick.png" - that's up to you.  For 
> convenience, if that material is not found you get a warning 
> message and the "default" 
> material is used instead.  If the chosen material (either 
> "default" or "brick" in this case) exists but has no uniform 
> variable that refers to a texture map (as is the case with 
> "default"), then the system will automatically generate a 
> uniform called "texture" that is set to 
> "<your_texture_path>/<materialname>.rgb".   This mechanism 
> allows you to 
> use a basic default material without having to go and type in 
> a material for every single texture type you use.
> I expect many of the other loaders we use will want to use a similar 
> mechanism.   The AC3D loader (for example) only knows about 
> one texture 
> map and a set of diffuse/spec/emiss/ambient colours.  It's 
> impossible to specify shaders or multiple textures or 
> whatever...so you model "brick" 
> inside AC3D and you tell PLIB what "brick" looks like by 
> giving me shaders, multiple textures, a normal map, 
> cube-mapped environmental reflections....whatever.

Yet it'd be sane to offer still a file support for basic, non shader-based,
material definition as far as it's not heavy to do.

> Shaders are written in GLSL...but it wouldn't be hard to add 
> Cg if anyone really wanted to.
> 
>  > - 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?
> >   
> I don't want to write my own Collada loader because it's too 
> phreaking complicated - but if you want to do it - or if you 
> want to write the plugin-stub for Collada and depend on an 
> external library - feel free to 
> do that.   I don't need it - and I don't generally write what 
> I don't need.
> Past experience says that these standard formats typically 
> have a whole lot of features that I don't want to implement - 
> and I have implemented a whole lot of features that they 
> don't support....so it's never a good 
> match.

I agree with you, but it usually lead to a lot of work in non-standard
directions. And, before or after, the custom format gets abandoned.

> Implementing ALL of the Collada spec would be exceedingly 
> difficult - and when you don't implement all of it you find 
> that half of the models out there won't load.

Google Earth, for example, does only support Collada geometry, and nobody
says "why I can't play physics on top of a volcano". But I don't know what
happens with non-SketchUp models.

Furthermore Collada supports the detailed inclusion of shaders (possibly
even the actual shader code?), and physics definition data, which is a "must
have" of modern games. So we shouldn't feel obliged to support all at once.

Anyway it was just a thought to share with you and others before going in a
certain direction, after having evaluated what really the distance between
the two formats is.

Paolo