Performer has an optimized native file format. It has a feature you can
turn on so that any time it loads any model that isn't in it's native format
already, it will immediately write it back out in the native format with the
different extension. (And it will redo this step any time the non-native
version is newer than the native version.) The native format typically
loads 10x faster than openflight format we usually use in our driving
simulator application.
This ends up being a big optimization step for us. The first time a model
loads it can be slow, but after that scenarios load *way* faster.
What Tim is proposing sounds very similar to this, so I'm not sure why there
are strong objections here. It's a lot like caching the unoptimized models
in a much more optimized format.
Regards,
Curt.
On 10/13/07, Vivian Meazza <> wrote:
>
> Tim Moore
>
> > Sent: 13 October 2007 01:40
> > To: FlightGear developers discussions
> > Subject: Re: [Flightgear-devel] optimized generic_pylons and
> > .osg models
> >
> > Melchior FRANZ wrote:
> > > * Tim Moore -- Saturday 13 October 2007:
> > >> I've added a "feature" to SimGear that substitutes a model with a
> > >> .osg extension for other models (not .xml) when it exists.
> > This seems
> > >> to be a bit controversial [...]
> > >
> > > That's quite an understatement. You asked on IRC about that and got
> > > *only* objections. You were the only one who liked the
> > idea, IIRC. I
> > > find it quite disturbing that you ignore the opinions that
> > you *asked*
> > > for, and do it anyway.
> > >
> > If I had received only objections, I wouldn't have checked it
> > in. My characterization of the discussion, including
> > discussion today, is fair. This is IMHO an important
> > performance enhancement that I feel is important to get out
> > there. Like I said, I'm willing to change the mechanics of it.
> >
> > > I'd prefer that explicitly stated paths are respected and
> > > are not replaced behind the scenes. Now, if an XML file
> > only demanded
> > > a <path>foo</path> without extension, then it would be ok
> > to first try
> > > foo.osg and then foo.ac. But we told you yesterday ...
> > >
> > > m.
> >
> > My objective is to be able to override model file paths that
> > seem to be hard to change, like those in the scenery files.
> > Perhaps it's easier than I think to update those? How often
> > is the scenery rebuilt?
> >
>
>
> The discussion on IIRC was brief, late at night and the proposal was both
> not well put or understood.
>
> As I now understand it, the proposal is to automatically use .osg files in
> scenery in place of .ac files, where the former exist.
>
> I for one have no difficulty with this. If performance is better, or at
> least no worse, than with the .ac version, and provided that ft-lb is
> unaffected then no harm is done. This should be quite invisible to the
> user.
>
> I can't see that this should be in the least controversial. Let's try it
>
> Vivian
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Flightgear-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson - University of Minnesota - FlightGear Project
http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/
http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
