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 functionality.
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:
data/Aircraft/AI/777/American data/Aircraft/AI/777/KLM data/Aircraft/AI/777/United
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.
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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d