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

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

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

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