Boris Koenig wrote:
Durk Talsma wrote:

For this and other reasons, I'm currently leaning toward favoring having a separate set of low-polygon count models for AI aircraft. The basic idea would then be to have a directory looking like this:


I like the idea of having such a low-polygon repository of standard
aircraft files, however they would certainly not only come in handy
for the AI traffic part but also for other things like multiplayer

So in that regard it might be worth to think about providing some
sort of standard folder for all components that might actually make
use of such (reduced) aircraft files - so that this isn't specific
to the AI component itself ?

which then has subdirectories for each aircraft. Like



and within each directory there are subdirectories for various liveries for example:


etc etc

I like this, but I would propose that the standard place to put an AI version of an aircraft would be a subfolder of the actual model's folder. The parent folder could exist even if there was no flyable model, and the parent folder could likewise not contain an AI folder. This way a designer could build the AI and/or flyable models and then release them in one tarball.

eg data/Aircraft/FooPlane/AI/American

FooPlane: FooPlane-set.xml, Sounds, Model, etc. (or nothing but AI)
FooPlane/AI: AI files
FooPlane/AI/American: American Livery

I think it sounds like a good idea, however I wonder whether *liveries*
shouldn't be placed in some central location, specific to certain
(fitting) aircraft models - independent of the AI stuff ?

So that they can be found in some sort of default location and
would hence be optionally available for either: AI traffic
and/or user traffic or even other/future components.

Then inside each of these livery subdirectories there would reside not only the texture files for the respective aircraft, but also all the traffic files for this aircraft.

At least for the multiplayer functionality within MS FS it is
nowadays a pretty common feature to allow users to pick a custom
livery  for their (online) flight - that would be another scenario
where AI files would/could be accessed by NON-AI components.

So, even without having such or similar support within the near future
I would still vote for a central "repository" that contains the
aircraft specific stuff such as the textures/liveries & models for
"LOWPOLY" aircraft - after all it would be merely a matter of
adding another subfolder...

That way those FG components that actually use the "LOWPOLY"
stuff wouldn't need to fool around with the AI sub-directory.

The traffic manager would then scan this directory and automatically load all the traffic files it would find here. This way, adding or removing AI aircraft would automatically adjust the amount of traffic generated.
Any thoughts or ideas?

My first thought concerning the last paragraph would be that it would
probably come in handy not to statically use _all_ traffic files that
are available within the AI folder but rather make this dependent on
some simple property that allows adjustment of the AI traffic complexity
and some other parameters.

That way, one could have various traffic files without actually having
to use them, one wouldn't even need to directly manipulate the files
in that folder to control some basic options.

Talking about low-polygon aircraft, it sounds like additional work
for the aircraft maintainers to really maintain different models
for the same aircraft types ?

So I wonder what would be involved in artificially reducing the polygon
count of an abitrary model at load/processing time, e.g. by using only a
certain percentage of the 3D data and ignoring the rest ?

If that logic isn't too simple one could still refer to the same
(complex) polygon model but only use a subset of the data to render
an accordingly reduced model ?

There are automatic LOD reducing programs out there, but all the output that I have seen is ugly and only suitable to simple modeds viewed at a large distance.


Flightgear-devel mailing list

Reply via email to