On Mon, 27 Dec 2004 19:27:03 -0000, Jim Wilson <[EMAIL PROTECTED]> wrote:

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

The same thing that is involved in switching to any format -- writing
a VRML 1.0 importer for plib (or directly for FlightGear).  The
advantages of VRML are

a) *every* 3D modelling program can import and export it; and

b) it's text-based, so it's easy to debug problems and to generate
VRML models or components using scripts.

VRML was meant to be as big as HTML, creating a new, 3-D web browsing
experience.  That was total BS, of course -- I mean, do you really
want to use a 3-D interface to bid on eBay or check movie listings? --
and to try to recover from the 3-D-for-the-web failure, llater
versions of VRML added actions and all kinds of extra stuff that few
ever implemented properly; it was also eventually XML-ified.  The
original, text-based, non-XML VRML 1.0, which is fairly simple, should
have all we need for textured meshes, however.  There is currently a
VRML 1.0 importer in plib, but it doesn't quite work (it messes up on
textures, if I recall correctly).  Having a VRML 1.0 importer that
worked as well as the AC3D importer would make things very easy --
just tell people to "save as VRML" no matter what modeller they're

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

The trick is coming up with something that loads faster than the XML,
or the caching is pointless.  Out in the wild, people have tried and
mostly failed.  Most of the overhead, I think, comes not from the XML
parsing but from opening and closing so many tiny files, so 100
pre-compiled binary files will take just about as long to load as 100
text XML files -- perhaps if you could dump everything into a single
file, load times would improve.

When I turn on debugging output, most of the load time does not seem
to be reading config files, though.

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

Yes -- give me a place to put my models, and I'll gladly make the
Blender source available.  Right now, it's in a temporary directory
for anyone who wants it:


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

You have to distinguish between the maintainer and contributors.  As
long as I'm maintaining, say, the J3 Cub model, any contributors
should make their changes to the Blender source, since Blender is my
chosen format.  If a different maintainer takes over (or forks the
model), then that maintainer may choose to keep the source in 3DS,
AC3D, or some other format.  I don't think that we should dictate to
people what modelling program they have to use, though, obviously,
they'll do better attracting contributors if they use an Open-Source
one, or at least a cross-platform one.

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

You will lose information that's useful to the modeller, like, say,
object grouping.  VRML is good enough for displaying a model in
FlightGear, but just about every modeller keeps a lot of extra
information around that's useful to the designer, and that will be
lost.  If a new maintainer is taking over and wants to switch to a
different modelling program, VRML is a good way to get the basic mesh
objects and textures in there, but then there will be some work
regrouping, etc.

> Can blender even import it's own exported
> VRML and have all the features intact?

No, because VRML just stores the basic mesh objects and textures, not
all the other Blender information (which FlightGear doesn't use
either, by the way).  It's somewhat similar to saving as RTF and then
reloading into Word or OpenOffice.

All the best,



Flightgear-devel mailing list

Reply via email to