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 using. > 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: http://www.megginson.com/Private/Models/ > 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, David -- http://www.megginson.com/ _______________________________________________ Flightgear-devel mailing list [email protected] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
