Re: [Flightgear-devel] Comments and questions about model loading, model formats, and effects....

[Jacob B. <jmb...@gm...>]

On Sun, Dec 12, 2010 at 10:51 AM, Curtis Olson <cur...@gm...> wrote:
> On Sun, Dec 12, 2010 at 9:21 AM, Jacob Burbach <jmb...@gm...> wrote:
> Would it be possible to come up with our own optimized model extension that
> would be unique and different from anything an artist might produce?  I
> could see this heading off into a lot of work though.  We maybe would want a
> global flag that specifies if model optimization should be turned on / off.
>  Saving an optimized version of every model could significantly increase the
> harddrive footprint of our data tree.
> Just thinking out loud here ...
> Curt.

Also thinking out loud...

First thing to do in my opinion would be to put the ac3d format to
rest and focus on one single, feature rich, capable, and portable
format for fgfs content creators to work with. I think collada is
probably an obvious choice for this.  Then...

a) Load the collada (or whatever) file directly, automatically caching
it to native format / global cache somewhere for reuse. The loader
would then check the cache first to see if a file is already there and
load it from there, if not or if the source file has changed reload it
and (re)cache it. This has advantage that content creators could just
work with one format and everything else happens automatically behind
the scenes without need to think about it. This also has disadvantage
that when a user first loads new content (aircraft, scenery, etc)
performance will be bad that first time as you have to load
unoptimized and large files and then cache them. There is also the
problem of content that is removed, still existing in cached form, and
the amount of disk space needed growing much larger as you now, in
some form or another, have multiple versions of the file in question
on your disk.

b) Provide a fgfs converter tool that takes the collada (or whatever)
file the content creator works with and creates the fgfs native format
out of it which can then be used by flightgear.  This has the
advantage that your always loading the native optimized format, there
is no worry about how to handle caching in the background, or large
amounts of space used for the cache, or how to hand orphaned items in
the cache..etc. Also by having the converter provide various options
for the content creator to enable/disable etc.... one puts more power
in the content creators hands which is usually a good thing. Couple
disadvantages would be that; 1. content creators have to convert the
stuff before using it or distributing it, and 2. that end users get a
native format they can't modify directly.  Number 1 is not really a
huge deal at all though, and could be easily automated too. Number 2
is easily addressed by simply having the fgfs converter tool work in
both directions. Run the converter on the collada (or whatever) and
you get the fgfs native format for distribution, run the converter on
the native file and converts back to the collada (or whatever) format
for import into your content creation app of choice for editing.

I kind of prefer option b, as I think it provides the most flexibility
for artists, simplicity for the engine, and no worries about larges
amounts of space used by a global cache or secondary files, etc.

----

That said, anything like that sort of thing would obviously take a lot
of planning, work, and time to complete. Even if it was decided to go
in that direction for the future, I think it would be important to
allow for other formats than ac3d to work properly with the
material/effects system first, so we have some much needed ability and
performance possibilities in the short term.

cheers
--Jacob