Howto:Make an aircraft
 |
The FlightGear forum has a subforum related to: aircraft development |
There are many things required to develop an aircraft for FlightGear.
Some suggestions for those relatively new to modeling wanting to contribute models to Flightgear:
- If fidelity is a factor, avoid anything where you cannot find clear high-resolution 3-views or engineering schematics. Don't rely on the cheesy little 3-views found all over the Internet-- the resolution is too low to be useful and they are often not accurate.
- Avoid obscure aircraft where information is scarce.
- Avoid anything with lots of external detail.
- Avoid anything with lots of compound curves.
- Do not start with cockpit modeling, at least not anything more elaborate than very simple GA aircraft. Cockpit modeling is complex and poses some of the most difficult and frustrating challenges in aircraft modeling.
- Excessive 3D modeling is often unnecessary. Much can be done (and in my opinion should be done) through smart use of textures and normal maps.
The advice to start with modeling ground objects like buildings is sound. It's a good way to learn and quickly benefit the community. Another alternative is to try modeling some cockpit instruments. Whatever you do, keep your initial project limited in scope and within your capabilities.
We encourage new aircraft developers to start their 'career' by modifying and enhancing existing aircraft. It is much easier to do and gives you a giant advantage by the time you create an aircraft completely by yourself.
This approach has a number of things going for it that benefit the FlightGear community as well as someone new trying to become an active member of the community. There are currently way too many aircraft in a very incomplete state that need tons of work. By working on these less complete aircraft you help move the ball forward on that aircraft. For someone new to one of the best places to start is doing cockpit work. Since the learning curve is fairly steep (you need to learn a 3D modeling tool plus a lot of other stuff that has been mentioned in this thread) it is best to start with something very simple.
|
One of the better approaches for a noob is to start out working on improving something that is already there but needs work. It limits the steepness of learning curve and allows you to actually get something done in the short term. This allows you to keep the frustration level down while learning how things work. Only a small % of aircraft development noobs who start a new aircraft without having done some previous work on another aircraft actually manage produce something worth while. It does happen but it is rare - the recent Bonanza work by a noob is an example of one of these rare cases. A much larger % of those who start off doing smaller tasks on existing aircraft end up making a significant contribution either by doing smaller things to a lot of aircraft or by transforming an existing aircraft into something much better (the P-51D is an example of one of these) or after building a decent skill set doing their own aircraft from scratch.
|
|
Things like placards, stream gauges or switches should be where you start. Adding placards is by far the simplest thing you can do for a cockpit and almost any aircraft you pick in the FGAddon aircraft hangar, even some very advanced models, will need at least one or more placards. Placards also add a lot of cockpit detail for very little effort although for a rank beginner it will still take a significant amount of effort to get a placard modeled and textured and into a cockpit. These do not need animation or any interface to the property tree or any nasal code and only minimal XML. This helps reduce the steepness of the initial learning curve. After doing a few placards you can step up to steam gauges. These will require more extensive XML and also animation and interfaces to the property tree and perhaps even some nasal code and the 3D models will be more complex than that needed for placards. But the 3D models will not be very complex relatively speaking and you will be able to use existing models as a starting place since gauges are build to a set of standard sizes and external configurations at least in modern (IE. WWII and later) aircraft.
Almost any aircraft maintainer should be willing to mentor someone new to add things like placards and gauges to an exiting model. Some will insist on very high standards for anything you do so please try to do quality work. But keep in mind that as a new contributor that the aircraft maintainer will likely spend more time helping you get up the learning curve than the amount of effort it would have taken them to do the same work themselves. So please do enough work on that aircraft to reach at least the break even point for the mentoring effort. Also keep in mind that an aircraft maintainer would prefer that new contributors coordinate with them to prevent duplication of effort and to make integrating the contribution into the aircraft easier.
I also think it is important to work on an aircraft that you have some passion for. This is tedious, detailed, time consuming work that requires a level of dedication to overcome the hurdles involved. If you don't have a certain level of passion for what you are doing you will not persevere. On the other hand doing this work will result in learning a lot about a wide range of things (3D modeling, how to research things, animation, 2D graphics, FlightGear, nasal...) and if you persevere you will find this very rewarding.
One thing that is coming is a better aircraft manager, which will allow aircraft to state their compatibility, so the GUI won't (by default of course) show you aircraft that don't work with your FG version. The problem then is getting more people to maintain aircraft and at least test them + tag them when a new version is being tested. Usually fixing an aircraft is < 1 hour work, with some help, but people are very reluctant to do it. Maybe we need an 'adopt an aircraft' for the unmaintained ones.
The content in this article gives a summary of codes and can be found on most planes. So, for examples on how it's used, you can take a look at some random planes.
Probably the easiest way to get a new aircraft going is to find another (similar) JSBSim/YaSim aircraft that is similar to yours and look at how it is setup. Even easier would be to copy that models configuration and then start making modifications to suit your aircraft. JSBSim can be complex depending on how advanced your aircraft is but using the copy and modify approach will allow you to get started and give you a platform to learn new stuff as you make modifications to the configuration.
Additional information is available in a special forum topic 
.
Before you start
If you are a complete beginner, knowing the processes involved will help out quite a bit. Roughly 4 simplified steps, first creating your 3d model, then the FDM, followed by creating animations and finally to implement systems. Each aircraft in FlightGear has two main development areas:
- The Flight Dynamics Model (FDM): This tells the computer how your aircraft reacts to various conditions. The FDM is composed of two main models most people use, either JSBSim or YASim. Or the lesser used model UIUC. Define the dimensions, mass-and-balance data. Tell FlightGear which part of your aircraft and where it may hit the ground. Where the gear is, if and how it travels. How it is propelled and how it flies if you move the controls. A subarea of the FDM are integral systems like the autopilot and fuel systems.
- The appearence of the aircraft, which can be split in two areas:
- 3-dimensional model and all of its visual aspects: animations (These give visual feedback from your FDM. Move the aileron of your 3D model when the aileron control is moved. Same for the other aero surfaces, the gear. Than go ahead with the instruments, animate the needles, the digital readouts. Define hot spots and pick animations, so you can click in your 3D cockpit.), lighting and textures (images that are put in specific locations on the 3D model).
- Auditory (sounds).
Introduction
There are lots of FlightGear aircraft that need cockpit work. This requires both artistic (create 3D models and textures...) and technical abilities (create XML, perhaps even nasal scripts and gathering information of the thing being modeled). This is also one area were your work is very visible to every day FlightGear users and this makes this effort one that has a major impact of the apparent quality of FlightGear.
This is also a very good place to start working on things in FlightGear. So how do you go about doing this?
- Find an aircraft that is part of the FGAddon aircraft hangar that needs cockpit work that interests you. This is important the aircraft should be one that you have a fondness for. This work is a labor of love and that will not be the case if you just pick some random aircraft.
- Ask on the forum and perhaps also on the developers list who the current dev for that aircraft is.
- Contact that person and ask them if it is OK to work on that aircraft. They will probably say OK but they will also probably say that you have to work in a certain way and they may go as far as saying OK but I want you to work on <some particular instrument or control>. Don't take this as a snub. The aircraft dev has put a lot of effort into this aircraft and in the end they have to live with whatever you do to it so you have an obligation to do things their way.
- Try to start out with something very simple such as adding a switch (or a switch panel with a few switches) or a placard. This may seem trivial but you will learn a lot from doing something simple while at the same time minimizing the learning curve and your level of frustration.
- Also the aircraft dev will likely have to spend time mentoring you and it may actually take him more time to do this mentoring than it would have taken him to do the work. So stick around and do enough work to that aircraft that the mentoring effort pays off for the aircraft dev.
- Keep in mind that the learning curve is fairly steep and at first the work will take a lot of effort to do what would be trivial task for someone with lot of experience doing this stuff. You need to be ready to deal with the learning curve.
Rules and guidelines
- All images in FlightGear should be sized to powers of two (eg. 64*64, 128*256 or 16*1024). Most computers cannot handle textures larger than 4096 pixels. Since FlightGear 1.9, images no longer have to be saved in the .rgb format. Right now .png is most common used among FlightGear developers.
- Please note that we use spaces in our codes, some developers use rather tabs, to make our code easy(er) to read. Every line that starts a new tag, we press the Space key once, so you get a kind of stairs. It does not really matter what method you use, as long as you use it consistently throughout all of your files. But XML files that are used by JSBSim FDMs must use spaces and not tabs.
- Filenames and directories are case-sensitive on most OS's. Windows is not case-sensitive, so when you are developing on a Windows machine, you won't notice any problems. On other OS's, there is a difference between 'Boeing' and 'boeing'. Since FlightGear is used on multiple platforms, make sure your code makes correct usage of capitals!
Tools of the trade
If you realize this is harder than you expect, don't worry. For the first-timer, the FDM(aircraft.xml), aircraft-set.xml, and the engine.xml files are the easiest. Modeling will require considerable time and practice. You want to have the tools for the job, so here are some tools to help:
- Aeromatic (works only for JSBSim, gives you entire engine file and FDM (aircraft.xml) file.
- JSBSim Commander (Only JSBSim, helps with the multitude of tags, try this on your aircraft BEFORE you release it and AFTER you are finished with all the xmls)
- This wiki
- Flightgear Forum
- Design plans and specifications of your aircraft, including:
- Three-View Plan (shows front view, top view, side view)
- Technical Specifications (from Wikipedia, Boeing, or Airbus)
- NOTE: Implement the specifications into the xmls
- A friend, and/or another developer, let's say you only want to do the FDM and XMLs. You'll need another person (a modeller) to model. Don't worry, the <author> tag has enough room. ;)
- A lot of patience
Directories and files
The data created during development results in many files, which are stored in several directories per aircraft. Each aircraft has its own directory in the $FG_ROOT/Aircraft/ directory. The first thing to do when you start working on a new aircraft is to make a directory for it. A short version of the aircraft name (eg. harrier), or its serial number (eg. 747-400) is prefered. More directories might be needed further on, but we will create them when we need them. They are explained in this article, but you can skip them if you are working on your first aircraft. For now we create one directory, namely:
- Models/ all files related to the appearence of the model are saved in this directory.
All paths are relative to $FG ROOT, with the exception of some that are explicit noted.
- Hint for Developers: You can pre-test all your .xml files without having to load FlightGear by opening them with Internet Explorer or Mozilla Firefox. These web browsers will parse XML documents and let you know if you made a mistake coding them.
It's worth noting that FlightGear doesn't expect any particular structure of folders or files, i.e. you could theoretically put things ANYWHERE, as long as you properly reference all files and paths in the top-level aircraft-set.xml file. However, it makes sense to follow some existing conventions (look at other well-maintained aircraft). Some more tips can be found here: Standard aircraft structure (needs to be updated as of 05/2012). A more recent discussion covering the pros & cons of the various approaches is to be found on the forum .
Root directory
-set.xml file
|
|
The most important file describing the aircraft's dependencies is the aircraft-set.xml file.
.xml file (FDM)
This file contains the entire (or partial) Flight Dynamics Model of the aircraft. We have three different systems; they all have their up- and downsides.
- YASim, needed for: helicopters, towing over a multiplay network
- JSBSim, needed for: pushback (external forces)
- UIUC (rarely used these days)
With limited data available, YASim is generally considered to be the best way to go. When you have acces to real windtunnel data and/or require more flexibility, JSBSim might be a better choice.
Engines/ directory
Only required for JSBSim aircraft. In this directory the engine and thruster/propeller files are stored.
Models/ directory
This directory contains all model related files; such as textures, models and animation files (.xml). In the -set.xml file we've set the path to one .xml file. That file should link (indirect) to each other model file (including a possible 3D cockpit) needed for the plane. The whole plane could be modeled into one file, but most developers prefer to split things up. A cockpit for example can be built up by several files, each existing of just one instrument or panel. This way it is easy to (re)move certain parts of the aircraft. You set up your model file like this:
<PropertyList>
<path>Aircraft.ac</path>
<model>
<name>Cockpit</name>
<path>Aircraft/.../Models/cockpit.xml</path>
<offsets>
<x-m> -5.25</x-m>
<y-m> 0.00</y-m>
<z-m> 1.30</z-m>
</offsets>
</model>
<animation>
<type>rotate</type>
<object-name>AileronLeft</object-name>
<property>/controls/flight/aileron</property>
<factor>-65</factor>
<center>
<x-m> 2.09</x-m>
<y-m>-5.50</y-m>
<z-m>-1.50</z-m>
</center>
<axis>
<x>1</x>
<y>0</y>
<z>0</z>
</axis>
</animation>
</PropertyList>
The cockpit.xml file can contain a similair structure, with all the instruments as seperate models. The amount of models is not limited, nor is the amount of animations.
A detailed article about animating and models can be found in Howto: 3D Aircraft Models.
A common subdirectory is the Liveries/ one, which holds the livery files. See Livery over MP for more information about that subject.
Nasal/ directory
All Nasal code specific to the aircraft is placed in this directory, with the exception of some system or instrument specific Nasal. If a certain Nasal script is usefull for all aircraft (eg. weather or multiplayer related) it can be placed in the $FG ROOT/Nasal directory. Nasal scripts that are useable on multiple aircraft (eg. air-air refueling) can be found in the $FG ROOT/Aircraft/Generic directory.
Sounds/ directory
What is an airliner without the sound of its mighty engines, or a glider without the sound of wind blowing around your face? Sounds are quite important to increase the feeling that you are actually into the simulation. In this directory all sound files that are specific for the aircarft are stored. Sounds that can be used on multiple aircraft (eg. the click of a switch or thunder) are available in the $FG ROOT/Sounds directory.
Tutorials/ directory
A helpfull feature in learning how to start the engines of a plane, flying a basic leg etc. is FlightGears tutorial system. It allows you to create a step by step tutorial that guides the user through a certain procedure. It can even indicate what switches should be pressed!
More about the tutorial system can be found at Tutorials.
Comments in XML files
We can place extra information in XML files, that will be ignored by FlightGear. Such as descriptions and explanations of certain XML markups, changelogs etc.
These will be mainly useful to other developers working with your XML code, for example when updating/maintaining your files, or when borrowing XML code from your work.
<!-- Last update: 09-10-2007 -->
Beware that certain characters are not allowed within an XML file, even within comments, and will always cause problems. This include the characters:
-- < &
Cockpit
| Note The following paragraphs are based on a forum response written by hvengel in 04/2014 |
Traditional Steam gauge cockpits are definitely more modeling than "programming". But in general most people build their cockpits out based what functionality they want to implement next. So you may need a switch to turn something on and off.
In that case the modeling part is almost non-existent since you will likely look at other aircraft and "steal" a switch model that looks like the switches your aircraft uses. By the way we encourage that kind of "stealing" here.
So the "modeling" is done in a matter of minutes although you still need to do things like texturing the panel to create labels for the switch and positioning the switch. But then you need to setup properties in the property tree, set up animation for the switch and then hook the device controlled by the switch up to the property tree, make the device function and so on. So the "programming" part will dominate for this type of thing. Also for some things the animation code can become fairly complex and there's one device in the P-51D cockpit that has over 500 lines of Nasal and XML just for animation. But most things only need a few lines of XML.
For an aircraft specific control like a retract lever or fuel tank selector it is highly unlikely that you will be able to "steal" one from an existing aircraft and you will need to spend the time to model one.
But the "programming" effort will be about the same as the switch in the previous example. So the modeling effort will dominate. You will also need to create some custom steam gauges and it is typical to need at least an aircraft specific air speed gauge and an engine cluster that are specific to the aircraft. For these find some other gauge that is close and create a new texture for the face and tweak on the animation code and you are done. Still the texture work for these gauges can take some time and effort. For a lot of your gauges you should be able to find one either in Aircraft/Instruments3d or in an existing aircraft that you can use with minimal modification.
What really takes time here is that there is so many little details that make up the cockpit. Dozens of switches, a bunch of steam gauges, radios, various controls... and each one takes time to model, position, animate and hook into the systems they control. And on top of that to really do this right you need to model things like the inside structure of the cabin, the seats, rudder pedals, yoke/stick, the panel, the panel shroud and so on. In other words there is just lots of stuff that needs to be done to make a really nice cockpit and because the pilot is sitting right in the middle of all of it and is fairly close to everything it needs to be well done to not look like crap.