Open-source: Released under the GNU General Public License, FlightGear's source code is
publicly available, allowing anyone to inspect, modify, and expand upon it. This has led to a robust
and dynamic development environment.
MultiPlatform:through a modular, open-source architecture that has been developed and refined
by a global community of developers for decades. This approach allows the software to be built and
run on various operating systems, including Windows, macOS, and Linux, and to function on a wide
range of hardware
Users can fly more than 400 aircraft, ranging from small propeller planes to large commercial
airliners, military jets, and helicopters. A wide variety of community-created aircraft are also available
FlightGear simulates a dynamic atmosphere, including real-time weather patterns, 3D cloud
rendering, seasonal changes, and realistic lighting based on the position of the sun, moon, and
stars.
• Core Infrastructure: The foundation of the simulation.
Property Tree: The central, data-driven communication layer. All subsystems communicate by
reading and writing variables to this tree.
Subsystem Manager: An orchestrator that manages all functional modules, ensuring they are
updated in the correct order during each frame.
Main Loop: The heart of the simulation, which drives the frame-by-frame execution and is
responsible for overall control flow.
External Interfaces: How the simulator interacts with the world outside its core process.
Input Devices: Capture user input from hardware like joysticks, keyboards, and mouse and
translate them into data for the Property Tree.
Network: Enables multiplayer functionality and allows external applications to read and write to the
Property Tree.
Simulation Subsystems: Specialized modules that handle different aspects of the simulation.
Flight Dynamics Model (FDM): Calculates the physics of the aircraft based on control inputs from
the Property Tree.
Rendering Engine (OpenSceneGraph): Reads the current state from the Property Tree to render
the visual scene.
AI Systems: Controls autonomous entities like air traffic and ground vehicles.
GUI: Handles user interaction through menus and windows, which in turn modifies the Property
Tree.
Sound Manager: Plays audio based on simulation events stored in the Property Tree.
TerraSync: A background service for downloading and managing scenery data, updating the
Propery Tree with its status.
Time Manager: Controls the flow of simulation time, including pausing and warping.
Add-on Manager: Manages the loading and unloading of dynamic simulation extensions.
Nasal Engine: A lightweight scripting engine that reads and writes properties to add or extend
aircraft-specific behavior and custom logic without modifying the core C++ code.
----------------------------------------------------------------------------------------------------------------------------------
You can play FlightGear on a network by connecting to the official multiplayer servers or by setting
up a private connection with friends
FlightGear uses several network protocols, primarily the User Datagram Protocol (UDP), for its
multiplayer and interface systems. UDP is chosen for its low overhead and speed, which is crucial
for a real-time simulation where a constant stream of positional and state data needs to be sent with
minimal delay
Rendering Pipeline:
OSG's utilities translate the scene graph into a stream of OpenGL commands.
OpenGL processes this stream of commands through its rendering pipeline, which includes steps
such as:
Vertex Processing: Transforms 3D coordinates from the scene graph into 2D coordinates for the
screen.
Primitive Assembly: Groups vertices into geometric shapes like triangles and lines.
Rasterization: Converts these shapes into a grid of pixels (fragments).
Fragment Processing: Applies textures, lighting, and other effects to each pixel.
Output Merging: Combines the final pixels to create the image displayed on the screen.
Shaders:
In modern FlightGear, complex effects like atmospheric light scattering are handled by shaders,
which are small programs written in the OpenGL Shading Language (GLSL). OSG manages and
passes the data needed for these shaders to OpenGL.
This is the most common use of AI in FlightGear and is managed by a subsystem called the Traffic
Manager.
AI Traffic Schedules: The system uses XML files located in the FG_ROOT/AI/Traffic directory.
These files define the routes, departure and arrival times (in UTC), and other flight parameters for
AI-controlled aircraft, mirroring real-world airline schedules.
AI Models: AI aircraft use simplified models that are separate from the complex, full flight dynamics
models (FDM) used for player-controlled aircraft. This is done to improve performance when
managing hundreds of AI planes at once.
Ground Networks (Groundnets): These XML files define the taxiways, runways, and gates at an
airport. The AI engine uses this network to guide aircraft from their parking spots to the runway and
vice versa for takeoffs and landings.
Runway Use Configurations (RWYUSE): These configuration files specify which runways AI
aircraft should use for takeoffs and landings, often based on wind conditions and time of day, adding
to the realism of airport traffic
The core of time management in a simulation is the distinction between two time variables:
Real-world (or wall-clock) time: This is the actual, physical time that passes. It's used for timing
events and ensuring the simulation stays responsive and smooth for the user.
Simulated time: This is the time experienced within the simulation itself, which can be different
from real-world time due to time acceleration or deceleration. All physical processes within the
simulation (like flight dynamics, weather, and the day/night cycle) are driven by this simulated tim
The Property Tree is the central nervous system of FlightGear, serving as a dynamic, hierarchical
database for all the simulator's real-time state variables. It allows different subsystems, such as the
flight dynamics model (FDM), aircraft systems, and animation engine, to communicate with each
other in a standardized way
1. Initialization phase
The simulation begins by preparing all the necessary components.
Start Application: The program is launched, and the operating system loads the executable.
Initialize Core Systems: The core simgear libraries are loaded, including the logging system and
the Property Tree. The Property Tree is a hierarchical data structure that becomes the central hub
for all simulation data.
Load Command-line Options: The program parses command-line arguments, which can override
default settings.
Load User Settings: Configuration files (e.g., [Link]) are read to apply user-specific
settings. This is done after command-line options so that command-line arguments can still take
precedence.
Initialize Subsystems: The SubsystemManager creates and initializes all required subsystems,
such as FlightDynamics, SoundManager, and TerraSync.
Initialize Graphics: The rendering engine, built on OpenSceneGraph (OSG), is set up. This
includes configuring cameras, render targets, and the graphics context.
2. Main simulation loop
This is the continuous, frame-by-frame process that drives the simulation.
Process Input Events: The system reads input from devices like joysticks and keyboards,
translating these events into property updates in the Property Tree.
Update Time: The TimeManager calculates the simulated and real-world time deltas since the last
frame. The simulation time can be warped to speed up or slow down the simulation.
Update All Subsystems: The SubsystemManager iterates through all active subsystems, calling
their update() method with the calculated time delta. This advances the state of the simulation:
FDM: The Flight Dynamics Model reads control inputs from the Property Tree, calculates new
forces, and updates the aircraft's position and orientation.
AI: AI traffic and other non-player entities are moved and their states are updated.
Instruments and Effects: Instruments and visual effects read their required data from the Property
Tree and update their state.
Handle Nasal GC: If enabled, the Nasal scripting engine performs garbage collection in a separate
thread to avoid stalling the main loop.
Render Scene: The rendering engine uses the latest state from the Property Tree to render the
scene. This involves multiple passes, such as for shadows, effects, and the main geometry.
Wait for Frame Completion: The main loop waits for the graphics processing unit (GPU) to finish
rendering the current frame, synchronizing the CPU with the GPU.
End Application: The program exits.
______________________________________________________________________________
1. Pre-rendering: Scene graph and data updates
Before a single pixel is drawn, the rendering process relies on several preparatory steps.
Property Tree State: The FDM and other subsystems continuously update the central
Property Tree with the aircraft's position, orientation, control settings, and various environmental
parameters.
Scene Graph Traversal: The OSG-based renderer performs a traversal of the scene graph, a
hierarchical data structure containing all visible objects. It identifies visible geometry, updates
properties (like animations), and prepares rendering commands.
Terrain Management (VPB): The Virtual Planet Builder (VPB) manages scenery loading and
unloading using a multi-threaded paging system. It loads terrain tiles with different levels of detail
(LoD) based on the camera's position and distance, ensuring that only necessary data is in memory.
2. Multi-camera setup for depth precision
To handle the vast visual range of a flight simulator (from cockpit instruments to distant horizons),
FlightGear uses multiple cameras to prevent Z-buffer precision issues.
Near Camera: Renders objects very close to the viewer, such as the cockpit interior. It uses a high-
precision Z-buffer for a short depth range to avoid flickering.
Far Camera: Renders distant terrain and environmental elements. Its Z-buffer is optimized for
objects far from the camera.
Composition: The outputs of these cameras are combined to form a single, seamless image.
3. The compositor and advanced pipelines
The Compositor is a framework that allows for completely data-driven rendering pipelines, defined
in XML files. Since FlightGear 2020.4, it is the default renderer.
Deferred Rendering (HDR/PBR): High-end pipelines like HDR use a deferred rendering technique
for efficiency.
Geometry Pass (G-Buffer): In an initial pass, all opaque geometry is rendered, and information like
position, normals, and material properties (roughness, metallic, albedo) is written to a series of off-
screen buffers called G-buffers.
Lighting Pass: In a second pass, lighting calculations are performed only on the visible pixels,
using the data from the G-buffers. This is more efficient than calculating lighting for every triangle.
Legacy Pipeline: Older or lower-spec graphics settings use a simpler, multi-pass, forward-
rendering approach.
4. Specialized rendering and effects
FlightGear uses various specialized techniques to enhance realism.
Environmental Effects (ALS): The Advanced Light Scattering (ALS) framework simulates realistic
atmospheric phenomena, including light scattering based on particle density, cloud formation, fog,
and hazes.
Shaders: The Effects Framework provides a structured way to implement GLSL shaders for
materials and visual effects. It allows for features like normal mapping for surface details, reflections,
and light mapping.
Lights: The Compositor has a dedicated system for defining and rendering lights that is
agnostic to the specific rendering pipeline being used.
Orbital Rendering (Earthview): For high altitudes (above ~100km), the Earthview system
replaces the standard terrain pager. It projects a textured sphere representing Earth, which is more
performant and visually accurate for orbital views.
5. Final composition and display
The final stage of the pipeline combines all rendered elements and prepares the image for display.
Transparent Objects: Transparent objects (e.g., cockpit glass) are typically rendered separately and
composited at a later stage, as they don't work with deferred rendering.
GUI and HUD: The user interface and Head-Up Display are rendered on top of all other scene
elements.
Post-processing: Final screen-space effects like tone mapping, bloom, and anti-aliasing are applied
before the image is presented to the user.
Vertex Processing (GPU):
The vertex data is processed by Vertex Shaders, small programs written in GLSL that run on the
GPU.
The vertex shader transforms the 3D coordinates of the vertices into 2D coordinates for the screen.
Rasterization (GPU): This is where the actual conversion from geometry to pixels happens.
The GPU takes the transformed vertices and "assembles" them into primitives (triangles).
The rasterizer determines which pixels on the screen are covered by each primitive.
As it does this, the rasterizer interpolates data from the primitive's vertices, such as color, normals,
and texture coordinates, and passes this information to the next stage.
This process is highly parallelized, making it extremely fast, which is critical for real-time applications
like FlightGear.
Fragment Processing (GPU):
The interpolated data for each fragment is processed by Fragment Shaders.
These shaders determine the final color of each pixel by applying textures, lighting, shadows, and
other effects, such as the advanced atmospheric effects in FlightGear's ALS framework.
Output Merging (GPU):
______________________________________________________________________________
Startup Configuration: The process begins when FlightGear starts up and reads the configured
scenery paths from the FG_SCENERY environment variable and other configuration files.
TerraSync Check: The simulator checks if the automated TerraSync feature is enabled.
If Yes: The TerraSync subsystem is prepared to download missing scenery tiles.
If No: The simulator will rely solely on the locally available scenery.
Main Simulation Loop: Once the core systems are configured, the simulation loop begins. The
process within this loop is repeated continuously for each frame.
Aircraft Position: The renderer obtains the aircraft's current position from the Property Tree.
VPB: New Tile Check: The Virtual Planet Builder (VPB) determines if any new scenery tiles are
needed based on the aircraft's position and direction of travel.
VPB: Search Paths: If new tiles are needed, the VPB searches the configured FG_SCENERY
paths in order of priority.
Tile Data Check: The VPB checks if the required tile data exists in any of the local scenery
directories.
Data Found:
If Yes: The VPB loads the terrain geometry (.[Link]), object placement (.stg), and textures. It
then prepares the geometry and textures for rendering by the graphics engine.
If No: The process checks if TerraSync is enabled.
TerraSync Action:
If TerraSync is enabled: It requests the missing tile data from the central TerraSync server.
It then downloads the tile and places it in the TerraSync folder. Once downloaded, the tile is
available for loading by the VPB in a subsequent loop.
If TerraSync is disabled: The system cannot find the scenery. In this case, it loads default
"water world" geometry and logs an error.
Render Cycle: The scenery, once prepared by the VPB, is incorporated into the render cycle, where
it is drawn to the screen along with other objects, effects, and the GUI.
Continuous Process: The loop continues, with the VPB constantly checking the aircraft's position
and swapping in new scenery tiles as needed to create a seamless virtual world.
----------------------------------------------------------------------------------------------------------------------------------
--
xtensibility: Nasal serves as the primary tool for extending FlightGear. Scripts can be used to add
new features, customize existing systems, and create complex interactions that are not hard-coded
into the core simulator.
Decoupled Logic: The main function of Nasal is to serve as the "glue" that connects different parts
of the simulator. By reading from and writing to the central Property Tree, Nasal scripts can interact
with various subsystems (like the FDM and rendering engine) without being tightly coupled to their
C++ implementations.
Timers and listeners: Once the simulation is running, many Nasal scripts are executed based on
events.
Listeners: A listener waits for a specific property in the Property Tree to change and then executes
a function in response.
Timers: A timer is set to execute a function after a specified time interval
Binding: In the aircraft's cockpit configuration (often in a separate XML file), a binding is created to
link the toggle_panel_lights function to a mouse click event on the panel lights switch.
Property Tree interaction: When the pilot clicks the switch, the binding executes the
toggle_panel_lights function. This function reads the /controls/lighting/panel-lights property, inverts
its value, and writes it back. The cockpit's 3D lighting model is listening for changes to this property
and updates the scene accordingly.
SimGear: A collection of C++ libraries that form the foundation of FlightGear. It provides essential
components like the Property Tree, Subsystem Manager, I/O abstractions, and cross-platform
compatibility.
OpenSceneGraph (OSG): A high-performance, cross-platform 3D graphics toolkit. FlightGear
transitioned to OSG in 2008 for rendering the visual world, replacing the older PLIB library.
OpenGL: The low-level standard graphics API used for rendering 2D and 3D graphics. OSG
translates its scene graph data into OpenGL commands, which are then processed by the graphics
card.
OpenAL: An open-source audio library that provides 3D positional sound effects. It allows
developers to control the placement, volume, and pitch of sounds dynamically based on their
position in the simulation.
Qt: A cross-platform application framework used for the main graphical launcher and modern
graphical user interface (GUI) elements within the simulator.
C++: The primary programming language for FlightGear's core, including SimGear, the Subsystem
Manager, and the main simulation loop.
C: Used for some supporting code, primarily within the SimGear libraries, such as the Nasal scripting
interpreter.
GLSL (OpenGL Shading Language): A C-like language used to write "shaders." These run on the
GPU to handle advanced graphical effects like atmospheric light scattering, HDR rendering, and
detailed weather effects.
Nasal: A lightweight, built-in scripting language that is used for a wide range of tasks, including
creating interactive cockpit instruments, managing aircraft systems, and implementing complex
mission logic.
Python: The FGo! launcher, an optional alternative to the default Qt launcher, is written in Python.
Python is also used for various external tools and scripts.
XML (Extensible Markup Language): Used extensively for configuration files, including:
PropertyList XML: Defines aircraft systems, animations, and instrument layouts.
JSBSim-ML: Configures the JSBSim flight dynamics model.
Effect Framework: Specifies how GLSL shaders and visual effects are applied.
Nasal Bindings: Exposes C++ methods to the Nasal scripting engine.
Flight dynamics models (FDM)
JSBSim: The default, highly accurate, and physics-based FDM. Written in C++ and
configured with XML, it was used in a NASA benchmark.
External tools and subsystems
TerraGear: A sister project that is a suite of tools for generating the worldwide scenery used
by FlightGear from real-world elevation and land-cover data.
FGMS (FlightGear Multiplayer Server): A dedicated server that relays position data between
connected FlightGear clients to enable multiplayer functionality.
Addon Manager: A framework that provides a standardized way for developers to create extensions
for FlightGear, often using Nasal and the Canvas system.
CMake: The build system used to compile FlightGear from source code.
Git: The version control system used by the FlightGear project to manage its source code.