Converting AI aircraft to FSX with Model Converter X

From FSDeveloper Wiki
Jump to: navigation, search

This article gives a short overview of the requirements and information about the conversion process. It is by no means a full blown tutorial and users are encouraged (and required) to do some research on their own if they do not know their way around Model Converter X, the SDK or else.

Introduction

Most AI aircraft were designed and compiled for FS9. They work fine in FSX, but use the rather inefficient compatibility rendering scheme which prevents their usage in DX10 mode and poses a heavier drain on computer resources.
The available options to alleviate this problem would be the purchase of a payware AI traffic package containing FSX native models or only flying in DX9 rendering mode or the conversion of AI models with ModelConverterX.
The first option is nod valid if the user uses self-assembled AI traffic or does not wish to spend any money. The second option is not valid if the user wishes to experience FSX in DX10 mode. This basically only leaves the third option, which is the subject of this article and possesses the following advantages and disadvantages:

Advantages

  • Does not require any monetary investments.
  • A great way to kill a lot time.
  • Improved framerates at busy airports.
  • AI traffic can be used in DX10 mode.
  • Basic animations are retained.
  • LODs still work.
  • AI traffic will be seen at any add-on airport keeping "Aircraft cast shadows on the ground" ticked.

Disadvantages

  • Parts with visibility conditions attached to them, e.g. prop disks will be lost in the conversion process. (This is a current ModelConverterX limitation.)
  • Animations will sometimes not play properly in FSX.
  • Lightmaps from repaints made for FS9 are not properly displayed in FSX.
  • Models using custom XML coded animations will lose said animations unless you replace them with a FSX standard animation or some custom code.
  • The MCX export will screw up the bounding and radius boxes within the model file, so they'll have to be fixed by the user.
  • Conversion of a lot of models is very time intensive. Depending on available spare time and amount of models installed, it will take anywhere from one to two days to several weeks.

The value of a slight gain in performance at big airports versus the incurred disadvantages is left to be decided individually.

Licensing and disclaimer

Before continuing on, it has to be noted that this is an experimental procedure so no warranty of any kind is given.
More importantly, converting AI models from other authors may only be done for personal usage (or not at all, depending on how strict the license is interpreted on an individual basis).
In any case: Do not distribute converted models. They are for personal use only!

Requirements


Basics

Some basic acquaintance with ModelConverterX, especially its animation editor, is required. It is also strongly advised that users export an aircraft model with a name different to the original model (i.e. B737-200X instead of B737-200) and adapt the model.cfg file accordingly. This allows a quick reversal to the original model in case the conversation produces an undesirable result in FSX.

AI Aaardvark

Users wishing to convert their freeware AI traffic may start out with AI Aardvark's FSX native models, especially those with World Of AI packages installed.
The models are available at Avsim or Flightsim in a file called aiafsx01.zip.
The readme and .pdf contained in the download also explain some of the disadvantages mentioned in the last section in a bit more detail, so reading it is highly recommended!

Workflow

The basic workflow for a conversion is the following:

  1. Open the model with ModelConverterX
  2. Launch MCX' animation editor and replace animations with ones read from the modeldef.xml in the SDK
  3. Export model as a FSX native model
    • (Open model in MCX and check it)
  4. Adapt model.cfg (see "Basics" above)
  5. Open exported model file with RADItor and assign model radius and bounding box values

It is of course possible to adapt said workflow to individual needs.

Tips & Hints

These are some tips and hints to facilitate the conversion process or create a better understanding of disadvantages.

Auto-assigning animations upon export

ModelConverterX allows auto-assigning animations during export based on animation tag name in the modeldef.xml file. If there's an animation named reverser0 in MCX, MCX' exporter will look for said animation in the modeldef.xml during export. If an animation named reverser0 is found, the model will be compiled using said animation. This can be used to facilitate the compilation of aircraft by creating modeldef.xml entries for the most common animations.

A collection of animation codes for jet aircraft is available here. The code can be copied and pasted into the modeldef.xml file above the closing </ModelInfo> tag at its end.
Propeller aircraft require an extra step for the propellers by manually assigning prop_blurred or prop_slow animations for the props.

Unknown animations

Many models come with animations controlled by custom XML code, mostly for slats and flaps. Depending on the laziness of the end user, it is perfectly possible to preserve said animations by writing custom animation code or simply assigning the default animations to the parts in question.
The animation editor in MCX makes it possible to isolate animations piece by piece by unchecking known ones and moving the animation slider while observing the rendering window. Albeit tedious, it is a perfectly fine method to identify a good part of 'unknown' animations.
It should be kept in kind though, that some animations are dependent on each other to display properly, such as animated flap canoes and flaps.
If an animation can not be idnetified or is deemed redundant or unnecessary, it is possible to discard it from the model by using the Fix Animation button.

Handling visibility tag incompatibility

ModelConverter's (current) visibility tag incompatibility currently affects the display of ground equipment (if present in the model file) and, more importantly, prop disks and possibly rolling wheels.
Currently, the only ways to alleviate this drawback are either a full blown export and modification of the model in GMax as described here or a simply assigning prop_slow or prop_blurred animation tags to the propeller model. Same applies to the wheels.

Bounding box and model radius

Editing the bounding box and model radius of each converted model is mandatory, as MCX does not include realistic values for these upon exporting. Using RADItor, the user can set the values to his/her liking.
The model radius determines the parking spot usage of a model. If a parking spot with a radius of 20m is used in an AFX (airport layout) file, a model with a radius of 25m will not be assigned to use said spot by FSX. A value of half the wingspan of an aircraft plus 1 or 2m usually works for the radius, but users are encouraged to use values that work best for them.

The bounding box is generally used to determine a 'crash into aircraft' event. If crashes are enabled in FSX and an AI aircraft possesses a bounding box of several kilometers length, width and height, the user will receive a 'Crash!' event by taxiiing around an airport. It is therefor advisable to set said bounding box to decently realistic values.
X-values are used for the wingspan and can thus be set to half the wingspan each.
Z-values constitute the fuselage length. Dependiung on where the original model designer placed the model origin, these values will be, in most cases not entirely symmetrical. For simplicity's sake, however, it can be assumed that the model origin is present at half the fuselage length and thus, values for half the fuselage length can be used to set the bounding box in this axis.
Y-Values determine the height of the bounding box. As the model origin is most likely not located at ground level with landing gear extended, a generic ratio has to be applied for this value. Something along the lines of 'one third of the aircraft height' works for the negative y-value while the remaining two thirds can be applied to the positive value. The stance of the aircraft model on the ground is not affected by this as it is entirely determined by the 'contact points' in the aircraft.cfg.
As usual, it is of course possible to use more elaborate methods for defining the bounding box and model radius.

Tweaked animations

Tweaked animations for the rudder and the nose wheel can be found here. It has to be noted that these have to be assigned manually unless the names are edited to enable them for automatic assignment (see 'Auto Assigning' above). In the latter case, it has to be made sure that the tweaked animations are not conflicting with the ones present in the collection of auto-assignable animations (by deleting the old ones).

Possible night texture fix

An untested fix for the overly bright night textures in FSX can possibly be achieved with MCX' material editor. While the .pdf included in AI Aardvark's model package (mentioned above) shows a fix based on individual repaints, it is very, very time consuming to apply. Setting the 'Emissive Properties' in the editor to Multiplay Blend or User Multiply Blend might tell FSX to revert back to the lightmap behaviour from FS9. Users are encouraged to test this.

Full blown model edits in GMax

By using ModelConverterX' 'export to .3DS' export function, AI models can also be imported into GMax, as outlined for scenery models here.
The model will, however, be imported with temporary materials and will be missing all of its mesh smoothing and all of its animations, including keyframes.
Despite the extra work required, it enables the user to recreate the prop disks and other parts requiring visibility conditions.


References

Reference thread: http://www.fsdeveloper.com/forum/threads/fs9-fsx-aircraft-model-conversion-an-experiment.427512/