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

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

Paolo Leoncini wrote:
>> 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.
>   
Well, the work of writing loaders and savers is generally one where "He 
who needs it - implements it!"...this generally gets you most of the 
important loaders fairly easily - but you also get landed with a bunch 
of obscure ones and some that are only incompletely written.  It's not 
the most glamorous job!

>> 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?
>   
Yes - it's the same on that my Blender exporter writes.  That's just a 
Python script that constructs XML in memory then calls the XML output 
module to dump it to disk.  Writing blender exporters is a total crap 
shoot though - they change the API with every release - update the 
documentation about once a decade - and the Python API always lags 
behind the feature set of blender's 3D modeller - so you just never 
quite get to catch up with everything.   But that's still better than 
trying to parse '.blend' files.   It's OK for exporting simple geometry 
- but when you start wanting to write out heirarchy or stuff like bone 
structures and vertex weights or animation curves...the lack of decent 
documentation and the lag in the Python API can really kill you.   Also, 
you have to update your Python code with almost every blender release.

I really hate blender...but my kid loves it - so I'm stuck having to 
support it!

> 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?
>   
No - don't work on ANYTHING because I'm still in a very early design phase.

The plan is to allow plugins in Java and as precompiled C++.   Java was 
not my language of choice - but I have an ulterior motive in that my son 
is learning it at school and I want him to exercise his programming 
skills.   It's not too terrible - but it wouldn't have been my first choice.
> 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.
>
>   
Well, that kinda falls out from what I just said.  There is a "default" 
material - that just renders one texture with no fancy features.  So if 
you apply a texture to a mesh and don't provide a material for it in the 
material.xml file then you get a simple gouraud-shaded, textured, lit 
surface.  Pretty much what you'd expect.   You can override the standard 
"default.vs" and "default.fs" (vertex shader and fragment shader) to 
make the default material do something else if you wanted to.   In my 
application, I have it doing simple phong shading with white specular 
light and a standard shininess of 10.0.   Kinda makes everything look 
like plastic.

That lets you write applications without having to learn anything about 
shaders - but you'll probably want to use them most of the time because 
it's where the cool features are!

>> 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.
>   
Well - maybe.  But I'm not going to do it - if someone else wants to - 
the hooks are there.  I typicaly write very stand-alone applications 
that come with their own models - so long as I have a working 
tool-chain, I'm happy.  With what I have, I can build models in AC3D and 
my kid can build them (and animate them) in Blender.   Blender is pretty 
much the de-facto OpenSource modeller - so that's plenty for my needs.

> 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.
>   
Well, exactly.  If it doesn't support ALL of Collada then it's not 
really a standard.  SketchUp writes some special subset of Collada which 
GoogleEarth reads.  If you want features that GoogleEarth doesn't 
support but Collada does - then SketchUp can't produce them - if you 
author your Collada models with something else, it's completely unknown 
whether the model will look right in GoogleEarth.   If other people 
write applications (as we surely would) that implement a DIFFERENT 
subset of Collada then you end up having to build material that uses the 
intersection of two subsets...that gets really ugly.

As I pointed out years ago when we tried to get some traction behind a 
project called "LodeStone" - what we REALLY need is a standard scene 
graph API so that standard loaders and savers can be written.   But that 
somehow never happens.
> 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.
>   
Well, maybe - but as I said - it just doesn't interest me - so I won't 
be doing it...period.
> 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.
>   
My format will bear ZERO resemblence to Collada - it's basically an 
XML'ed version of the PLIB in-memory structures.  The reason being that 
I don't care much how long it takes to write a file - but I care 
passionately about how long it takes to load.  Hence the effort of 
standards conversions should be kept in off-line tools and not in the 
interactive application.

I can run a batch job once in a great while to convert models from 
whatever they are in (Collada, Blender, AC3D) to ".plib" and if it takes 
a couple of hours to run - that's no big deal.  However, when my end 
user starts up the game (or whatever) it needs to get going FAST - we 
don't want to be hanging around while some chunk of complicated code is 
trying to convert Collada shaders into GLSL or some fancy winged edge 
topography into triangle meshes.   This needs to be fast.

But as I said - there is nothing to stop people writing their own 
loaders and savers as they have for PLIB-1.