Mini-HOWTO: 3D Aircraft Models in FlightGear

11 March 2002

David Megginson

Introduction

This mini-HOWTO explains how to add 3D aircraft models to FlightGear, and how to animate and position those models. No C++ programming is required, but the user will need some knowledge of FlightGear's property system and XML markup, and will need to understand the coordinate system FlightGear uses for its models:

distances are in meters
angles are in degrees
the x-axis runs lengthwise, towards the back
the y-axis runs sideways, towards the right
the z-axis runs upwards
heading is a rotation around the z-axis, where positive is clockwise viewed from above
pitch is a rotation around the y-axis, where positive is clockwise viewed from the left
roll is a rotation around the x-axis, where positive is clockwise viewed from behind

[[TODO: will someone volunteer to draw diagrams?]]

This mini-HOWTO contains three parts:

1. Loading the model

Through plib, FlightGear supports many different 3D file formats, including VRML1, AC3D, DXF, MDL (from Microsoft Flight Simulator), and many others. The property /sim/model/path in the main FlightGear property tree controls what model will be loaded; it takes a string value giving the relative path of the model from FG_ROOT (the root of the base package, such as /usr/local/share/FlightGear or C:\FLIGHTGEAR\).

The easiest way to load a new model is to set the property at startup with the --prop: command-line option; for example, to use a 3D aircraft model that you have installed in $FG_ROOT/Models/my-cessna.wrl, you could invoke FlightGear like this (under Unix-like systems):

fgfs --prop:/sim/model/path=Models/my-cessna.wrl

(Note: Normally all textures used by the model must appear in the same directory. If my-cessna.wrl uses the textures cessna01.rgb and cessna02.rgb, you should also install those textures in $FG_ROOT/Models/. It is howerever possible to specify a path (relative to the model path) to specify where the textures could be found.)

When you want to set a 3D model permanently as the default for an aircraft rather than specifying it on the command line, you need to edit an aircraft settings file. In the $FG_ROOT/Aircraft/ directory there is a series of files ending in -set.xml, such as c172-set.xml, dc3-yasim-set.xml, and beech99-uiuc-set.xml. When you start FlightGear with the --aircraft option, it reads the properties from one of these files; for example

fgfs --aircraft=dc3-yasim

Loads the properties from $FG_ROOT/Aircraft/dc3-yasim-set.xml into the main FlightGear property tree. These files are in the same XML property-list format as $FG_ROOT/preferences.xml and the FlightGear save files. There may be many XML files with different startup conditions, sounds, panels, 3D models, etc. for any single aircraft type, so you are best off copying an existing one, renaming it, then changing the value inside the path element inside model inside sim:

<PropertyList>
 <sim>
  <model>
   <path>Models/my-cessna.wrl</path>
   <texture-path>./Textures</texture-path>
  </model>
 </sim>
</PropertyList>

So far, all of the examples have had the /sim/model/path property point directly at the 3D model file (Models/my-cessna.wrl); however, if you want to be able to reposition or animate the model, you need to point to an intermediate XML file instead, and then put the repositioning and animation information into the XML file. Here's a simple example of a 3D-model wrapper file, with no repositioning or animation information:

<PropertyList>
 <path>my-cessna.wrl</path>
 <texture-path>./Textures</texture-path>
</PropertyList>

Like the -set.xml files, this file is in XML property list format, but the properties in it are not added to the main FlightGear property tree; they're used only while loading the model. The following sections will explain how to add repositioning and animation information to the file; for now, the only property to worry about is path: it provides the relative path to the actual 3D file from the XML wrapper file (not from FG_ROOT!). Usually, you should put the wrapper file in the same directory as the 3D file, and then have /sim/model/path point to the wrapper file, either on the command line

fgfs --prop:/sim/model/path=Models/my-cessna.xml

or in the -set.xml file:

<PropertyList>
 <sim>
  <model>
   <path>Models/my-cessna.xml</path>
  </model>
 </sim>
</PropertyList>

2. Repositioning the Model

Often, an aircraft model not designed specifically for FlightGear will not be positioned or oriented correctly; for example, it might be too far off the ground, and the nose might point to the side or even straight up.

Inside the XML wrapper file (not the main FlightGear property tree), there are six properties that allow you to tweak the default position and orientation of the model:

/offsets/x-m: The distance to reposition the model along the x-axis.
/offsets/y-m: The distance to reposition the model along the y-axis.
/offsets/z-m: The distance to reposition the model along the z-axis.
/offsets/heading-deg: The angle by which to rotate the model around the z-axis.
/offsets/roll-deg: The angle by which to rotate the model around the x-axis.
/offsets/pitch-deg: The angle by which to rotate the model around the y-axis.

For example, if you wanted to use the 3D model my-cessna.wrl but found that the nose was pointing to the right instead of straight-ahead and the wheels were 1.5 meters off the ground, you could reorient it in the XML wrapper file like this:

<PropertyList>
 <sim>
  <model>
   <path>Models/my-cessna.xml</path>
  </model>
 </sim>
 <offsets>
  <heading-offset-deg>270</heading-offset-deg>
  <z-offset-m>-1.5</z-offset-m>
 </offsets>
</PropertyList>

It usually takes a bit of experimentation to get the model positioned correctly.

3. Animating the Model

Now for the interesting part. FlightGear allows you to animate models by having parts rotate or spin in response to property changes: for example, the propellers can spin when the engine is on and the elevators can move up and down with your controller. There is no fixed limit on what parts can be animated: the only requirements are that the part is named in the 3D model file, and that there is a property in the main tree that you can use to get the positioning information.

Currently, there are three types of animation recognized:

none
spin
rotate

In the future, many more will be added, but the last two are sufficient for animating the main control surfaces of many standard-configuration aircraft. none is a no-op; spin rotates the object around an axis with a known rotational velocity (not worrying about the exact position), and rotate rotates the object around an axis to an exact position.

Every animation appears inside an animation element, and contains a type property and at least one object-name property:

<animation>
 <type>rotation</type>
 <object-name>Rudder</object-name>
</animation>

The object name must match exactly the object name used in the 3D file (including case). You may include more than one object name to apply the same transformation to more than one object, assuming that they rotate around exactly the same line:

<animation>
 <type>rotation</type>
 <object-name>LeftElevator</object-name>
 <object-name>RightElevator</object-name>
</animation>

Each animation must be associated with exactly one property from the main FlightGear property tree (remember that the properties in the wrapper file are not part of the main tree), using property to provide the property name:

<animation>
 <type>rotation</type>
 <object-name>Rudder</object-name>
 <property>controls/rudder</property>
</animation>

Note the omission of the leading slash '/' when reffering to the property. This assures that when the model is used for AI traffic the animations will follow that of the AI controller instead of that of the user.

This example rotates the rudder according to the value of the controls/rudder property (or at least, it will when we specify the center and axis of rotation below); however, controls/rudder is normalized from -1.0 to 1.0, and we probably want to rotate the rudder more than that; as a result, we need to use the factor property to do scaling. For example, if the rudder on the actual aircraft rotates 18 degrees in each direction, we would use a factor of 18 to scale the rudder position from -18 degrees to 18 degrees:

<animation>
 <type>rotation</type>
 <object-name>Rudder</object-name>
 <property>controls/rudder</property>
 <factor>18</factor>
</animation>

If you wanted to reverse the direction of rudder movement, you would use a factor of -18.

There is also an offset property that can be useful for starting the rotation from a point other than center. For example, let's say that you want the rudder to start 1% to the left rather than dead center; you could specify that like this:

<animation>
 <type>rotation</type>
 <object-name>Rudder</object-name>
 <property>controls/rudder</property>
 <offset>-0.01</offset>
 <factor>18</factor>
</animation>

The offset is applied before the factor.

Finally, there are min and max properties that can constrain the amount of rotation in degrees, as in this (very complicated) example for the Cessna 310 landing gear:

<animation>
 <type>rotate</type>
 <object-name>NoseWheel</object-name>
 <property>gear/gear[0]/position-norm</property>
 <factor>120</factor>
 <offset>-1</offset>
 <min>-90</min>
 <max>0</max>
 <center>
  <x-m>-2.28</x-m>
  <y-m>0.0</y-m>
  <z-m>-0.65</z-m>
 </center>
 <axis>
  <x>0</x>
  <y>1</y>
  <z>0</z>
 </axis>
</animation>

In this example, the gear position (from 0.0 for fully retracted to 1.0 for fully extended) is multiplied by a factor of 120 and an offset of -1, then clamped to between -90 and 0. In the 3D model, the gear is extended by default, so we end up with the following rotations through the gear's range of movement:

position-norm	+ offset -1	* factor 120	clamped to min/max -90:0	comments
0.0	-1.0	-120.0	-90.0	fully retracted
0.25	-0.75	-90.0	-90.0	still retracted
0.5	-0.5	-60.0	-50.0	1/3 extended
0.75	-0.25	-30.0	-30.0	2/3 extended
1.0	0.0	0.0	0.0	fully extended (default position)

The gear does not move at all during the first 1/4 of the position-norm value, giving the doors a chance to open and close in a separate animation. Obviously, this would be easier to manage with an interpolation table, and future versions of the model animation will likely support interpolation.

For a spin animation, the property provides a value in revolutions per minute (RPM) rather than an absolute position in degrees, and offset is not used. You can still use factor to scale the property value if it is not in RPM.

Now, it is necessary to specify the axis of rotation for the object, its virtual hinge. This is often the hardest part, requiring a lot of trial-and-error when the axis of rotation is not lined up with the x-, y-, or z- axis (think of ailerons on a swept wing with a non-zero dihedral angle). You need to provide two groups of information: a point through which the axis of rotation passes, and the direction in which the axis is moving.

For the point through which the axis passes, you use the /center/x-m, /center/y-m, and /center/z-m properties to specify a position in meters, using the aircraft's coordinate system. Note that this is the system before repositioning: if the original model was pointing sideways, then your fuselage will run along the y-axis rather than the x-axis. Here is an example for a rudder:

<animation>
 <type>rotate</type>
 <object-name>Rudder</object-name>
 <property>controls/rudder</property>
 <factor>18</factor>
 <center>
  <x-m>5.45</x-m>
  <y-m>0.0</y-m>
  <z-m>0.0</z-m>
 </center>
</animation>

In this example, the point is right on the y and z axes, but 5.45 meters along the x axis (i.e. towards the back of the plane).

Finally, in addition to the center point, it's necessary to specify the direction of the axis that passes through it, using the properties /axis/x, /axis/y, and axis/z. These are unitless values showing the rate of change in each direction; for example, a straight up-and-down rotational axis could be specified like this:

<axis>
 <x>0</x>
 <y>0</y>
 <z>1</z>
</axis>

or like this:

<axis>
 <x>0</x>
 <y>0</y>
 <z>1000000</z>
</axis>

Since there's 0 movement along the other two axes, it doesn't matter. On the other hand, let's say that the rudder hinge sloped back 5% because of a swept tail. In that case, the x-axis would have to show some movement as well:

<axis>
 <x>0.05</x>
 <y>0</y>
 <z>1</z>
</axis>

That could just as easily be written as

<axis>
 <x>1</x>
 <y>0</y>
 <z>20</z>
</axis>

as long as the ratios are the same. For a complicated rotation axis, like that for an aileron on a swept-back wing with a significant dihedral angle, you'll have to specify movement along all three axes:

<axis>
 <x>0.15</x>
 <y>1.00</y>
 <z>0.01</z>
</axis>

Here's a complete example, showing the animation for the rudder on the Cessna 172:

<animation>
 <type>rotate</type>
 <object-name>Rudder</object-name>
 <property>controls/rudder</property>
 <factor>18</factor>
 <center>
  <x-m>5.45</x-m>
  <y-m>0.0</y-m>
  <z-m>0.0</z-m>
 </center>
 <axis>
  <x>0.72</x>
  <y>0.0</y>
  <z>1.0</z>
 </axis>
</animation>

And here's an example of a spin, using the Cessna 172 propeller:

<animation>
 <type>spin</type>
 <object-name>Propeller</object-name>
 <property>engines/engine[0]/rpm</property>
 <center>
  <x-m>0</x-m>
  <y-m>0</y-m>
  <z-m>-.25</z-m>
 </center>
 <axis>
  <x>1.0</x>
  <y>0.0</y>
  <z>0.0</z>
 </axis>
</animation>

You can get a lot of your initial measurements by viewing the model in a 3D editor like PPE, and you can also use PPE to name or rename objects so that you can animate them in FlightGear. In the end, though, you'll almost have to do a little tweaking by trial and error until everything looks right.

This document will likely be out of date by the time you read it. Look at the actual XML wrapper files (currently in $FG_ROOT/Aircraft/aircraft-type/Models/) to look at how FlightGear is doing things now. In the future, we'll be adding other animation types, including selecting among different versions of the same object (such as a translucent propeller disk for high RPM), non-rotational transformations, scaling, and conditionals (i.e. draw engine exhaust only above a certain velocity).

David Megginson, 11 March 2002