David Megginson said:

> On Sat, 25 Dec 2004 16:23:29 -0600, Curtis L. Olson
> <[EMAIL PROTECTED]> wrote:
> > .ssg format is basically a binary memory dump of the internal ssg
> > structures.  This has some advantages within plib-based applications,
> > but it would be tough to build an exporter from a non-plib application.
> > It would be a lot simpler to build a plib-based converter, but then
> > you'd need to be able to read the source format into plib anyway.  .ssg
> > is extremely non portable, and would make it very difficult for people
> > to edit the models with any non-plib based modelers, and I'm not aware
> > of any plib-based modelers that are far enough along to be useful.  I
> > think we would do better to stay with high level 3d formats.
> I know that no one particularly loves VRML, but it is text based (like
> AC3D) and open.  As long as we're just doing textured and tinted
> meshes, with the more complex stuff (like animations) in external XML
> files, is there any good reason *not* to go with VRML, especially
> since we can compress the files on disk with gzip?

This sounds interesting, I'm just not familiar enough with it.  What would be
involved in making this change?

Curt's idea of storing .ssg in a cache fashion also sounds interesting.  Sort
of along the same theme I'm wondering if we could gain some benifit by caching
binary representations of other XML config files (like 3d cockpit animations,
etc).  The amount of xml processing during intialization is becoming quite
large in some cases.

In reference to the original question on this thread,  should we as a project
be maintaining blender (or MAX, etc) _sources_ regardless of which direction
we take?  If a given model was developed in blender,  shouldn't we be
providing blender sources in a _base package source_ distribution so that
future changes are also handled by blender users?  This particular problem as
I see it is that once an exported to ac3d model is commited to cvs with
changes from an ac3d user, then the blender users are nolonger able to
contribute to that model.

Of course the flip side to this argument is that if we commit to providing
blender sources and requiring blender source modifications (which itself is
fraught with blender version issues),  then we effectively commit to the
blender format for that model,  regardless of which format FlightGear actually

Would VRML give us true modeler portability?   Can ac3d (or whatever closed
source modeler) import a VRML model and have all features intact,  and then
export it back to VRML in a way that a blender user could import the same
model and see the same changes?  Can blender even import it's own exported
VRML and have all the features intact?



Flightgear-devel mailing list

Reply via email to