https://wiki.flightgear.org/w/api.php?action=feedcontributions&user=Cgdae&feedformat=atomFlightGear wiki - User contributions [en]2024-03-29T04:36:27ZUser contributionsMediaWiki 1.39.6https://wiki.flightgear.org/w/index.php?title=ExtraViewWindows&diff=138602ExtraViewWindows2023-11-01T23:11:02Z<p>Cgdae: /* Specifying views in more detail */</p>
<hr />
<div>[[File:Fg-cv-textures2.jpeg|thumb|Multiple top level windows in CompositeViewer]]<br />
<br />
== Overview ==<br />
<br />
On next, there's support for Extra View windows. These are top-level windows that show views independently from the main window's view. These use a new view system called '''Sview''' (short for "Step View") along with [[CompositeViewer Support]].<br />
<br />
The simplest way to create an extra view window is from menu '''View/Add Clone View''' which, as the name implies, will create a new window that is a clone of the current view. Changing the main window's view will leave the new window's view unchanged.<br />
<br />
== Viewing pairs of aircraft ==<br />
<br />
There is a slightly crude mechanism for creating views that work on pairs of aircraft: one uses menu '''View/Push Pair View''' to push the current main-window view onto a stack of views.<br />
<br />
Once this has been done at two or more times, menu '''View/Add Pair View''' will open a new top-level window showing a view derived from the last two remembered viewpoints. So for example it can show the view of your aircraft from a particular multiplayer aircraft, or a view of the nearest tower from your aircraft.<br />
<br />
Menu '''View/Add Pair Foreground View''' is similar but it keeps the first viewpoint at a fixed distance in the foreground and the second viewpoint in the background. This works well when flying in formation.<br />
<br />
== Limitations ==<br />
<br />
As of '''2021-10-25''':<br />
<br />
* Extra View windows can be panned like the main window by dragging with the left mouse button.<br />
* Other UI interations is not supported:<br />
** Mouse clicks are ignord.<br />
** Key presses are ignored.<br />
<br />
== Specifying views in more detail ==<br />
<br />
One can open new view windows explicitly with the <code>view-new</code> command, which accepts an Sview specification in the form of an accompanying XML tree.<br />
<br />
For details of the XML format, see the comments in: {{flightgear file|src/Viewer/sview.hxx}}<br />
<br />
From Nasal, one can load the view specification from a specific file:<br />
<br />
<syntaxhighlight lang="nasal"><br />
var spec = io.read_properties("sview.xml");<br />
fgcommand("view-new", spec);<br />
</syntaxhighlight><br />
<br />
Alternatively a view can be specified in the main property tree, for example:<br />
<br />
<syntaxhighlight lang="xml"><br />
<sim><br />
...<br />
<sview-tower><br />
<window-width>300</window-width><br />
<window-height>200</window-height><br />
<window-x>200</window-x><br />
<window-y>200</window-y><br />
<step> <!-- Move to aircraft. --><br />
<type>aircraft</type><br />
<callsign></callsign><br />
</step><br />
<br />
<step> <!-- Move to centre of aircraft. --><br />
<type>move</type><br />
<right>0</right><br />
<up>0.5</up><br />
<forward>-3.85</forward><br />
</step><br />
<br />
<step> <!-- Copy current position to target. --><br />
<type>copy-to-target</type><br />
</step><br />
<br />
<step> <!-- Move to nearest tower. --><br />
<type>nearest-tower</type><br />
</step><br />
<br />
<step> <!-- Look at target position we found earlier. --><br />
<type>rotate-to-target</type><br />
</step><br />
</sview-tower><br />
...<br />
</sim><br />
</syntaxhighlight><br />
<br />
And can be opened from Nasal:<br />
<br />
<syntaxhighlight lang="nasal"><br />
fgcommand("view-new", props.globals.getNode("sim/sview-tower"));<br />
</syntaxhighlight><br />
<br />
Or from a menu item:<br />
<br />
<syntaxhighlight lang="xml"><br />
<menu><br />
...<br />
<item><br />
<name>Open extra tower view</name><br />
<binding><br />
<command>nasal</command><br />
<script><br />
printf("running view-new");<br />
fgcommand("view-new", props.globals.getNode("sim/sview-tower"));<br />
</script><br />
</binding><br />
</item><br />
...<br />
</menu><br />
</syntaxhighlight><br />
<br />
== How Sview works ==<br />
<br />
Sview works by constructing camera's eye and target positions/directions using an arbitrary number of individual configurable steps. There are various step types defined which allow for various transformations such as moving to a particular user/multiplayer aircraft or nearest tower, move relative to the current position+direction, modify heading, pitch and roll according to particular property values, rotate view direction to point at a particular target etc.<br />
<br />
These basic steps are enough to allow Sview to copy what conventional views do, allowing the '''View/Add clone view''' menu item to work.<br />
<br />
It's also easy enough to add (C++) code to implement new steps to achieve more sophisticated behaviour. An example of this is the view step called '''double''' that keeps two aircraft visible at all times, with one in the foreground; this is used for '''View/Add Pair Foreground View'''.<br />
<br />
For more details, see the C++ Sview code itself: {{flightgear file|src/Viewer/sview.cxx}}<br />
<br />
== Example ==<br />
This example will work with F-16. It will place a small window in lower-right corner of a 1920x1080 FG window.<br />
<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<br />
<PropertyList><br />
<window-width>400</window-width><br />
<window-height>400</window-height><br />
<window-x>1520</window-x><br />
<window-y>0</window-y><br />
<type>sview</type><br />
<name>step-dancer</name><br />
<br />
<step n="0"> <!-- Move to own aircraft. --><br />
<type>aircraft</type><br />
<callsign></callsign><br />
</step><br />
<br />
<!-- Move to place inside of aircraft. --><br />
<step n="1"><br />
<type>move</type><br />
<right>0</right><br />
<up>-0.83</up><br />
<forward>4.40</forward><br />
</step><br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[Configuring View Windows]]<br />
* [[SView]]</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=ExtraViewWindows&diff=138601ExtraViewWindows2023-11-01T23:06:26Z<p>Cgdae: /* Specifying views in more detail */ Added example XML and Nasal.</p>
<hr />
<div>[[File:Fg-cv-textures2.jpeg|thumb|Multiple top level windows in CompositeViewer]]<br />
<br />
== Overview ==<br />
<br />
On next, there's support for Extra View windows. These are top-level windows that show views independently from the main window's view. These use a new view system called '''Sview''' (short for "Step View") along with [[CompositeViewer Support]].<br />
<br />
The simplest way to create an extra view window is from menu '''View/Add Clone View''' which, as the name implies, will create a new window that is a clone of the current view. Changing the main window's view will leave the new window's view unchanged.<br />
<br />
== Viewing pairs of aircraft ==<br />
<br />
There is a slightly crude mechanism for creating views that work on pairs of aircraft: one uses menu '''View/Push Pair View''' to push the current main-window view onto a stack of views.<br />
<br />
Once this has been done at two or more times, menu '''View/Add Pair View''' will open a new top-level window showing a view derived from the last two remembered viewpoints. So for example it can show the view of your aircraft from a particular multiplayer aircraft, or a view of the nearest tower from your aircraft.<br />
<br />
Menu '''View/Add Pair Foreground View''' is similar but it keeps the first viewpoint at a fixed distance in the foreground and the second viewpoint in the background. This works well when flying in formation.<br />
<br />
== Limitations ==<br />
<br />
As of '''2021-10-25''':<br />
<br />
* Extra View windows can be panned like the main window by dragging with the left mouse button.<br />
* Other UI interations is not supported:<br />
** Mouse clicks are ignord.<br />
** Key presses are ignored.<br />
<br />
== Specifying views in more detail ==<br />
<br />
One can open new view windows explicitly with the <code>view-new</code> command, which accepts an Sview specification in the form of an accompanying XML tree.<br />
<br />
For details of the XML format, see the comments in: {{flightgear file|src/Viewer/sview.hxx}}<br />
<br />
From Nasal, one can load the view specification from a specific file:<br />
<br />
<syntaxhighlight lang="nasal"><br />
var spec = io.read_properties("sview.xml");<br />
fgcommand("view-new", spec);<br />
</syntaxhighlight><br />
<br />
Alternatively a view can be specified in the main property tree, for example:<br />
<br />
<syntaxhighlight lang="xml"><br />
<sim><br />
...<br />
<sview-tower><br />
<window-width>300</window-width><br />
<window-height>200</window-height><br />
<window-x>200</window-x><br />
<window-y>200</window-y><br />
<step> <!-- Move to aircraft. --><br />
<type>aircraft</type><br />
<callsign></callsign><br />
</step><br />
<br />
<step> <!-- Move to centre of aircraft. --><br />
<type>move</type><br />
<right>0</right><br />
<up>0.5</up><br />
<forward>-3.85</forward><br />
</step><br />
<br />
<step> <!-- Copy current position to target. --><br />
<type>copy-to-target</type><br />
</step><br />
<br />
<step> <!-- Move to nearest tower. --><br />
<type>nearest-tower</type><br />
</step><br />
<br />
<step> <!-- Look at target position we found earlier. --><br />
<type>rotate-to-target</type><br />
</step><br />
</sview-test-tower><br />
...<br />
</sim><br />
</syntaxhighlight><br />
<br />
And can be opened from Nasal:<br />
<br />
<syntaxhighlight lang="nasal"><br />
fgcommand("view-new", props.globals.getNode("sim/sview-tower"));<br />
</syntaxhighlight><br />
<br />
Or from a menu item:<br />
<br />
<syntaxhighlight lang="xml"><br />
<menu><br />
...<br />
<item><br />
<name>Open extra tower view</name><br />
<binding><br />
<command>nasal</command><br />
<script><br />
printf("running view-new");<br />
fgcommand("view-new", props.globals.getNode("sim/sview-tower"));<br />
</script><br />
</binding><br />
</item><br />
...<br />
</menu><br />
</syntaxhighlight><br />
<br />
== How Sview works ==<br />
<br />
Sview works by constructing camera's eye and target positions/directions using an arbitrary number of individual configurable steps. There are various step types defined which allow for various transformations such as moving to a particular user/multiplayer aircraft or nearest tower, move relative to the current position+direction, modify heading, pitch and roll according to particular property values, rotate view direction to point at a particular target etc.<br />
<br />
These basic steps are enough to allow Sview to copy what conventional views do, allowing the '''View/Add clone view''' menu item to work.<br />
<br />
It's also easy enough to add (C++) code to implement new steps to achieve more sophisticated behaviour. An example of this is the view step called '''double''' that keeps two aircraft visible at all times, with one in the foreground; this is used for '''View/Add Pair Foreground View'''.<br />
<br />
For more details, see the C++ Sview code itself: {{flightgear file|src/Viewer/sview.cxx}}<br />
<br />
== Example ==<br />
This example will work with F-16. It will place a small window in lower-right corner of a 1920x1080 FG window.<br />
<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<br />
<PropertyList><br />
<window-width>400</window-width><br />
<window-height>400</window-height><br />
<window-x>1520</window-x><br />
<window-y>0</window-y><br />
<type>sview</type><br />
<name>step-dancer</name><br />
<br />
<step n="0"> <!-- Move to own aircraft. --><br />
<type>aircraft</type><br />
<callsign></callsign><br />
</step><br />
<br />
<!-- Move to place inside of aircraft. --><br />
<step n="1"><br />
<type>move</type><br />
<right>0</right><br />
<up>-0.83</up><br />
<forward>4.40</forward><br />
</step><br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[Configuring View Windows]]<br />
* [[SView]]</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=Advanced_weather&diff=138557Advanced weather2023-10-26T17:55:18Z<p>Cgdae: /* Connection with the multiplayer system */ Fixed typo</p>
<hr />
<div>The '''Advanced Weather''' (AW) system, formerly called '''Local Weather''' (LW) and sometimes '''Detailed Weather''', is included in FlightGear since version 2.4 (see [http://www.flightgear.org/news/flightgear-v2-4-0-released/ release notes]). It was then renamed and improved for FlightGear 2.6 (see [http://www.flightgear.org/news/flightgear-v2-6-0-released/ release notes] and [http://www.flightgear.org/tours/advanced-weather-v1-4-in-flightgear-2-6/ detailed explanation and many screenshots] for version 1.4 of the Advanced Weather in FlightGear 2.6).<br />
<br />
== Unification of basic and advanced weather system == <br />
It is planned to unify the weather systems in FlightGear. Possibly for the upcoming version 3.0. It is therefore needed to improve the usability of the advanced weather configuration system. Join the [http://forum.flightgear.org/viewtopic.php?f=69&t=16630 discussion on this topic in the forums].<br />
<br />
== History ==<br />
Status: August 2010<br />
<br />
The current weather system of FlightGear can be called global when FlightGear runs offline: Any menu weather setting, be it windspeed, visibility, precipitation or cloud coverage, affects the weather everywhere. It is not possible to fly to a region where the cloud cover is different, or see precipitation from an aircraft flying in sunshine, or to observe a change in atmospheric pressure by flying somewhere else.<br />
<br />
When online, the weather system offers a link with METAR servers, which makes the weather locally-determined global: One can change the weather by flying to a different location where a different METAR is available, but the change happens instantaneously everywhere, i.e. there is no transition of for example crossing a rain front or leaving dense clouds behind to emerge in sunshine.<br />
<br />
A local weather system in contrast is one in which continuous changes from the weather at one location to the weather in a different location are simulated, i.e. weather phenomena are tied to a specific location. Needless to say, a local weather system is significantly more complicated to simulate than the present system. Below is a conceptual outline how a local weather system for FlightGear could be created using mainly existing technology and code.<br />
<br />
'''Advanced Weather''' has had the capability to do a 3-dim interpolation of a windfield for years - you just need to hand it the correct aloft information, and it rotates the wind with altitude and position. It's actually 4d, because it has also the ability to gradually fade interpolation vectors in and out. Since default METAR doesn't say anything about aloft layer, it tries to deduce how much the local boundary layer winds are reduced from the terrain topology, guesses the lowest aloft wind layer from there, then guesses higher aloft layers based on Coriolis deflection of winds and the generic strengthening of high-altitude winds. <ref> {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/34960164/<br />
| title = <nowiki>Re: [Flightgear-devel] Aircraft-specific weather (Extra 500)</nowiki><br />
| author = <nowiki>Thorsten Renk</nowiki><br />
| date = Mar 23rd, 2016<br />
| added = Mar 23rd, 2016<br />
| script_version = 0.25<br />
}}<br />
</ref><br />
<br />
== Scales for weather phenomena ==<br />
Real weather phenomena are determined by processes occurring at vastly different size scales. At the large end of the scale is the system of low and high pressure regions and fronts between cold and warm air masses, which have spatial size scales of O(1000) km. At the other end of the scale are very localized phenomena, for instance a dark tarmac surface heated by sunlight acting as the source point of a thermal updraft resulting in a Cumulus cloud. Both size scales are relevant for the FlightGear experience - an airliner on a long haul flight is able to observe large-scale weather fronts from above, whereas a glider pilot needs a reasonable simulation of local updrafts and sinks tied to terrain features in a credible way for a realistic flight experience. A local weather system therefore needs to<br />
<br />
* Simulate weather phenomena at different scales<br />
* Ideally work offline as well as online<br />
* Allow modification by the user on various scales<br />
* Be reasonably fast to run in real-time <br />
<br />
The actual dynamics of the atmosphere is a very complex problem which even solved approximately needs hours of CPU time on supercomputing clusters. From this, it is clear that a local weather system cannot be an (even approximately) physically accurate description of processes in the atmosphere, but needs to be a credible mockup of such a description in which heuristic rules replace simulation. <br />
<br />
To give an example for what this means, consider the development of Cumulus clouds. Cumulus development is reduced on a hot day under a hazy Cirrus sky. The reason is that the Cirrus sky reflects part of the sunlight, thus the ground is not heated that much by direct sunlight and the convective processes responsible for Cumulus cloud formation are lessened. An accurate simulation would need to start with the energy absorbed from the sunlight on various types of surfaces, then solve the equations governing the heat flux from the ground to the air above, followed by fluid-dynamical equations for the convective currents creating Cumulus clouds. A heuristic rule would simply state that the probability for the placement of a Cumulus cloud into the FlightGear environment is reduced by 50% when a Cirrus cover is present (obviously, the sophistication of the rule set determines how realistic the weather system will appear).<br />
<br />
In the following, the technology for such a local weather system needed at the relevant scales is outlined - first for the situation offline, followed by ideas how it could be connected with the METAR system in online use.<br />
<br />
=== Small scale - effect volumes and average conditions ===<br />
To simulate local weather at small scale, effect volumes (EV) are a useful concept. The effect volumes define regions in which the normal weather conditions (wind, turbulence, updraft, visibility, precipitation...) are replaced by ones characteristic for the region. As an example, one would define the inside of a cloud as an effect volume in which visibility is reduced as compared to outside, or the precipitation layer underneath a thunderstorm as an EV in which heavy rain is on, visibility is reduced, the temperature is reduced and some turbulence may be active. <br />
<br />
The conditions characteristic for the EV are imposed once the aircraft enters the volume, they are restored to the outside values once the aircraft leaves the region again. The FlightGear AI system already has examples of structures which in essence are EVs - '''thermal''' and '''thunderstorm'''. The first structure contains an EV in which vertical air motion is active, the second one in which turbulence is present. These structures could be generalized to an AI system '''weather''' in which essentially all weather parameters inside the volume could be set by XML tags. <br />
<br />
On the visual side, parts of the EV must also be tied to visible models. The inside of a cloud can be modelled by reduced visibility, but the outside of the cloud must be a model. Similarly, the inside of a rain front appears as rain generated by the FlightGear system, but the outside must be a 3-d model of a precipitation layer. This means that individual 3-d models for various visible atmospheric phenomena (clouds, precipitation, fog, ...) need to be created (see [[Howto: Modelling clouds|Howto: Modelling Clouds]] for a collection of techniques for creating cloud and precipitation models).<br />
<br />
Outside the EV, many meteorological parameters may vary in a continuous way, for example visibility may decrease from 5000 to 4000 m when flying 20 km north - but inside the cloud (the EV), it will change in a discontinuous way very suddenly to a low value (say 30 m), to jump back to a large value outside the cloud. Thus, the EVs are used to simulate only discontinuous, local changes in conditions, the larger scale changes in the background need to be taken care of by a different system.<br />
<br />
EV's should be implemented such that they can be user-specified, i.e. a user should be able to place any particular combination of weather effects and cloud/precipitation model to a specific location.<br />
<br />
=== Mid scale - weather tiles ===<br />
Weather needs to be explicitly simulated about as far as one can see from an aircraft - that naturally leads to the concept of weather tiles (analoguous to scenery tiles) which would cover a region of, say, 30x30 km or something of that size. Inside tiles, weather is simulated explicitly in terms of EVs and 3-d models. <br />
<br />
As experiments will quickly convince anyone, placing a random set of cloud models into a tile does not create a realistic sky appearance. Instead, some cloud types usually occur together, others do not. The underlying reason is of course that there is large scale dynamics of the weather which determines what happens in a given location. For instance, Cirrus clouds are found at the leading edge of a warm front - and they are usually followed by lower, layered cloud types like Altostratus, but typically not by a thunderstorm front. <br />
<br />
Thus, there need to be different 'types' of tiles, each representing a typical snapshot of a development inside the larger system. Tile themes would be something like 'leading edge of warm front', 'trailing edge of warm front', 'cold front', 'dry high-pressure region', 'developed tropical thunderstorms' and so on. This has the added benefit that the user can specify the weather locally simply by choosing an appropriate tile from a menu (he does not need to micromanage the weather by placing individual EV and cloud models).<br />
<br />
The type of tile then determines the rules for populating the tile with EV and models. A 'leading edge of a warm front' tile could for example have the rules<br />
<br />
* Populate the northern part of the tile randomly with 10 Cirrus clouds between 25.000 and 30.000 ft <br />
* Make sure the models are spaced sufficiently far apart<br />
* Make sure the models show the same type of texture (do not mix feathery Cirrus textures with amorphous ones)<br />
* Populate the southern part of the tile with 20 Cirrocumulus clouds between 20.000 and 25.000 ft<br />
(...)<br />
<br />
The values of weather parameters outside the EVs would be set for the tile center and interpolated between neighbouring tiles. <br />
<br />
Technically, each tile can be populated by a Nasal script specific for the tile type whenever the tile is needed (probably when it becomes visible). As an example for the development state of the system (March 2010), here is the view for a weather tile representing an approaching cold front with a Stratocumulus layer and occasional Cumulonimbus activity.<br />
<br />
<center><br />
[[File:Clouds-coldfront02.jpg|400px]]<br />
</center><br />
<br />
=== Large scale - tile placement rules ===<br />
To create a realistic experience for flights beyond a tile, there need to be matching rules for tiles. Since each tile represents a particular development in a larger weather environment, only certain types of tiles match. For instance, one cannot place a 'high-pressure region' tile next to a 'low pressure region' tile without crossing a front. With a moderately large library of different tile types and a set of placement rules, out of which (in offline mode) a credible set of neighbouring tiles is chosen, a more or less realistic long-distance flight experience can result.<br />
<br />
If each tile type contains default values for weather parameters (to be overwritten by METAR info if available), the actual value of any parameter such as atmospheric pressure of visibility can be obtained by interpolation between tile centers, and the parameters will vary even in the absence of METAR info simply due to the tile placement rules mocking up the presence of real large-scale weather systems.<br />
<br />
Tile placement rules can be implemented in a Nasal loop which monitors the local position and initializes a new tile as soon as it is needed.<br />
<br />
== Connection with the METAR system ==<br />
Connecting the above concepts with real METAR info is not straightforward. The METAR info should conceptually influence three different things:<br />
<br />
* Selection of tile type<br />
* Placement of EVs and models inside the tile<br />
* Continuously varying weather parameters<br />
<br />
=== Selection of tile type ===<br />
If METAR info is to determine tile type selection, one would need to find an algorithm which gets the METAR from nearby stations and tries to extract a more global weather pattern from that info. For instances, pressure differences and wind direction could be used to locate high and low pressure regions, temperature differences (corrected for elevation) could help to find cold and warm air masses, and based on the most likely weather pattern given these bits of information, the initial tile type as well as the most likely matching neighbouring tiles could be chosen.<br />
<br />
=== Placement of EVs and models inside the tile ===<br />
At least some aspects of EV and model placement, such as cloud base, precipitation strength or number of clouds to be placed can more or less be inferred directly from the METAR information. However, in general the tile rules may in details conflict with the METAR info, so the weather system outlined here would not always literally reproduce the METAR (for example, it could happen that the METAR reports rain at an airfield, but that the tile generation does not place a raincloud directly above the airfield).<br />
<br />
=== METAR and continuously varying weather parameters ===<br />
If METAR info is available, this (rather than default tile center info) should be used to set parameters like visibility, pressure or temperature. To avoid discontinuous jumps, the info should be linearly interpolated in time for each nearby position from which a METAR is available. If METAR is updated every 10 minutes, one can use the information at startup for each position for the first 10 minutes of flight, then as soon as the next METAR is available slowly change the value (at each position) within the next 10 minutes to the values just fetched, and continue to do so (in essence creating a 10 minute offset from real to simulated weather).<br />
<br />
To interpolate in space, in principle a simple algorithm with inverse distance weighting can be used (there are more accurate but also more complicated solutions): If, say, the pressure ''p'' is known at ''n'' positions, such that the pressure at position ''i'' is ''p_i'' and the distance between aircraft and ''i'' is ''d_i'', then a good approximation of the local pressure is<br />
<br />
p = (sum p_i (1/d_i)) / (sum 1/d_i)<br />
<br />
as this will make the pressure at position ''i'' equal to ''p_i'' and lead to the average of the individual pressures if the distance to all METAR stations is the same.<br />
<br />
== Creating custom Weather Tiles ==<br />
Hard-customizing a weather scenario for your needs is fairly easy. If you look into Nasal/local-weather/weather_tiles.nas you can for instance find the function set_high_pressure_tile() That has lines var spread = 10.0 + 4.0 * rand(); var D = T - spread; which set spread and dewpoint D, so if you want a certain cloud base, you just set spread to your desired value such that the cloudbase will later be spread * 400 later. The exact cloud base will always depend a bit on the topology, outcrops of the terrain tend to push it up under some conditions.<ref>{{cite web<br />
|url = https://sourceforge.net/p/flightgear/mailman/message/35259165/ <br />
|title = <nowiki> Re: [Flightgear-devel] Autostart advanced weather with METAR from<br />
commandline </nowiki> <br />
|author = <nowiki> Thorsten Renk </nowiki> <br />
|date = Aug 3rd, 2016 <br />
|added = Aug 3rd, 2016 <br />
|script_version = 0.40 <br />
}}</ref><br />
<br />
<br />
If you have a function (data table,...) providing the wind vector w =(wx, wy, wz) as a function of position and time, i.e. w (x,y,z,t), is it possible to make that work in FG, yes that is possible.<br />
<br />
Advanced Weather allows to specify a weather effect volume by function (like the distribution of lift inside thermals is implemented) and such a dedicated windshear function could be simulated close to the ground. The required tool is Nasal, FGs scripting language.<br />
<br />
Nasal files are usually *.nas files, they are program code, not just "configuration files". So you will want to check out $FG_ROOT/Nasal/local_weather and in particular, see the various "tiles" in weather_tiles.nas<br />
<br />
For instance, to add support for wind-shear, you probably want to have a look at the effect volume management routines. Basically you want to write something analogous to thermal_lift_start(), thermal_lift_stop() and thermal_lift_loop() in /Nasal/local_weather/local_weather.nas and use the management routines of effect_volume_loop()<br />
<br />
You'd have the best control over weather just defining your own specific tile (see the various tiles in weather_tiles.nas - a minimal structure might be<br />
<br />
<syntaxhighlight lang="php"><br />
####################################<br />
# my own tile<br />
####################################<br />
<br />
var set_my_own_tile = func {<br />
<br />
setprop(lw~"tiles/code","myown");<br />
<br />
tile_start();<br />
<br />
var x = 0.0;<br />
var y = 0.0;<br />
var lat = 0.0;<br />
var lon = 0.0;<br />
<br />
var alpha = getprop(lw~"tmp/tile-orientation-deg");<br />
var phi = alpha * math.pi/180.0;<br />
var alt_offset = getprop(lw~"tmp/tile-alt-offset-ft");<br />
<br />
# get tile center coordinates<br />
<br />
var blat = getprop(lw~"tiles/tmp/latitude-deg");<br />
var blon = getprop(lw~"tiles/tmp/longitude-deg");<br />
calc_geo(blat);<br />
<br />
# first weather info for tile center (lat, lon, visibility, temperature, dew point, pressure)<br />
<br />
local_weather.set_weather_station(blat, blon, alt_offset, 45000.0, 14.0, 12.0, 29.78);<br />
<br />
var alt_offset = getprop(lw~"tmp/tile-alt-offset-ft");<br />
<br />
# draw some clouds<br />
<br />
create_2_8_altocumulus_streaks(blat, blon, 12000+alt_offset, alpha) ;<br />
create_6_8_stratus(blat, blon, 3000+alt_offset, alpha) ;<br />
<br />
# set visibility and light attenuation as a function of altitude<br />
<br />
local_weather.set_atmosphere_ipoint(blat, blon, 45000.0, 3000.0, 45000.0, 0.0, 15000.0, 17000.0, 0.8, 12000.0, 17000.0); <br />
<br />
append(weather_dynamics.tile_convective_altitude,3000.0);<br />
append(weather_dynamics.tile_convective_strength,0.0);<br />
<br />
tile_finished();<br />
<br />
}<br />
</syntaxhighlight><br />
<br />
which controls all clouds/visibility. Turbulence can be coded into that as an effect volume spanning the whole tile (as for example for the cold front). Wind is read from the menu, so the properties need to be set accordingly.<br />
<br />
METAR strings give you a lower level of control (you can't control the precise clouds being drawn and the vertical structure of the atmosphere that way). <br />
<br />
If you have a Nasal subroutine creating the wind field, Thorsten (get in touch via the forum) volunteers to provide integration help you with implementing it in the correct places.<br />
<br />
There are other possibilities, you might for instance try to alter the generic boundary layer code of Advanced Weather to add automatic windshear detection, or you might alter the C++ code of Basic Weather - it really depends on what information you have and what you'd like to do.<br />
<br />
== Connection with the multiplayer system ==<br />
<!--<br />
(should be written by someone who knows what the multiplayer system can and cannot do)<br />
--><br />
<br />
{{Note|<br />
It would seem useful to get Richard into the boat, because (once again) [[Emesary]] seems kind of ideal for the required communication.<ref>{{cite web<br />
|url = https://sourceforge.net/p/flightgear/mailman/message/35609551/ <br />
|title = <nowiki> Re: [Flightgear-devel] Traffic 2020: Towards a new Development<br />
Model for FlightGear AI Traffic </nowiki> <br />
|author = <nowiki> Thorsten Renk </nowiki> <br />
|date = Jan 17th, 2017 <br />
|added = Jan 17th, 2017 <br />
|script_version = 0.40 <br />
}}</ref><br />
<br />
<br />
}}<br />
<br />
This is a feature that could have been there at least four years ago. AW is nearly made for efficient sync over MP, because once you give it a dedicated random number generator, all you need to send is tile coordinates, a handful of meta-data variables and a random seed, and it'll get identical weather across multiple instances. No need to send thousands of cloud positions (which never shares the thermals anyway) - you can get the whole tile structure identical for hardly any transmission cost. All it really takes is someone who cares about multi-instance sync and has some Nasal experience to get up and code it. It's probably less than 300 lines of code added to the AW tile manager. But we're moving in circles - every six months someone remarks it'd be nice to have, Thorsten writes how it can be accomplished but that since he is neither interested in MP nor have an MP test setup won't do it himmself (you don't seriously expect him to develop something he can't test? himself), Thorsten offers his help with the AW internals to everyone who wants to have a go - and nothing happens, we repeat the exercise half a year later. So the offer still stands - Thorsten believes synchronizing AW over MP is not very difficult, and he'll help with the task, but it has to be done by someone who has a setup to actually test it. <ref>{{cite web<br />
|url = https://sourceforge.net/p/flightgear/mailman/message/35595674/ <br />
|title = <nowiki> Re: [Flightgear-devel] Traffic 2020: Towards a new Development<br />
Model for FlightGear AI Traffic </nowiki> <br />
|author = <nowiki> Thorsten Renk </nowiki> <br />
|date = Jan 10th, 2017 <br />
|added = Jan 10th, 2017 <br />
|script_version = 0.40 <br />
}}</ref><br />
<br />
<br />
We have two weather systems that work aircraft-centered, but zero which work server-centered - what's the smaller task - creating a p2p design to transmit a comparatively small amount of info, or write a server-based weather system from scratch?<ref>{{cite web<br />
|url = https://forum.flightgear.org/viewtopic.php?p=151995#p151995 <br />
|title = <nowiki> Re: Clouds online </nowiki> <br />
|author = <nowiki> Thorsten </nowiki> <br />
|date = Mar 1st, 2012 <br />
|added = Mar 1st, 2012 <br />
|script_version = 0.40 <br />
}}</ref><br />
<br />
To state the problem in a nutshell:<br />
An aircraft-centered system doesn't have to care about matching to large-scale weather patterns beyond cloud visibility range. It doesn't have to care that Earth is a sphere. It doesn't have to care if winds lead to severe inconsistencies 3 hours into tile generation, because you'll be long gone from the area by the time the problems become visible. A server-based weather system has to care about all things. There is no space beyond visible range into which you can simply let problems run.<ref>{{cite web<br />
|url = https://forum.flightgear.org/viewtopic.php?p=152091#p152091 <br />
|title = <nowiki> Re: Clouds online </nowiki> <br />
|author = <nowiki> Thorsten </nowiki> <br />
|date = Mar 2nd, 2012 <br />
|added = Mar 2nd, 2012 <br />
|script_version = 0.40 <br />
}}</ref><br />
<br />
Suppose we manage to spawn exactly the same weather tile for two players. In scheme B), since cloud motion is a tile property, they would continue to evolve the same way. But in scheme A), if one player flies at 5000 ft where the wind is 10 kt and the other at 15.000 ft in 20 kt winds, the clouds will drift apart with 10 kt even if you manage to create them synchronied. So you can't cast this into a mere synchronization problem at tile creation. But if you want to enforce synchronization later, the problem goes beyond a mere exchange of information - it becomes one of control (and consistency) Nature moves clouds in a windfield C), and at least you must detatch that from aircraft position as in scheme A). My original scheme B) would have been suitable for MP synchronization (this is part of the reason I introduced it that way). But since Stuart's cloud rendering system doesn't recognize 'tile-index' as a valid concept, there is no easy way to get it back and to move clouds by tile again.<br />
And thus, wind is going to be a problem if you require high precision and wind drift of clouds.<br />
<br />
<ref>{{cite web<br />
|url = https://forum.flightgear.org/viewtopic.php?p=152428#p152428 <br />
|title = <nowiki> Re: Clouds online </nowiki> <br />
|author = <nowiki> Thorsten </nowiki> <br />
|date = Mar 5th, 2012 <br />
|added = Mar 5th, 2012 <br />
|script_version = 0.40 <br />
}}</ref><br />
<br />
<br />
Basically it's pretty difficult - it's a plane-centered approach - it won't translate into a global weather server and it won't naturally give two planes in approximately the same location precisely the same weather (apart from METAR reported parameters which would agree - but there's an inifinity of ways to have scattered cloud cover). Years ago ideas were discussed and Thorstten worked out a neat way of approximately synchronizing it in a peer-to-peer fashion among MP participants (assuming they all run on METAR, which seems the thing on MP). <br />
<br />
Basically the first plane gets to build the weather tile is in the vicinity, any plane that reaches the area queries the plane already there whether it has weather tiles available or not, if yes it queries for the information to build them, if not it does it itself and announces their availability. This doesn't have to be high bandwidth because the meta-information to build a tile is very small (a random seed and a handful of parameters) and decision times can be of order of minutes. <br />
<br />
Thorsten mentioned that Richard's [[Emesary]] framework would be ideal for this sort of thing. <br />
<br />
The changes AW side would be modest - basically a shift to a dedicated random number generator, a routine to build a tile based on incoming information, one to store and encode the meta-data of tiles already created and that'd basically be it. Thorsten never did anything into this direction because he does not do MP himself, and has no opportunity to test and developing blind without being able to see how it works isn't what he considers fun... But that's the kind of thing Thorsten would do to synchronize weather across sessions.<ref>{{cite web<br />
|url = https://sourceforge.net/p/flightgear/mailman/message/35491937/ <br />
|title = <nowiki> Re: [Flightgear-devel] Traffic 2020: Towards a new Development<br />
Model for FlightGear AI Traffic </nowiki> <br />
|author = <nowiki> Thorsten Renk </nowiki> <br />
|date = Nov 15th, 2016 <br />
|added = Nov 15th, 2016 <br />
|script_version = 0.40 <br />
}}</ref><br />
<br />
Speaking for AW: the main thing is lots of stuff is a lot easier if you can assume it happens in the 100 km around a certain spot. Basically you can assume Earth is reasonably flat, you can expand coordinates into a local Cartesian system of equally-sied tiles, you never need to put up with spherical trig, you can put enough 'looseness' into the weather grid such that it gradually deforms to adapt to prevailing winds and traces the fronts (for instance weather at fronts is oriented - there's a cold and a warm side to a front with quite different properties). If you have to cover the whole globe with about equally sized weather tiles, the form of the grid and continuity quickly becomes issues. If you allow tile sizes to shrink with latitude, then the larger clouds may not fit into a tile any more... You have to use spherical trigonometry to set up everything, it's not clear where the 'looseness' to deal with frontal weather or higher latitudes should come from... Don't you wish sometimes we'd live on Discworld? Personally I think the idea of a local 'loose' grid gradually adapting to what's needed is pretty neat because it solves a lot. How you'd MP that depends on whether you want to have exact sync (i.e. see the identical arrangement of clouds at identical places) or approximate sync (see optically similar weather) across instances. Exact sync means either giving up the loose grid (without a clear idea on my side of what should replace it) or as in the P2P mode, allow the first plane in the region of interest to define the grid and make all others use it as long as they're close and transit to their own as they depart (should be unproblematic as long as Earth is sparsely covered by MP planes, i.e. most of the planet would not have to explicitly generate weather tiles - which I believe is the case). Approximate sync means that each instance fetches weather tile meta-data from the server and build from that (rather than its own random number driven tile generator), but that will not have the grids for two planes precisely aligned with each other, so they will see the same type of clouds and weather, but not necessarily in the same spot. Needless to say, that's easier. (Note that whether you see a cloud and fog etc. also depends on rendering settings, so we're unable to guarantee identical weather visuals for the simple reason that we have different renderers and selectable LOD and density ranges for clouds). That's at least my two cents. It wasn't called 'local weather' for nothing ;-)<ref>{{cite web<br />
|url = https://sourceforge.net/p/flightgear/mailman/message/35492964/ <br />
|title = <nowiki> Re: [Flightgear-devel] Traffic 2020: Towards a new Development<br />
Model for FlightGear AI Traffic </nowiki> <br />
|author = <nowiki> Thorsten Renk </nowiki> <br />
|date = Nov 15th, 2016 <br />
|added = Nov 15th, 2016 <br />
|script_version = 0.40 <br />
}}</ref><br />
<br />
== Development ==<br />
* Some users have expressed having problems when using the reset/new location facility, the local weather system should probably register listeners to /sim/signals/* and suspend/reset itself accordingly, so that all operations are gracefully interrupted? This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://forum.flightgear.org/viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=165#p94765]<br />
* Dynamically examining the FG/Nasal APIs by running code that may cause exceptions, may also cause errors printed to the console, it would probably be a good idea to expose logging related variables to the property tree, so that the log system can be optionally muted in such cases, i.e. by introducing a "NONE" or "MUTE" logging priority [http://forum.flightgear.org/viewtopic.php?f=5&t=7358&p=96439#p96370].<br />
* The feature-checking approach used by "compat_layer.nas" should probably be generalized and made available as a standard Nasal module, also for use by other scripts, as it provides a good method for handling backward compatibility [http://forum.flightgear.org/viewtopic.php?f=5&t=7358&p=96439#p96358]<br />
* We could introduce another hash/namespace in the compat_layer module for Nasal based workarounds that are directly performance critical, so that the C++ implementation is prioritized.<br />
* For some uses, threading may provide a real performance benefit. However, we need to ensure that threading is always OPTIONAL, so that users can easily verify if potential problems are related to threading or not. Worker threads seem to be the easiest and safest way for doing that.<br />
* Excessive use of the property tree for storing all sort of state variables is a potential performance bottleneck, it is usually better to directly use Nasal data structures. In addition, it is much easier to make use of worker threads when all data is available in Nasal space, especially given that the property tree (and basically all Nasal extension functions) are not designed to be thread safe.<br />
* To be able to further optimize the system, it might be good to integrate some form of simple benchmark so that users can easily provide the results [http://forum.flightgear.org/viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=165#p94801] (we talked about this in 9/2011, there are possibilities to provide this info automatically, but these would require modifying the core Nasal interpreter, and probably introducing some new instrumentation-specific opcodes, too - that doesn't seem to be a very popular idea at the moment, though).<br />
<br />
== Feature requests on the C++ side ==<br />
Intended as a base for discussions on how to implement particular features in the C++ code. Also see [http://forum.flightgear.org/viewtopic.php?f=5&t=8365 Weather algorithms discussion] from 06/2010.<br />
<br />
As of version 0.81, the local weather system runs on a high-end system, but has problems on slower machines and could use performance boosts from implementing some features which currently are done from Nasal in C++. Guiding principles for that should be '''performance''', '''accessibility''', a '''clear structure''' and '''backward compatibility'''. The decision if a particular function should be implemented on the C++ level should be investigated with these in mind - usually performance is served better from C++, but Nasal structures remain more accessible. For example, cloud configurations (assembling a vector of coordinates where to place clouds) can usually be done in Nasal in a single frame and thus the performance boost when porting to C++ is marginal. On the other hand, cloud configurations are crated by functions which turn a set of parameters into cloud positions, and it is useful to have quick access to the parameters and functions to tune the system to reproduce a real sky better and better without the need to recompile the code. Thus, cloud configuration computations are an example for structures which should probably not be ported to C++.<br />
<br />
Based on an idea by Hooray, version 0.81 of the local weather package has low-level function calls gathered in a separate Nasal file '''compat_layer.nas'''. The idea is that C++ counterparts for these are supplied, along with Nasal structures which check if the FlightGear core has the functionality and call the C++ function if the functionality is there while they use current Nasal implementations if no C++ structures are available, thus ensuring backward compatibility to FlightGear 2.0.0. Anyone interested in porting a structure to C++ could then start to implement one of the functions found there. These functions are:<br />
<br />
=== Terrain related ===<br />
* (08/2012) provide an option to decouple terrain loading from visibility, so that geodinfo and the terrain presampler can also query terrain which is invisible [http://forum.flightgear.org/viewtopic.php?f=69&t=7358&start=525#p164198] [https://code.google.com/p/flightgear-bugs/issues/detail?id=848&sort=-id&colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].<br />
<br />
* To check for wave conditions far from the original obstacle doesn't work well in FlightGear, because you can't rely on terrain far from your present location being loaded already. So by necessity one has to make it a more local phenomenon.<br />
<br />
=== Environment related ===<br />
* <del>(08/2012): Provide an option to disable the precipitation "layer" system [http://forum.flightgear.org/viewtopic.php?f=69&t=7358&start=525#p163627]: Local Weather has no precipitation rendering. This is due to the fact that the system uses its own layer altitude definition and a 3d definition of where rain is falling, whereas the precipitation rendering system uses a lowest altitude criterion. Since lowest layer altitude is always zero when local weather is running (it uses its own cloud altitude management and since clouds need to be placed with offset to the layer, it's easiest to make that layer zero) Local Weather has never rain unless you fly to the dead sea (not much chance of rain there either...). Could someone please provide a dumb rain and snow flag which alwaysrenders rain when that flag is set and leave it to the weather system to set/unset that flag as it sees fit? [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35256.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg34300.html]</del> (fixed by Stuart)<br />
<br />
* (06/2012) Sun is always painted on top of the skydome, you even see it through what is supposed to be terrain from high altitude. That's an issue for the maintainer of the sun code, it isn't curable via Nasal. See [https://code.google.com/p/flightgear-bugs/issues/detail?id=788&sort=-id&colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].<br />
<br />
* Expose the atmospheric model to the property tree (or Nasal) [http://forum.flightgear.org/viewtopic.php?f=30&t=8743#p86387] [http://forum.flightgear.org/viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=15#p70714] [http://www.av8n.com/fly/fgfs/README.altimetry.html] [http://www.av8n.com/physics/altimetry.htm]<br />
<br />
* Once I cross the mountaintops, some system switches on turbulence (I suspect ridge lift, since I could not find any other property which would create turbulence). That's bad, because wave lift isn't turbulent at all. To disable the ridge lift system, set '''/environment/ridge-lift/enabled''' to 0<br />
<br />
=== Cloud placement ===<br />
* 08/2012: Cloud placement meanwhile uses a new fgcommand "add-cloud", however that's using the property tree, and it only places a single cloud - it might make sense to provide another version which places multiple clouds at once, so that a single call can add several clouds. This would probably be faster by using a Nasal extension function, instead of an fgcommand.<br />
<br />
* Calls to place cloud models into the scenery, to remove them and to change their position. Compared with the standard FlightGear 3d clouds, placing and moving models from Nasal seems exceedingly slow. However, local weather uses some features for which it is not obvious if they are supported by the way the standard 3d clouds are implemented. These are:<br />
<br />
:* A 'cloudlet' is not a single texture, but a complete *.ac model. This allows to make multi-layered cloudlets and opens the possibility to make sure that one type of cloud texture is always seen in front of another (for example, a diffuse haze could always be before a well-structured cloud top, such that the top seems to emerge from the haze). This is a *very* useful feature for designing clouds, and is also non-trivial to get via explicit placement rules. <br />
<br />
:* Clouds need to be identified by various means. For movement, the system needs to know all clouds in the visual field, for deletion all clouds with given tile index, for evolution (not implemented yet) all cloudlets which belong to a particular Cumulus cloud. Internally, this is done by storing pointers to the cloud property node in various arrays, such that simply using the right array ensures that the correct cloud is referenced for an operation. Any C++ implementation should preferably allow similar referencing by pointer from Nasal or provide equivalent functionality to replace what the pointer array is for.<br />
<br />
=== Performance bottlenecks ===<br />
For reference, the main performance bottlenecks in v0.81 seem to be:<br />
<br />
* Rotating cloud models towards the viewer. This scales with the number of vertices, and is currently done by the shader. Performance is needed whenever clouds are in the field of view. Probably performance here can not be improved significantly and this is an upper limit for the number of distinct clouds which can be in the field of view - for denser cloud population, larger textures containing a group of clouds can be used.<br />
<br />
* Moving clouds with the wind. This scales with the number of cloudlets in the field of view and is done by Nasal. performance is needed whenever dynamical weather is on and clouds are in the field of view. Currently, the Nasal code limits the max. number of clouds in the loop to avoid a dramatic drop in framerate, which means that not all clouds in the visual field may be processed. <br />
<br />
* Generating a cloud configuration. This is only a significant issue for convective clouds, where several thousand terrain coverage calls need to be done. More performance is needed in more detailed terrain (custom France for example). Performance is only needed when a weather tile is generated, so unlike in the previous cases, performance loss occurs over a finite time interval, after which things get back to normal<br />
<br />
* Sampling terrain elevation (as above, just no terrain coverage, only elevation data is needed) <br />
<br />
* Placing clouds into the scenery. Performance is reduced while the FlightGear core lets clouds appear in the scenery<br />
<br />
* Deleting clouds. A brief drop in framerate (usually less than a second) occurs when a large amount of information is deleted from the property tree.<br />
<br />
* Frequently used fgcommands <br />
<br />
* Property tree access (i.e. reduce property tree use and use native Nasal data structures where possible)<br />
<br />
=== New Nasal API requests ===<br />
For things that should be implemented as new Nasal APIs, rather than being hard coded features in C++<br />
The file {{fg root file|Nasal/local_weather/compat_layer.nas}} contains compatibility wrappers for functions that are currently implemented in Nasal space, because the corresponding features are not yet supported by the core fgfs/Nasal APIs. This may be a good starting point for implementing new Nasal APIs.<br />
<br />
<br />
<br />
== Galleries ==<br />
==== Feature gallery of version 0.85 ====<br />
[[File:local_weather_0.85_01.jpg|150px|[ Cumulus and Cirrocumulus clouds (Local Weather v0.85)]]<br />
[[File:local_weather_0.85_02.jpg|150px|[ Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)]]<br />
[[File:local_weather_0.85_03.jpg|150px|[ 45 km cloud visibility range (Local Weather v0.85)]]<br />
[[File:local_weather_0.85_04.jpg|150px|[ Realistic cloud bottoms (Local Weather v0.85)]]<br />
[[File:local_weather_0.85_05.jpg|150px|[ Cumulus and Altocumulus clouds (Local Weather v0.85)]]<br />
[[File:local_weather_0.85_06.jpg|150px|[ Multiple 3d layered clouds (Local Weather v0.85)]]<br />
<br />
==== Feature gallery of version 1.0 ====<br />
[[File:local_weather_1.00_05.jpg|150px|[ Realistic skies with multiple cloud types (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_06.jpg|150px|[ Thin 3d cloud layers (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_11.jpg|150px|[ Thermal soaring beneath Cumulus clouds (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_12.jpg|150px|[ Flying with both thermal and ridge lift (Local Weather v1.0)]]<br />
<br />
[[File:local_weather_1.00_01.jpg|150px|[ Thick stratocumulus layers (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_03.jpg|150px|[ Thin Cirrocumulus sheets (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_02.jpg|150px|[ Altostratus layers (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_04.jpg|150px|[ Stratus coverage obscuring the sunlight (Local Weather v1.0)]]<br />
<br />
[[File:local_weather_1.00_07.jpg|150px|[ Evening light... (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_09.jpg|150px|[ ... and morning light (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_10.jpg|150px|[ Multiple 3d layers (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_08.jpg|150px|[ Heavy rain (Local Weather v1.0)]]<br />
<br />
==== Feature gallery of FGFS 3.0 ====<br />
[[File:Cloud shadows.jpg|150px|[EC 135 P2 "Air Zermatt" near Lugano with new cloud shadows]]<br />
[[File:Cloud shadows 2.jpg|150px|[EC 135 P2 "Air Zermatt" near Lugano with new cloud shadows 2]]<br />
<br />
==== Feature gallery of FGFS 3.5 ====<br />
[[File:Twin otter sunrise.png|150px]]<br />
[[File:Twin otter weather.png|150px]]<br />
[[File:Twin otter fog.png|150px]] <br />
[[File:Twin otter ALS.png|150px]]<br />
[[File:Twin otter clouds.png|150px]]<br />
<br />
== Download ==<br />
* Advanced weather is now included in FlightGear, so in its Git repository you get the newest version: http://sourceforge.net/p/flightgear<br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[Atmospheric light scattering]]<br />
* [[Weather]]<br />
<br />
=== Forum topics ===<br />
* [http://forum.flightgear.org/viewtopic.php?f=5&t=8365 Weather algorithms] (06/2010)<br />
* [http://forum.flightgear.org/viewtopic.php?f=5&t=8137 A smart cloud altitude algorithm] (05/2010)<br />
* [http://forum.flightgear.org/viewtopic.php?f=5&t=7591 Weather dynamics] (04/2010)<br />
* [http://forum.flightgear.org/viewtopic.php?f=5&t=6968 New thunderstorm AI scenario alpha release] (02/2010)<br />
* [http://forum.flightgear.org/viewtopic.php?f=5&t=7107 Cirrus sky (download link in first post)] (02/2010)<br />
* [http://forum.flightgear.org/viewtopic.php?f=5&t=7358 A local weather system] (03/2010)<br />
<br />
<br />
== References ==<br />
{{Appendix}}<br />
<br />
[[Category:Weather]]<br />
[[Category:Development projects]]</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=Video_encoding&diff=138403Video encoding2023-09-20T21:13:58Z<p>Cgdae: /* Overview */</p>
<hr />
<div>== Overview ==<br />
<br />
Flightgear on next (the development branch) has support for video encoding of the main window. This requires that ffmpeg/libav libraries are available at build time.<br />
<br />
* Videos are generated in the current directory. This can be changed by setting property '''/sim/video/directory'''.<br />
* Video files are called '''fgvideo-<aircraft>-YYYYMMDD-HHMMSS.<container>''', for example '''fgvideo-harrier-gr3-20211209-234105.mp4'''.<br />
* A convenience link is created that points to the latest video, called '''fgvideo-<aircraft>.<container>''', for example '''fgvideo-harrier-gr3.mp4''' -> '''fgvideo-harrier-gr3-20211209-234105.mp4'''.<br />
* Encoding performance can be improved by changing OSG's default thread-cpu affinity behaviour; see [[ThreadCPUAffinities]].<br />
<br />
== Limitations ==<br />
<br />
* As of 2021-12-12, only Unix builds of Flightgear include support for video encoding by default.<br />
** On other platforms, if ffmpeg libraries are installed on the system, Flightgear's cmake might pick them up automatically and enable video encoding, but this hasn't been tested.<br />
* We do not (yet) record sound.<br />
<br />
== Building ==<br />
<br />
On Unix, we require these libraries and their header files to be available at build time:<br />
<br />
* avcodec<br />
* avutil<br />
* swscale<br />
* avformat<br />
<br />
If these libraries and header files are installed, a standard cmake build should automatically include video encoding support.<br />
<br />
As of 2021-12-27, [[Scripted_Compilation_on_Linux_Debian/Ubuntu|download_and_compile.sh]] installs these libraries automatically.<br />
<br />
On Devuan (and probably other Debian-based distributions), they can be manually installed with:<br />
<br />
sudo apt install libavcodec-dev libavutil-dev libswscale-dev libavformat-dev<br />
<br />
== Creating video of live Flightgear ==<br />
<br />
=== Starting/stopping video encoding ===<br />
<br />
Use menu items '''File/Video Start''' and '''File/Video Stop''' to start/stop video encoding.<br />
<br />
* If an error occurs, for example support for video encoding was not included at build time, Flightgear will show a popup warning message.<br />
<br />
=== Video encoding settings ===<br />
[[File:Video-control dialogue.png|thumb]]<br />
Menu '''File/Video Control''' opens a dialogue that allows control over various settings, including:<br />
<br />
* Container name, such as '''mp4''' or '''ogv'''.<br />
** Radio buttons are provided for common containers.<br />
** Run '''ffmpeg -formats''' in a separate terminal to see what containers are available on your system.<br />
* Codec name, such as '''mpeg2video''', '''libx264''', '''libx265'''.<br />
** Radio buttons are provided for common codecs.<br />
** Run '''ffmpeg -codecs''' in a separate terminal to see what codecs are available on your system.<br />
* Encoding quality in range '''0..1'''. Use '''-1''' for codec's default.<br />
* Encoding speed in range '''0..1'''. Use '''-1''' for codec's default.<br />
* Encoding target bitrate in bits per second. Use '''0''' for codec's default.<br />
<br />
Some combinations of container and codec are not supported by Ffmpeg, for example container '''OGV''' and codec '''H.265'''. If this happens, an error message will pop up; you can try again with different settings.<br />
<br />
== Creating video from Flightgear recordings ==<br />
<br />
Flightgear can automatically generate a video when replaying a recording file, stopping video encoding when we reach the end of the recording.<br />
<br />
Usually one would use a Continuous recording for this, as they contain full information regardless of the recording duration.<br />
<br />
* From within Flightgear:<br />
** In the '''Load Flight Recorder Tape''' dialogue, set the '''Auto-create video''' checkbox.<br />
** Optionally also set '''Fixed dt''' (see below).<br />
<br />
* With the command line '''--load-tape''' option:<br />
** Also specify '''--load-tape-create-video'''.<br />
** Optionally specify '''--load-tape-fixed-dt=...''' (see below).<br />
<br />
=== Using '''fixed-dt''' ===<br />
<br />
Setting '''fixed-dt''' to a non-zero value forces Flightgear to increment the FDM time in seconds by the specified amount each frame, instead of by the elapsed real-world time between frames. For example using a value of 0.04 will force a frame rate of 25fps.<br />
<br />
This allows creation of high quality videos from recordings, regardless of the rendering settings or speed of the host, at the expense of potentially taking longer than real time to create the recording.<br />
<br />
=== Command line examples ===<br />
<br />
Create a high quality video of a recording by running Flightgear with these command-line args:<br />
<br />
'''--load-tape=... --load-tape-create-video=1 --prop:bool:/sim/time/simple-time/enabled=true --load-tape-fixed-dt=0.04 --graphics-preset=high-quality'''<br />
<br />
Also fix video settings by setting the relevant properties:<br />
<br />
'''--load-tape=... --load-tape-create-video=1 --prop:bool:/sim/time/simple-time/enabled=true --load-tape-fixed-dt=0.04 --graphics-preset=high-quality --prop:/sim/video/container=mp4 --prop:/sim/video/codec=libx265 --prop:/sim/video/quality=0.75 --prop:/sim/video/speed=1'''<br />
<br />
=== Example video ===<br />
<br />
This 5 minute video flying around Manhattan with high rendering settings was created on a fairly slow laptop, taking about an hour to replay and encode: http://op59.net/fgvideo-harrier-gr3-20211206-230342-manhattan.mp4</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=User:Cgdae&diff=138402User:Cgdae2023-09-20T21:07:34Z<p>Cgdae: Moved thread-cpu-affinities to new wiki page.</p>
<hr />
<div>== Current ==<br />
<br />
== Completed ==<br />
<br />
These are all on next. Some items may also have been cherry-picked onto the current stable branch.<br />
<br />
* [[ThreadCPUAffinities|Control over thread-cpu affinities]].<br />
* [[YASim#Torus-shaped_contact_surface_on_next|YASim torus-shaped tyre contact surfaces]].<br />
* [[Video encoding]] of Flightgear's main window.<br />
** E.g. see: http://op59.net/fgvideo-harrier-gr3-manhattan.mkv<br />
* [[Highlighting]].<br />
* [[SimpleTime]].<br />
* [[ExtraViewWindows|Extra view windows]].<br />
* [[Instant_Replay#Record.2Freplay_on_next|Enhancements to record/replay]].<br />
* [[Carrier_over_MP#Pilot_Using_the_Carrier|Enhancements to multiplayer carrier operation]].<br />
*[https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/debug/logdelta.hxx logdeltas] - control of debug log levels based on source filename prefixes, line numbers and function prefixes.<br />
*[[Post_FlightGear_2020.2_LTS_changes#Record.2Freplay|Record/replay]]:<br />
** Multiplayer record.<br />
**Continuous record.<br />
**Recovery snapshots.<br />
*[[Changelog_2020.1#Multiplayer |Multiplayer views]].<br />
*[[Changelog_2020.1#Graphics |Tower View AGL]].<br />
<br />
== Other ==<br />
<br />
* [[:Category:Hackathon 2021 Ideas]].<br />
*[[Walk_build_system|The Walk Flightgear Build system]] - a different kind of build system which i use to build Flightgear.<br />
*Harrier-GR3 autohover: https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Harrier-GR3/<br />
*Flightgear on [http://www.openbsd.org OpenBSD].</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=ThreadCPUAffinities&diff=138401ThreadCPUAffinities2023-09-20T21:04:27Z<p>Cgdae: Created page with "=== Control over thread-cpu affinities. === This is on next. By default OSG ties the main thread and others to a single CPU core early on in startup. This can cause problems..."</p>
<hr />
<div>=== Control over thread-cpu affinities. ===<br />
<br />
This is on next.<br />
<br />
By default OSG ties the main thread and others to a single CPU core early on in startup. This can cause problems on Linux if one tries to run CPU-intensive tasks on other threads, because new threads inherit their parent thread's affinity settings.<br />
<br />
For example this can make video encoding run very slowly because the internal threads created by ffmpeg can end up all trying to run on the same core.<br />
<br />
One can change the default behaviour by setting the '''/sim/thread-cpu-affinity''' property on startup to "none", e.g. with '''--prop:/sim/thread-cpu-affinity=none'''.<br />
<br />
Allowed values are:<br />
<br />
* Empty string or unset: allow OSG to set thread affinities as normal.<br />
* "none": do not allow OSG to set thread affinities; the OS gets to choose what cores to use.<br />
* "osg": allow OSG to set up thread affinities but attempt to cancel affinity of main thread afterwards. (This doesn't really work.)<br />
<br />
One can also change the behaviour at runtime by setting property '''/sim/affinity-control''', e.g. to test the effect of thread affinities on frame rate:<br />
<br />
* Set to "clear": remember current threads' affinities then clear all thread affinities.<br />
* Set to "revert": restore thread affinities remembered from most recent '''clear''' setting.</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=SG_LOG&diff=137915SG LOG2023-07-20T10:08:02Z<p>Cgdae: /* Log deltas */</p>
<hr />
<div><code>SG_LOG</code> is a wrapper macro for the [[SimGear]] <code>logstream</code> class. By default, the <code>logstream</code> class writes all output to the [[console]]. <code>SG_LOG</code> simplifies debugging for core developers who regularly [[Building FlightGear|compile from source]]. It allows you to easily associate your debug messages with a "channel" and with a "priority". This mechanism allows users to explicitly enable to certain log messages, while ignoring others. This can be helpful in order to troubleshoot certain problems.<br />
<br />
== Usage ==<br />
Logging settings can be modified using the <code>--log-level=[level]</code> and <code>--log-class=[class]</code> [[command line]] options. Where <code>level</code> is one of the following:<br />
* <code>bulk</code><br />
* <code>debug</code><br />
* <code>info</code><br />
* <code>warn</code><br />
* <code>alert</code><br />
* <code>popup</code><br />
And <code>class</code> is a white space seperated list of any (combination) of the following:<br />
* <code>all</code><br />
* <code>ai</code><br />
* <code>enviroment</code><br />
* <code>flight</code><br />
* etc.<br />
<br />
For a complete list of available classes, see {{simgear file|simgear/debug/debug_types.h}}.<br />
<br />
If you are interested in simply logging certain properties to a file at runtime, you can use either FlightGear's built-in [[Logging properties|logging framework]], or the [[generic protocol]].<br />
<br />
== File/line numbers ==<br />
<br />
Log output will be prefixed with <code>&lt;filename&gt;:&lt;line&gt;:</code> if Flightgear is started with command-line option <code>--prop:bool:/sim/log-file-line=true</code>.<br />
<br />
Text output from Nasal will be prefixed with <code>&lt;nasal-filename&gt;:&lt;line&gt;:</code> if Flightgear is started with command-line option <code>--prop:bool:/sim/nasal-log-file-line=true</code>.<br />
<br />
== Log deltas ==<br />
<br />
On can modify log levels based on the file/function-name/line-number of calls to <code>SG_LOG()</code>, by setting the environmental variable <code>SG_LOG_DELTAS</code> when running Flightgear.<br />
<br />
For example one can increase debugging diagnostics from scenery paging code with:<br />
<br />
<code>SG_LOG_DELTAS=src/Scenery/SceneryPager.cxx=+3 fgfs.exe ...</code><br />
<br />
Or set to <code>=-5</code> to reduce all diagnostics by 5:<br />
<br />
<code>SG_LOG_DELTAS==-5 fgfs.exe ...</code><br />
<br />
For more information see: {{simgear file|simgear/debug/logdelta.hxx}}.<br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[Command line options#Debugging Options]]<br />
* [[Commonly used debugging tools#Console and startup log output]]<br />
<br />
=== Source code ===<br />
* {{simgear file|simgear/debug/logstream.cxx}}<br />
* {{simgear file|simgear/debug/logstream.hxx}}<br />
* {{simgear file|simgear/debug/debug_types.h}}<br />
<br />
[[Category:Core developer documentation]]</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=Input_device&diff=137773Input device2023-06-10T12:06:47Z<p>Cgdae: /* Multiple mice on Linux */</p>
<hr />
<div>Could you imagine a pilot in his or her [[:Category:Cessna|Cessna]] controlling the machine with a keyboard alone? For getting the proper feeling of flight you will need a '''joystick/yoke''' plus [[rudder]] pedals, right? <br />
<br />
FlightGear has integrated joystick support, which automatically detects any joystick, yoke, or pedals attached. Just try it! If this does work for you, lean back and be happy! You can see what FlightGear has detected your joystick as in the Help > Joystick Configuration dialog from the [[menu]]. <br />
<br />
Unfortunately, for the above mentioned versatility, chances are your joystick does not work out of the box. This article explains you how to make FlightGear recognise your device<br />
<br />
== Joystick or yoke? ==<br />
{| cellpadding="4" cellspacing="0" align="right" style="clear:right; background:#fafafa; font-size: 85%; border: 1px solid #CCCCCC;" <br />
|-<br />
| [[File:CH Products Fighterstick USB.jpg|x199px|CH Products Fighterstick USB]]<br />
| [[File:Saitek Pro Flight Cessna Yoke front.jpg|300px|Saitek Pro Flight Cessna Yoke]]<br />
|-<br />
| CH Products Fighterstick USB<br />
| Saitek Pro Flight Cessna Yoke<br />
|}<br />
The two most common control devices on aircraft are the joystick (left picture) and yoke (right picture). Joysticks can be found on military fighters, helicopters and Airbus [[airliner]]s, while yokes are used on almost all other fixed wing aircraft, including Boeing airliners.<br />
<br />
Joysticks are generally a lot cheaper, starting at $10. Yokes start at $100. When you are new to flightsimming, buying a cheap (ca. $20) joystick might be a good way to find out if it's something for you.<br />
<br />
The following table should help you decide which one is best suited for you:<br />
{| class="wikitable"<br />
!<br />
! Joystick<br />
! Yoke<br />
|-<br />
! style="text-align:left;" | Price<br />
| $10+<br />
| $100+<br />
|-<br />
! style="text-align:left;" | General aviation<br />
| {{no}}<br />
| {{yes}}<br />
|-<br />
! style="text-align:left;" | Gliders<br />
| {{yes}}<br />
| {{no}}<br />
|-<br />
! style="text-align:left;" | Helicopter<br />
| {{yes}}<br />
| {{no}}<br />
|-<br />
! style="text-align:left;" | Fighters<br />
| {{yes}}<br />
| {{no}}<br />
|-<br />
! style="text-align:left;" | Most airliners including Boeing<br />
| {{no}}<br />
| {{yes}}<br />
|-<br />
! style="text-align:left;" | Airbus<br />
| {{yes}}<br />
| {{no}}<br />
|}<br />
<br />
It should be noted that any type of input device (be it a joystick, a yoke or even a gamepad) will work with '''all''' aircraft in FlightGear and that the table above only suggests which ones are more suited to specific types of aircraft given how they are flown in real life.<br />
<br />
Some reviews of flight simulation hardware can be found in [[:Category:Hardware reviews]].<br />
<br />
== Built-in joystick support ==<br />
In order for joystick auto-detection to work, a joystick bindings xml file must exist for each joystick. This file describes what axes and buttons are to be used to control which functions in FlightGear. The associations between functions and axes or buttons are called "bindings".<br />
<br />
FlightGear includes a large number of such bindings files for a variety of manufacturers. Chances are high that your joystick will be recognised straight away, so let's try that first. You can confirm whether it was recognised by looking in the <tt>File > Joystick Configuration</tt> dialog. "Used for" should contain a name/description of your joystick. It will contain "default" when FlightGear did not recognise your joystick.<br />
<br />
Most of the time when your joystick is not recognised, it is because of a missing name definition in the respective bindings file. Because FlightGear is used on all kind of operating systems, names vary a lot. You can find the files under <tt>[[$FG_ROOT]]/Input/Joysticks/</tt> (despite the name, yokes and pedals are also found here!). For example, if you have a CH Products joystick, look in the folder <tt>[[$FG_ROOT]]/Input/Joysticks/CH</tt> for a file that might work for your joystick. When such a file exists, do the following:<br />
# Launch FlightGear with the joystick connected.<br />
# Look under File > Joystick Configuration and check the name behind "Joystick #0:". <br />
# Open your joystick's bindings file in a XML editor and add the following code to the file, below the already-present <code><name></code> tags.<br />
# <syntaxhighlight lang="xml"><name>The EXACT name you found under step 2; including spaces, capitals etc.</name></syntaxhighlight><br />
# Please report this name [http://forum.flightgear.org/viewforum.php?f=24 at our forum], so it can be added to the official file (and next releases).<br />
<br />
Please note that the latest config files are always to be found at {{fgdata file|Input/Joysticks}}. This link may contain additional binding files that were not included in the latest stable release.<br />
<br />
If there is no file for your joystick, you will have to create such a file. We will discuss that in [[Joystick#Writing or editing joystick binding xml files|a later section]], by cutting and pasting bindings from the examples that are included with FlightGear.<br />
<br />
=== Multiple devices on Windows ===<br />
In case you have two USB devices (for instance a yoke plus pedals) to a Windows computer, there may be cases, where the same driver name is reported twice. In this case, you can get at least the yoke to work by assigning it number 0 (out of 0 and 1), by adding a line to <tt>[[$FG_ROOT]]/joystick.xml</tt> like:<br />
<syntaxhighlight lang="xml"><js n="0" include="Input/Joysticks/Saitek/ST290-Pro.xml"/></syntaxhighlight><br />
if you also have pedals (or another joystick), just add more lines, similar to:<br />
<syntaxhighlight lang="xml"><js n="1" include="Input/Joysticks/Saitek/Pro-Flight-Rudder-Pedals.xml"/></syntaxhighlight><br />
<br />
To make sure that the first input device is indeed the yoke, rotate the yoke ([[aileron]] control) and observe the Help > Joystick Configuration dialog. If the aileron value does not change, you have to make the yoke the preferred device first. For doing so, enter the Windows "Control panel", open "Game controllers" and select the "Advanced" button. Here you can select the yoke as the "Preferred" device. Afterwards you can check that assignment by restarting FlightGear. The yoke should now control the aileron.<br />
<br />
== Adding support for your joystick ==<br />
=== Verifying your joystick is working ===<br />
==== Linux ====<br />
Reboot your system and immediately enter on the [[command line]] <br />
<br />
<syntaxhighlight lang="bash"><br />
dmesg | grep Joystick <br />
</syntaxhighlight><br />
<br />
which pipes the boot message to grep which then prints every line in the boot message that contains the string “Joystick”. When you do this with a Saitek joystick attached, you will see a line similar to this one: <br />
<br />
<syntaxhighlight><br />
input0: USB HID v1.00 Joystick [SAITEK CYBORG 3D USB] on usb2:3.0 <br />
</syntaxhighlight><br />
<br />
This line tells us that a joystick has identified itself as SAITEK CYBORG 3D USB to the operating system. It does not tell us that the joystick driver sees your joystick. You can verify that the joystick driver sees the joystick by entering:<br />
<br />
<syntaxhighlight><br />
js_demo <br />
</syntaxhighlight><br />
<br />
If your joystick is not recognized by the driver, you may have to manually load the joystick device module with the command:<br />
<br />
<syntaxhighlight><br />
modprobe joydev<br />
</syntaxhighlight><br />
<br />
==== Windows ====<br />
Go to <tt>Start > Control Panel > Game Controller</tt> and see whether the dialog displays (and responses) on your joystick. <br />
<br />
=== Confirming that the driver recognizes your joystick ===<br />
FlightGear ships with a utility called js_demo. It will report the number of joysticks attached to a system, their respective "names" and their capabilities. Under Linux, you can run js_demo from the folder /FlightGear/bin as follows: <br />
<br />
<syntaxhighlight lang="bash"><br />
$ cd /usr/local/FlightGear/bin <br />
$ js_demo<br />
</syntaxhighlight><br />
<br />
Under Windows, open a command shell (<tt>Start > All Programs > Accessories > Command Prompt</tt>), go to the FlightGear binary folder and start the program as follows (given FlightGear is installed under <tt>C:/Program Files/Flightgear</tt>) <br />
<br />
<syntaxhighlight lang="dos"><br />
C:<br />
cd /Program Files/FlightGear/bin/win32 <br />
js_demo.exe <br />
</syntaxhighlight><br />
<br />
<!--If js_demo.exe is not included in your version, download it [http://fgfs.beggabaur.de/forum/js_demo.exe here].--><br />
<br />
On our system, the first few lines of output are (stop the program with C if it is quickly scrolling past your window!) as follows: <br />
<br />
<syntaxhighlight><br />
Joystick test program. <br />
Joystick 0: “CH PRODUCTS CH FLIGHT SIM YOKE USB ” <br />
Joystick 1: “CH PRODUCTS CH PRO PEDALS USB” <br />
Joystick 2 not detected <br />
Joystick 3 not detected <br />
Joystick 4 not detected <br />
Joystick 5 not detected <br />
Joystick 6 not detected <br />
Joystick 7 not detected <br />
+——————–JS.0———————-+——————–JS.1———————-+ <br />
| Btns Ax:0 Ax:1 Ax:2 Ax:3 Ax:4 Ax:5 Ax:6 | Btns Ax:0 Ax:1 Ax:2 | <br />
+———————————————-+———————————————-+ <br />
| 0000 +0.0 +0.0 +1.0 -1.0 -1.0 +0.0 +0.0 . | 0000 -1.0 -1.0 -1.0 . . . . . | <br />
</syntaxhighlight><br />
<br />
First note that js demo reports which number is assigned to each joystick recognized by the driver. Also, note that the “name” each joystick reports is also included between quotes. We will need the names for each bindings file when we begin writing the binding xml files for each joystick.<br />
<br />
=== Identifying the numbering of axes and buttons ===<br />
Axis and button numbers can be identified using js demo as follows. By observing the output of js demo while working your joystick axes and buttons you can determine what axis and button numbers are assigned to each joystick axis and button. It should be noted that numbering generally starts with zero. <br />
<br />
The buttons are handled internally as a binary number in which bit 0 (the least significant bit) represents button 0, bit 1 represents button 1, etc., but this number is displayed on the screen in hexadecimal notation, so: <br />
<br />
* 0001 ⇒ button 0 pressed <br />
* 0002 ⇒ button 1 pressed <br />
* 0004 ⇒ button 2 pressed <br />
* 0008 ⇒ button 3 pressed <br />
* 0010 ⇒ button 4 pressed <br />
* 0020 ⇒ button 5 pressed <br />
* 0040 ⇒ button 6 pressed <br />
* ... etcp to ... <br />
* 8000 ⇒ button 15 pressed <br />
* ... and ... <br />
* 0014 ⇒ buttons 2 and 4 pressed simultaneously <br />
* ... etc. <br />
<br />
For Linux users, there is another option for identifying the “name” and the numbers assigned to each axis and button. Most Linux distributions include a very handy program, “jstest”. With a CH Product Yoke plugged into the system, the following output lines are displayed by jstest: <br />
<br />
<syntaxhighlight lang="bash"><br />
jstest /dev/js3 <br />
Joystick (CH PRODUCTS CH FLIGHT SIM YOKE USB ) has 7 axes and 12 buttons. Driver version is 2.1.0 <br />
Testing…(interrupt to exit) <br />
Axes: 0: 0 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 Buttons: 0:off 1:off 2:off 3:on 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off <br />
</syntaxhighlight><br />
<br />
Note the “name” between parentheses. This is the name the system associates with your joystick. <br />
<br />
When you move any control, the numbers change after the axis number corresponding to that moving control and when you depress any button, the “off” after the button number corresponding to the button pressed changes to “on”. In this way, you can quickly write down the axes numbers and button numbers for each function without messing with binary.<br />
<br />
In most modern repositories, there is a graphical version of this program, called "jstest-gtk", where you are given a list of attached devices to choose from, and then get a graphical representation of all axes and buttons.<br />
<br />
=== Calibration ===<br />
For many/most joysticks this step might not be necessary. If either, the centre position of the joystick does not yield near-zero values for relevant axes, or if the maximum value for an axis cannot be reached, or is reached too early, you need to calibrate the joystick. (Note that some calibration problems can be fixed with the flighgear joystick configuration files, but not all, e.g. if the maximum value is reached too early)<br />
<br />
==== Linux ====<br />
The program "jscal" (install from repositories if not already available on your system) provides a calibration routine for joysticks. You need to know or find out the device name of your joystick (usually /dev/js0 or /dev/input/js0 - instead of 0 a different number might need to be used, look at output of js_demo to figure out which). For example to calibrate the joystick with device name /dev/input/js0, execute<br />
<syntaxhighlight lang="bash">jscal -c /dev/input/js0<br />
</syntaxhighlight><br />
and follow instructions.<br />
The calibration is retained until the joystick is unplugged, or the computer rebooted. In order to save it for future use, execute <br />
<syntaxhighlight lang="bash">jscal -p /dev/input/js0<br />
</syntaxhighlight><br />
which will print the command that needs to be entered to restore the calibration, for example<br />
<syntaxhighlight lang="bash">jscal -s 6,1,0,8171,8171,65936,65374,1,0,8166,8166,65928,65494,1,0,128,128,4194176,4227201,1,0,128,128,4194176,4227201,1,0,0,0,536854528,536854528,1,0,0,0,536854528,536854528 /dev/input/js0<br />
</syntaxhighlight><br />
Copy the command you obtained into your startup script in order to restore calibration automatically.<br />
<br />
Recent versions of jscal have this simplified, you can store and restore your calibration settings.<br />
After calibration store the settings:<br />
<syntaxhighlight lang="bash">jscal-store /dev/input/js0<br />
</syntaxhighlight><br />
<br />
Then in your startup script recall the settings for the given device:<br />
<syntaxhighlight lang="bash">jscal-restore /dev/input/js0<br />
</syntaxhighlight><br />
<br />
However if you have multiple controllers connected, they might be renumbered on pluging/repluging. Best way to insure you get the correct calibration is to create a custom '''udev''' rule-set that you put into /etc/udev/rules.d/00-joystick.rules, similar to the following example:<br />
<syntaxhighlight lang="bash"><br />
#joystick rules to make the names persistent and reload the stored calibration profile<br />
ACTION!="add|change", GOTO="joystick_end"<br />
SUBSYSTEM!="input", GOTO="joystick_end"<br />
<br />
KERNEL=="js*", ATTRS{idProduct}=="a02f", ATTRS{idVendor}=="12bd", SYMLINK+="input/joystick" RUN+="/etc/udev/scripts/joycal.sh"<br />
KERNEL=="js*", ATTRS{name}=="Logitech Logitech Racing Wheel", SYMLINK+="input/logiwheel" RUN+="/etc/udev/scripts/wheelcal.sh"<br />
<br />
LABEL="joystick_end"<br />
</syntaxhighlight><br />
<br />
Then the scripts called would be as follows:<br />
*/etc/udev/scripts/joycal.sh:<br />
<syntaxhighlight lang="bash"><br />
#!/bin/sh<br />
jscal-restore /dev/input/joystick<br />
</syntaxhighlight><br />
*/etc/udev/scripts/wheelcal.sh<br />
<syntaxhighlight lang="bash"><br />
#!/bin/sh<br />
jscal-restore /dev/input/logiwheel<br />
</syntaxhighlight><br />
<br />
Now each time you plug/replug your joysticks/controllers they will get the persistent device names, and will get the correct calibration profile restored.<br />
<br />
<br />
The calibration is even more comfortable using the program "jstest-gtk", also available from most repositories. Starting this you are given a list of all attached joysticks with their device names. Pick the one you wish to inspect or calibrate and click 'Properties', then calibrate. This calibration tool offers the possibility to fine-tune the calibration by editing the numbers. The program manipulates the same internals as jscal so you can use jscal to save the calibration information for later use, as before.<br />
<br />
=== Writing or editing joystick binding xml files ===<br />
At this point, you have confirmed that the operating system and the joystick driver both recognize your joystick(s). You also know of several ways to identify the joystick “name” your joystick reports to the driver and operating system. You will need a written list of what control functions you wish to have assigned to which axis and button and the corresponding numbers. <br />
<br />
Make the following table from what you learned from js demo or jstest above (pencil and paper is fine). Here we assume there are 5 axes including 2 axes associated with the hat. <br />
<br />
{| class="prettytable"<br />
! align="center" bgcolor="#EFEFEF" | Axis<br />
! align="center" bgcolor="#EFEFEF" | Button<br />
|- <br />
|elevator = 0 <br />
|view cycle = 0 <br />
|- <br />
|rudder = 1 <br />
|all brakes = 1 <br />
|- <br />
|aileron = 2 <br />
|up trim = 2 <br />
|- <br />
|throttle = 3 <br />
|down trim = 3 <br />
|-<br />
|leftright hat = 4 <br />
|extend flaps = 4 <br />
|- <br />
|foreaft hat = 5 <br />
|retract flaps = 5 <br />
|-<br />
| <br />
|decrease RPM = 6 <br />
|-<br />
|<br />
|increase RPM = 7 <br />
|}<br />
<br />
We will assume that our hypothetical joystick supplies the “name” QUICK STICK 3D USB to the system and driver. With all the examples included with FlightGear, the easiest way to get a so far unsupported joystick to be auto detected, is to edit an existing binding xml file. Look at the xml files in the sub-folders of '''/FlightGear/Input/Joysticks/'''. After evaluating several of the xml binding files supplied with FlightGear, we decide to edit the file <tt>[[$FG_ROOT]]/Input/Joysticks/Saitek/Cyborg-Gold-3d-USB.xml</tt>.<br />
<br />
This file has all the axes functions above assigned to axes and all the button functions above assigned to buttons. This makes our editing almost trivial. <br />
<br />
Before we begin to edit, we need to choose a name for our bindings xml file, create the folder for the QS joysticks, and copy the original xml file into this directory with this name. <br />
<br />
<syntaxhighlight lang="bash"><br />
$ cd /usr/local/FlightGear/Input/Joysticks <br />
$ mkdir QS <br />
$ cd QS <br />
$ cp /usr/local/FlightGear/Input/Joysticks/Saitek/ <br />
Cyborg-Gold-3d-USB.xml QuickStick.xml <br />
</syntaxhighlight><br />
<br />
Here, we obviously have supposed a Linux/UNIX system with FlightGear being installed under '''/usr/local/FlightGear'''. For a similar procedure under Windows with FlightGear being installed under C:/Program Files/FlightGear, open a command shell and type <br />
<br />
<syntaxhighlight lang="dos"><br />
C: <br />
cd /Program Files/FlightGear/Input/Joysticks <br />
mkdir QS <br />
cd QS <br />
copy /Program Files/FlightGear/Input/Joysticks/Saitek/ <br />
Cyborg-Gold-3d-USB.xml QuickStick.xml <br />
</syntaxhighlight><br />
<br />
Next, open QuickStick.xml with your favorite editor. Before we forget to change the joystick name, search for the line containing <name>. You should find the line <br />
<br />
<syntaxhighlight lang="xml"><name>SAITEK CYBORG 3D USB</name></syntaxhighlight><br />
<br />
and change it to <br />
<br />
<syntaxhighlight lang="xml"><name>QUICK STICK 3D USB</name></syntaxhighlight><br />
<br />
This line illustrates a key feature of xml statements. They begin with a <tag> and end with a </tag>. <br />
<br />
You can now compare your table to the comment table at the top of your file copy. Note that the comments tell us that the Saitek elevator was assigned to axis 1. Search for the string <br />
<br />
<syntaxhighlight lang="xml"><axis n="1"></syntaxhighlight><br />
<br />
and change this to <br />
<br />
<syntaxhighlight lang="xml"><axis n="0"></syntaxhighlight><br />
<br />
Next, note that the Saitek rudder was assigned to axis 2. Search for the string <br />
<br />
<syntaxhighlight lang="xml"><axis n="2"></syntaxhighlight><br />
<br />
and change this to <br />
<br />
<syntaxhighlight lang="xml"><axis n="1"></syntaxhighlight><br />
<br />
Continue comparing your table with the comment table for the Saitek and changing the axis numbers and button numbers accordingly. Since QUICKSTICK USB and the Saitek have the same number of axes but different number of buttons, you must delete the buttons left over. Just remember to double check that you have a closing tag for each opening tag or you will get an error using the file. <br />
<br />
Finally, be good to yourself (and others when you submit your new binding file to a FlightGear developers or users archive!), take the time to change the comment table in the edited file to match your changed axis and button assignments. The new comments should match the table you made from the js demo output. Save your edits. <br />
<br />
Several users have reported that the numbers of axes and buttons assigned to functions may be different with the same joystick under Windows and Linux. The above procedure should allow one to easily change a binding xml file created for a different operating system for use by their operating system.<br />
<br />
You can tell how FlightGear has interpretted your joystick setup by selecting <tt>Help > Joystick Configuration</tt> from the menu.<br />
<br />
== Joystick support via .fgfsrc entries ==<br />
Fortunately, there is a tool available now, which takes most of the burden from the average user who, maybe, is not that experienced with XML, the language which these files are written in. <br />
<br />
For configuring your joystick using this approach, open a command shell (command prompt under windows, to be found under Start|All programs|Accessories). Change to the directory <tt>[[$FG_ROOT]]/bin</tt> via e.g. (modify to your path) <br />
<br />
<syntaxhighlight lang="dos">cd C:/Program Files/FlightGear/bin</syntaxhighlight><br />
<br />
and invoke the tool fgjs via <br />
<br />
<syntaxhighlight lang="bash">./fgjs --fg-root=$FG_ROOT</syntaxhighlight><br />
<br />
on a UNIX/Linux machine, or via <br />
<br />
<syntaxhighlight lang="dos">fgjs --fg-root=$FG_ROOT</syntaxhighlight><br />
<br />
on a Windows machine. The program will tell you which joysticks, if any, were detected. Now follow the commands given on screen, i.eṁove the axis and press the buttons as required. Be careful, a minor touch already “counts” as a movement. Check the reports on screen. If you feel something went wrong, just re-start the program. <br />
<br />
After you are done with all the axis and switches, the directory above will hold a file called fgfsrc.js. If the FlightGear base directory FlightGear does not already contain an options file .fgfsrc (under UNIX)/system.fgfsrc (under Windows) mentioned above, just copy <br />
<br />
'''fgfsrc.js''' into '''.fgfsrc''' (UNIX)/'''system.fgfsrc''' (Windows) <br />
<br />
and place it into the directory FlightGear base directory FlightGear. In case you already wrote an options file, just open it as well as fgfsrc.js with an editor and copy the entries from fgfsrc.js into .fgfsrc/system.fgfsrc. One hint: The output of fgjs is UNIX formatted. As a result, Windows Editor may not display it the proper way. I suggest getting an editor being able to handle UNIX files as well, for example [https://notepad-plus-plus.org/ Notepad++]. <!-- My favorite freeware file editor for that purpose, although somewhat dated, is still PFE, to be obtained from http://www.lancs.ac.uk/people/cpaap/pfe/. --> <br />
<br />
The the axis/button assignment of fgjs should, at least, get the axis assignments right, its output may need some tweaking. There may be axes moving the opposite way they should, the dead zones may be too small etc. For instance, I had to change <br />
<br />
<syntaxhighlight><br />
--prop:/input/joysticks/js[1]/axis[1]/binding/factor=-1.0<br />
</syntaxhighlight><br />
<br />
into <br />
<br />
<syntaxhighlight><br />
--prop:/input/joysticks/js[1]/axis[1]/binding/factor=1.0<br />
</syntaxhighlight><br />
<br />
(USB CH Flightsim Yoke under Windows XP). Thus, here is a short introduction into the assignments of joystick properties. <br />
<br />
Basically, all axes settings are specified via lines having the following structure: <br />
<br />
<syntaxhighlight><br />
--prop:/input/joysticks/js[n]/axis[m]/binding/command=property-scale <br />
--prop:/input/joysticks/js[n]/axis[m]/binding/property=/controls/steering option<br />
--prop:/input/joysticks/js[n]/axis[m]/binding/dead-band=db<br />
--prop:/input/joysticks/js[n]/axis[m]/binding/offset=os<br />
--prop:/input/joysticks/js[n]/axis[m]/binding/factor=fa<br />
</syntaxhighlight><br />
<br />
where <br />
<br />
{| class="prettytable"<br />
! align="center" bgcolor="#EFEFEF" | <br />
! align="center" bgcolor="#EFEFEF" | <br />
|- <br />
|n<br />
|number of device (usually starting with 0) <br />
|-<br />
|m<br />
|number of axis (usually starting with 0)<br />
|-<br />
|steering option<br />
|elevator, aileron, rudder, throttle, mixture, pitch <br />
|-<br />
|dead-band<br />
|range, within which signals are discarded; useful to avoid jittering for minor yoke movements<br />
|-<br />
|offset<br />
|specifies, if device not centered in its neutral position <br />
|-<br />
|factor<br />
|controls sensitivity of that axis; defaults to +1, with a value of -1 reversing the behavior <br />
|}<br />
<br />
You should be able to at least get your joystick working along these lines. Concerning all the finer points, for instance, getting the joystick buttons working, John Check has written a very useful README being included in the base package to be found under '''FlightGear/Docs/Readme/Joystick.html'''. In case of any trouble with your input device, it is highly recommended to have a look into this document.<br />
<br />
== More about programming joystick XML files ==<br />
=== General tips ===<br />
* When testing a new xml file it is best to start FlightGear via a command window (rather than the GUI interface). Any error messages will then be displayed in the terminal. Error messages will give both a message and a line number, helping you pinpoint any errors.<br />
* Errors can be detected on initial startup or at runtime. Both types of errors will be displayed in the terminal.<br />
* One of the most common errors is including a character that makes XML choke. Such characters include<br>& < --<br>These characters will cause problems even if simply included in comments or within scripts.<br />
* If your scripts contain any of these characters, you have to enclose the scripts in <script><![CDATA[...]]></script>. Alternatively, you can 'escape' the characters, ie "<" becomes "&amp;lt;".<br />
* You can reload your edited joystick file without restarting FlightGear by selecting "Debug" &gt; "Reload Input" from the main simulator window.<br />
* You can find many examples of different ways to program joysticks simply by examining the joystick xml files that are packaged with FlightGear. See the directory FlightGear/data/input/joysticks<br />
* Many advanced functions can be programmed using the Nasal scripting language. These scripts are enclosed in <script></script> tags in the XML file. Helpful:<br />
** A guide to the [[Nasal scripting language]] in FlightGear <br />
** [[Nasal FAQ]]<br />
** [[Howto: Write simple scripts in Nasal]]<br />
* You can explore the internal property tree to see many variables that can be altered using joystick buttons or axes (File/Browse Internal Properties)<br />
* You can test bits of Nasal code and do some other useful things using the Nasal Console (Debug/Nasal Console).<br />
* All Nasal code shares a common namespace, so it's possible to set a variable in one nasal binding, and to read it in another.<br />
<br />
=== Useful hints for scripts ===<br />
Some particularly useful ideas for programming scripts within joystick XML files:<br />
* getprop and setprop can be used for getting & setting properties from the internal properties tree:<br />
<syntaxhighlight lang="nasal"><br />
var brake = !getprop("/controls/gear/brake-parking");<br />
setprop("/controls/gear/brake-parking", brake);<br />
</syntaxhighlight><br />
* You can also make your own values on the property tree:<br />
<syntaxhighlight lang="nasal"><br />
setprop("/input/joysticks/js[0]/myjoystick-modifier", 1);<br />
var mod = getprop("/input/joysticks/js[0]/myjoystick-modifier");<br />
</syntaxhighlight><br />
* You can print to terminal using the print function. This is very useful for debugging.<br />
<syntaxhighlight lang="nasal"><br />
print("Just", " a ", "test");<br />
</syntaxhighlight><br />
* You can display info in FlightGear via a popup. This is useful for giving the user feedback about changes that may not be obvious via the panel. It can also be useful for debugging. Example:<br />
<br />
<syntaxhighlight lang="nasal"><br />
gui.popupTip("Parking Brake ON");<br />
</syntaxhighlight><br />
<br />
Arguments for gui.popupTip must be strings, so if you want to display other types of variables they should be formatted with something like sprintf:<br />
<br />
<syntaxhighlight lang="nasal"><br />
gui.popupTip(sprintf("Elevator trim: %d", 100 * getprop("/controls/flight/elevator-trim")));<br />
</syntaxhighlight><br />
<br />
Or<br />
<br />
<syntaxhighlight lang="nasal"><br />
thv = getprop("/controls/engines/engine[0]/mixture");<br />
gui.popupTip("Thrust vector " ~ int(thv * 120 - 20));<br />
</syntaxhighlight><br />
<br />
* You can just start using variables, ie,<br />
<syntaxhighlight lang="nasal"><br />
x = 10;<br />
</syntaxhighlight><br />
<br />
But [http://wiki.flightgear.org/index.php/Nasal_scripting_language#Variables for various reasons] it is generally better to declare variables with the "var" statement:<br />
<syntaxhighlight lang="nasal"><br />
var x = 10;<br />
</syntaxhighlight><br />
<br />
Note that "var" creates variables that are local in scope, but since all bindings for a joystick share the same scope, it will be seen across each script in the joystick file.<br />
<br />
* You can include a section of script that runs on startup to initialize variables, create functions, etc. Example:<br />
<syntaxhighlight lang="xml"><br />
<PropertyList><br />
<name type="string">My joystick name</name><br />
<name type="string">My joystick name #2</name><br />
<nasal><br />
<script><br />
#initialize variables<br />
f1 = f2 = 0;<br />
left_brake = right_brake = 0;<br />
# create a function to be used with all buttons<br />
getmod = func { getprop("/input/joysticks/js[0]/t-flight-hotas-x-modifier" ) }<br />
</script><br />
</nasal><br />
</syntaxhighlight><br />
<br />
* Sample code for firing weapons with the joystick is found on the [[Gun Effects]] page.<br />
<br />
<br />
== Multiple mice on Linux ==<br />
<br />
On Linux, it is possible to make specific mice control specific Flightgear properties instead of the default flight controls.<br />
<br />
You will need to know the Linux name and ID for the mouse. This can be done by running the command <code>xinput --list</code> which lists all connected input devices. (Extra information about a specific device can be found with <code>xinput --list-props <id></code> or <code>xinput --list-props <name></code>.)<br />
<br />
Then create a file in <code>fgdata/Input/Event/</code>. The leafname doesn't matter, but for example it could be called <code>fgdata/Input/Event/MouseExtra.xml</code>. The contents of this file determine the properties that the mouse will control. For example:<br />
<br />
<pre><br />
<PropertyList><br />
<name>Logitech Logitech USB Optical Mouse</name><br />
<debug-events type="bool">false</debug-events><br />
<grab type="bool">true</grab><br />
<event><br />
<desc>Y-Axis</desc><br />
<name>rel-y-translate</name><br />
<binding><br />
<command>property-adjust</command><br />
<property>/controls/flight/elevator</property><br />
<factor type="double">-.002</factor><br />
<min type="double">-1.0</min><br />
<max type="double">1.0</max><br />
<wrap type="bool">false</wrap><br />
</binding><br />
</event><br />
<event><br />
<desc>X-Axis</desc><br />
<name>rel-x-translate</name><br />
<binding><br />
<command>property-adjust</command><br />
<property>/controls/flight/aileron</property><br />
<factor type="double">.002</factor><br />
<min type="double">-1.0</min><br />
<max type="double">1.0</max><br />
<wrap type="bool">false</wrap><br />
</binding><br />
</event><br />
</PropertyList><br />
</pre><br />
<br />
(Change <code><name>Logitech Logitech USB Optical Mouse</name></code> to match your mouse.)<br />
<br />
It can be useful to tell X to ignore the mouse so that it doesn't affect the main X pointer. This can be done with: <code>xinput --set-prop <id> "Device Enabled" 0</code>. Normal X handling of the mouse can be restored with <code>xinput --set-prop <id> "Device Enabled" 1</code>. (One can also use the name of the mouse instead of <code><id></code>.)<br />
<br />
On Devuan Linux, one can use a udev rule to ensure that the mouse can be read and written by flightgear (usually they are only accessible to root):<br />
* Create a file <code>/etc/udev/rules.d/90-fgmouseextra.rules</code> containing a single line <code>KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0666"</code>.<br />
* Reboot or run <code>udevadm control --reload-rules</code>.<br />
[Note that i know almost nothing about udev, and it's entirely possible that this represents a huge security flaw, so use with caution.]<br />
<br />
[The information above is based on the forum thread https://forum.flightgear.org/viewtopic.php?t=32750 and Torsten Dreyer's original email https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23171.html.]<br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[Bindings]]<br />
* [[Force feedback]]<br />
* [[Head tracking]]<br />
* [[Joystick xml library]] <br />
* [[Troubleshooting input devices]]<br />
* [[Writing Joystick Code: Part 1]]<br />
* [[Writing Joystick Code: Part 2]]<br />
* [[Writing Joystick Code: Part 3]]<br />
* [[Writing Joystick Code: Part 4]]<br />
<br />
=== Forum topics ===<br />
* {{forum link|f=24|title=Hardware}}<br />
<br />
== External links ==<br />
* [http://www.flightgear.org/Docs/getstart/getstartch3.html#x8-360003.6 The FlightGear Manual]<br />
* [http://sourceforge.net/projects/hapticsforfg/ Force Feedback]<br />
<br />
[[Category:Hardware]]<br />
[[Category:Joysticks and Yokes]]<br />
<br />
[[de:Joystick]]<br />
[[es:Joystick]]</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=Instant_Replay&diff=136954Instant Replay2023-01-02T13:03:38Z<p>Cgdae: /* FG 2.6.0 and later */ Removed confusing note about moving this article to a page that already redirects to this page.</p>
<hr />
<div>== Normal recording ==<br />
<br />
Flightgear maintains an in-memory recording of the current session. To avoid running our of memory, only the last minute or so is recorded in full detail, and older data is gradually pruned.<br />
<br />
The in-memory recording can be saved to a file.<br />
<br />
=== Starting and Controlling Replay of Normal recording ===<br />
<br />
* Press '''Ctrl-r''' or select '''Instant Replay''' from the '''View''' menu to start the replay. Replay starts immediately.<br />
* Press '''p''' or click '''pause''' to pause/resume the replay.<br />
* Use the '''left/right''' arrow keys, or the '''&lt;&lt;''', '''&gt;&gt;''' buttons to skip. You can also use the mouse and drag the time slider.<br />
* Use the '''up/down''' arrow keys, or the '''+''', '''-''' buttons to change replay speed. You can replay at slow-motion, real-time or fast-forward speed.<br />
* Enable the '''Loop''' checkbox to continuously repeat the playback. When you configure a duration (in seconds) then only the last few seconds are continuously replayed.<br />
<br />
[[File:FG-instant-replay-new.png|thumb|500px|The instant replay dialog.]]<br />
<br />
=== Stopping Replay ===<br />
<br />
* Press '''Escape''' or the '''End Replay''' button to stop replay and return to the position prior to starting replay.<br />
* Alternatively, click the '''My Controls!''' button to take over control at any point. With this feature you can use the replay system to go back in time, regain control and then continue the flight from a past position. This is useful to train particular flight phases, such as flying the same approach again and again, maybe using different weather/wind conditions.<br />
<br />
== Record/replay on next ==<br />
<br />
There are various additions to record/replay on next:<br />
<br />
* Extended '''File/Flight Recorder Control''' dialogue.<br />
[[File:Flight-recorder-control.png|thumb]]<br />
* Periodic generation of a recovery snapshot, allowing resumption after a flightgear crash.<br />
* Continuous recording system:<br />
** Continuous recording to file without any loss of detail.<br />
** Optionally record/replay extra information:<br />
*** Multiplayer aircraft.<br />
*** Main window size.<br />
*** Main window position.<br />
*** Main window view.<br />
* Aircraft override:<br />
** When loading a Continuous recording at startup, we override the aircraft and starting airport to match what is in the recording.<br />
* Replay of Continuous recordings from URL:<br />
** Extends the '''--load-tape command-line''' option, for example: '''--load-tape=<nowiki>http://foo.com/bar.fgtape</nowiki>'''<br />
<br />
=== Details ===<br />
<br />
* A recovery snapshot is actually a single-frame continuous recording, and will be called '''<aircraft-type>-recovery.fgtape'''.<br />
** Load on the command line with '''--load-tape=<aircraft-type>-recovery'''.<br />
** Then do '''Ctrl-R''' to see the replay dialogue.<br />
** And click on '''My Controls'''.<br />
** Notes:<br />
*** Some aircraft do not support '''My Controls'''.<br />
*** Loading a recovery file from within Flightgear via the '''Flight Recorder Control''' dialogue is usually not useful because the recovery file will have been overwritten by the current Flightgear session.<br />
* Continuous recording to file uncompressed is e.g. 100MB for an hour's recording near EDDF.<br />
* Support for compression of Continuous recordings was pushed to next on 2021-7-31 ({{flightgear commit|7d414886e00e}}).<br />
* Replay of Continuous recordings from URL:<br />
** Downloads to local file in the background while replaying.<br />
** Reuses local file if present, appending to it in the background if it was a partial download.<br />
** Local file is in directory specified by property '''/sim/replay/tape-directory'''.<br />
<br />
For details on recording file formats, see: {{flightgear file|docs-mini/README-recordings.md}}<br />
<br />
----<br />
<br />
== FG 2.6.0 and later ==<br />
the <br />
flight recorder tapes are only 1 or 2 hours max... at one time i wanted to do <br />
one for a cross-country flight but when i saved it i only got the last hour or <br />
two<br />
{{Note|<br />
{{FGCquote<br />
|the "my controls" button is currently intentionally disabled for JSBSim and for YASim helicopters. Only works with YASim aircraft so far.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/30084554/<br />
|title=<nowiki>Re: [Flightgear-devel] flight recorder / replay system</nowiki><br />
|author=<nowiki>ThorstenB</nowiki><br />
|date=<nowiki>2012-11-11</nowiki><br />
}}<br />
}}<br />
}}<br />
FG 2.6.0 introduced a new replay system which can be adapted to individual aircraft and provides better recordings/playbacks. It also introduces a new GUI as well as a dedicated file format for serializing flights to disk: [[Fgtape]].<br />
[[File:FG-instant-replay-new.png|thumb|500px|The instant replay dialog.]]<br />
<br />
== FG 2.4.0 and earlier ==<br />
[[File:FG-instant-replay.gif|thumb|220px|The instant replay dialog for FG2.4.0 and earlier.]]<br />
For FG 2.4.0 and earlier, a simple dialog box is presented with a couple of options (duration of replay and view type). <br />
* A value of 0 for duration will replay the entire flight. The default value is 90 seconds (similar to MSFS). If you want something different, just type the number of seconds desired in the text box. <br />
* The view option is a drop-down box with three options corresponding to Cockpit, Chase and Tower views. No matter what this is initially set to, the view type can be changed as normal with v/V and ctrl-v to cycle forwards or backwards through all the available views or return to default Cockpit view.<br />
<br />
To return to normal flight, press 'p' twice (pause/unpause). This returns you to the point where you selected Instant Replay. You cannot back up 30 seconds or so and try that landing again. Also, it is currently not possible to save the replay buffer to a file to load and replay a flight later on.<br />
<br />
'''Note:''' only data directly related to your aircraft is saved and played back, AI objects, multiplayer aircraft or any random features will not be replayed.<br />
<br />
{{FGCquote<br />
|The replay system uses three buffer levels: short term memory records 60 <br/><br />
seconds at full frame rate, mid term buffer records another 10 minutes <br/><br />
at 2fps, and the long term buffer holds 1 hour at 1/5fps. As I stated <br/><br />
earlier, I'm not changing the buffering scheme itself. However, the <br/><br />
buffer durations and rates are exposed by properties now. So, if you had <br/><br />
enough memory, you could increase the buffer sizes or change their rates.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28045468/<br />
|title=<nowiki>Re: [Flightgear-devel] flight recorder / replay system</nowiki><br />
|author=<nowiki>ThorstenB</nowiki><br />
|date=<nowiki>2011-09-05</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= You should be able to extend the recording limit by changing the /sim/reply/duration property (e.g. by clicking on View -> Instant Replay and changing the duration in the textbox next to the "Loop" checkbox). <br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/34868828/<br />
| title = <nowiki>Re: [Flightgear-devel] flight recorder time limit</nowiki><br />
| author = <nowiki>Alessandro Menti</nowiki><br />
| date = Feb 20th, 2016<br />
| added = Feb 20th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
<br />
== Feature Requests ==<br />
{{FGCquote<br />
|1= If the F/R data was written to disk immediately, so it doesn't have to take up valueable RAM, would make it possible to record nearly indefinitely (depending on disk space). And delete this data like a tmp-file on shutdown, if it isn't stored somewhere else...<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/34868775/<br />
| title = <nowiki>[Flightgear-devel] flight recorder time limit</nowiki><br />
| author = <nowiki>chris</nowiki><br />
| date = Feb 20th, 2016<br />
| added = Feb 20th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
{{FGCquote<br />
|1= This should be quite doable, the FlightRecorder code is quite self-contained. Also it uses thining of the history buckets so actually I think for multi-hour data, maybe it just needs a coarser (maybe one sample per 5 seconds?) bucket of larger sie. If you want to look at the code I’m happy provide guidance on enhancing it.<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/34869713/<br />
| title = <nowiki>Re: [Flightgear-devel] flight recorder time limit</nowiki><br />
| author = <nowiki>James Turner</nowiki><br />
| date = Feb 21st, 2016<br />
| added = Feb 21st, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
[Something similar to this is on next - see above.]<br />
<br />
* [[Howto:Record, analyze and replay multiplayer flights with network tools]]<br />
* [[Redesigning the Replay System]]<br />
<br />
=== Forum topics ===<br />
* {{forum link|p=373973|title=Re: How to start an A320 on approach with engines running?}} - Starting FlightGear with the <code>--load-tape</code> option, for example for approach training.<br />
<br />
=== Readme file ===<br />
* {{flightgear source |path=docs-mini/README-recordings.md}} (Description of Normal and Continuous recordings, up to date as of 2021-10-10.)<br />
* {{readme file|flightrecorder}} (Detailed description of Normal recordings, last modified 2013-06-20.)<br />
<br />
=== Source code ===<br />
* {{fgdata source|path=Aircraft/Generic/flightrecorder/}} - Generic flight recorder configuration files.<br />
<br />
* {{flightgear source|path=src/Aircraft/replay.hxx}}<br />
* {{flightgear source|path=src/Aircraft/replay.cxx}}<br />
<br />
[[Category:FlightGear feature]]<br />
[[Category:Menubar]]</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=User:Cgdae&diff=136953User:Cgdae2023-01-02T12:37:16Z<p>Cgdae: /* Completed */</p>
<hr />
<div>== Current ==<br />
<br />
=== Control over thread-cpu affinities. ===<br />
<br />
This work is on next.<br />
<br />
By default OSG ties the main thread and others to a single CPU core early on in startup. This can cause problems on Linux if one tries to run CPU-intensive tasks on other threads, because new threads inherit their parent thread's affinity settings.<br />
<br />
For example this can make video encoding run very slowly because the internal threads created by ffmpeg can end up all trying to run on the same core.<br />
<br />
One can change the default behaviour by setting the '''/sim/thread-cpu-affinity''' property on startup with '''--prop:/sim/thread-cpu-affinity=...''':<br />
<br />
* Empty string or unset: allow OSG to set thread affinities as normal.<br />
* Set to "none": do not allow OSG to set thread affinities; the OS gets to choose what cores to use.<br />
* Set to "osg": allow OSG to set up thread affinities but attempt to cancel affinity of main thread afterwards. (This doesn't really work.)<br />
<br />
One can also change the behaviour at runtime by setting property '''/sim/affinity-control''', e.g. to test the effect of thread affinities on frame rate:<br />
<br />
* Set to "clear": remember current threads' affinities then clear all thread affinities.<br />
* Set to "revert": restore thread affinities remembered from most recent '''clear''' setting.<br />
<br />
<br />
== Completed ==<br />
<br />
These are all on next. Some items may also have been cherry-picked onto the current stable branch.<br />
<br />
* [[YASim#Torus-shaped_contact_surface_on_next|YASim torus-shaped tyre contact surfaces]].<br />
* [[Video encoding]] of Flightgear's main window.<br />
** E.g. see: http://op59.net/fgvideo-harrier-gr3-manhattan.mkv<br />
* [[Highlighting]].<br />
* [[SimpleTime]].<br />
* [[ExtraViewWindows|Extra view windows]].<br />
* [[Instant_Replay#Record.2Freplay_on_next|Enhancements to record/replay]].<br />
* [[Carrier_over_MP#Pilot_Using_the_Carrier|Enhancements to multiplayer carrier operation]].<br />
*[https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/debug/logdelta.hxx logdeltas] - control of debug log levels based on source filename prefixes, line numbers and function prefixes.<br />
*[[Post_FlightGear_2020.2_LTS_changes#Record.2Freplay|Record/replay]]:<br />
** Multiplayer record.<br />
**Continuous record.<br />
**Recovery snapshots.<br />
*[[Changelog_2020.1#Multiplayer |Multiplayer views]].<br />
*[[Changelog_2020.1#Graphics |Tower View AGL]].<br />
<br />
== Other ==<br />
<br />
* [[:Category:Hackathon 2021 Ideas]].<br />
*[[Walk_build_system|The Walk Flightgear Build system]] - a different kind of build system which i use to build Flightgear.<br />
*Harrier-GR3 autohover: https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Harrier-GR3/<br />
*Flightgear on [http://www.openbsd.org OpenBSD].</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=ExtraViewWindows&diff=136952ExtraViewWindows2023-01-02T12:33:27Z<p>Cgdae: Added example screenshot.</p>
<hr />
<div>[[File:Fg-cv-textures2.jpeg|thumb|Multiple top level windows in CompositeViewer]]<br />
<br />
== Overview ==<br />
<br />
On next, there's support for Extra View windows. These are top-level windows that show views independently from the main window's view. These use a new view system called '''Sview''' (short for "Step View") along with [[CompositeViewer Support]].<br />
<br />
The simplest way to create an extra view window is from menu '''View/Add Clone View''' which, as the name implies, will create a new window that is a clone of the current view. Changing the main window's view will leave the new window's view unchanged.<br />
<br />
== Viewing pairs of aircraft ==<br />
<br />
There is a slightly crude mechanism for creating views that work on pairs of aircraft: one uses menu '''View/Push Pair View''' to push the current main-window view onto a stack of views.<br />
<br />
Once this has been done at two or more times, menu '''View/Add Pair View''' will open a new top-level window showing a view derived from the last two remembered viewpoints. So for example it can show the view of your aircraft from a particular multiplayer aircraft, or a view of the nearest tower from your aircraft.<br />
<br />
Menu '''View/Add Pair Foreground View''' is similar but it keeps the first viewpoint at a fixed distance in the foreground and the second viewpoint in the background. This works well when flying in formation.<br />
<br />
== Limitations ==<br />
<br />
As of '''2021-10-25''':<br />
<br />
* Extra View windows can be panned like the main window by dragging with the left mouse button.<br />
* Other UI interations is not supported:<br />
** Mouse clicks are ignord.<br />
** Key presses are ignored.<br />
<br />
== Specifying views in more detail ==<br />
<br />
One can specify views explicitly with the <code>view-new</code> command, which accepts an Sview specification in the form of an accompanying XML tree.<br />
<br />
For details of the XML format, see the comments in: {{flightgear file|src/Viewer/sview.hxx}}<br />
<br />
== How Sview works ==<br />
<br />
Sview works by constructing camera's eye and target positions/directions using an arbitrary number of individual configurable steps. There are various step types defined which allow for various transformations such as moving to a particular user/multiplayer aircraft or nearest tower, move relative to the current position+direction, modify heading, pitch and roll according to particular property values, rotate view direction to point at a particular target etc.<br />
<br />
These basic steps are enough to allow Sview to copy what conventional views do, allowing the '''View/Add clone view''' menu item to work.<br />
<br />
It's also easy enough to add (C++) code to implement new steps to achieve more sophisticated behaviour. An example of this is the view step called '''double''' that keeps two aircraft visible at all times, with one in the foreground; this is used for '''View/Add Pair Foreground View'''.<br />
<br />
For more details, see the C++ Sview code itself: {{flightgear file|src/Viewer/sview.cxx}}</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=StepView&diff=136951StepView2023-01-02T12:24:19Z<p>Cgdae: Link to ExtraViewWindows as main article.</p>
<hr />
<div>{{Main article|ExtraViewWindows}}<br />
<br />
If you're able to run a build from next and run with <code>--composite-viewer=1</code>, there's support for extra view windows which can provide a top-level window showing exterior aircraft views independently from the main window's view.<br />
<br />
One can configure such a view via XML with the view-clone command - see: $FG_SRC/Viewer/sview.hxx and it's used by fgdata/gui/menubar.xml. Or simply clone the current view using the View menu.<br />
<br />
At some point in the future we'll have Canvas views which will allow such views to appear within the main view, e.g. as an emulated CRT/LCD screen.<ref>https://forum.flightgear.org/viewtopic.php?f=87&t=35076&start=1065#p383455</ref><br />
<br />
== What is it == <br />
"Step View" - because it constructs eye and target positions/directions in a series of explicit configurable steps.<br />
<br />
{{flightgear file|src/Viewer/sview.cxx}}) already knows how to parse some of the standard XML view specifications, so that it can clone views.<br />
<br />
<br />
Extra view windows use a new view system called Sview which is short for 'step view', where one configures an arbitrary number of individual steps that end up defining the camera position and orientation. There are a number of different step types defined which allow for various transformations such as moving to a particular user/multiplayer aircraft or nearest tower, move relative to the current position+direction, modify heading, pitch and roll according to particular property values, rotate view direction to point at a particular target etc. One can specify the exact desired sequence of steps by passing XML to the view-new command see <br />
{{Flightgear file|src/Viewer/sview.hxx}} for details.<br />
<br />
These basic steps are enough to allow Sview to copy what conventional views do, allowing the 'Add clone view' menu item to work - this opens a new window with a copy of the current view, which is then independent of the main window's view.<br />
<br />
It's easy enough to add (C++) code to implement new steps, including more sophisticated things. For example there is a view step that keeps two aircraft visible at all times, with one in the foreground. See [[CompositeViewer Support]] for details and demonstration videos.<br />
<br />
It might be interesting to try to define the Shuttle RMS arm view as an Sview in its own top-level window. Apart from anything else Jules would like to make sure that Sview supports whatever requires; He'd imagine that we would have one Sview step for each hinge/link in the arm for example, and this might need a new Sview step type.<br />
<br />
It would also be a useful incentive to getting Canvas views working.<ref>https://forum.flightgear.org/viewtopic.php?f=87&t=35076&p=383610#p383610</ref><br />
<br />
== Internals ==<br />
we could make things into a top-level<br />
subsystem. Though Sview is not the default view subsystem and so in<br />
some ways it's nice to keep it under control of the main view subsystem.<br />
<br />
However before we get too far down into these details... the code in<br />
src/Viewer/sview.* currently mixes two things that it might be good to<br />
split up first. First there's the step view system itself which manages<br />
eye and target positions/directions, and second we have the creation and<br />
management of extra view windows (and potentially [[Canvas View Camera Element|canvas elements]])<br />
with their own graphics context and [[Compositor]] instance etc.<br />
<br />
The reason they are bundled together at the moment is that splitting<br />
them up might require that we expose some of the details of how step<br />
views are created, which is necessarily a little involved - see the<br />
various base and derived classes such as SviewStep and derived classes<br />
such as SviewStepMove, SviewStepNearestTower etc.<br />
<br />
Whether or not we can keep the details hidden, might depend ultimately<br />
on the UI for creating views that we want to present to the user.<ref>https://sourceforge.net/p/flightgear/mailman/message/37163870/</ref><br />
<br />
== References ==<br />
{{Appendix}}</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=CompositeViewer_support&diff=136950CompositeViewer support2023-01-02T12:19:27Z<p>Cgdae: /* General information */</p>
<hr />
<div><!--<br />
{{Affected by Compositor}}<br />
--><br />
<br />
{{infobox subsystem<br />
|image = Fg-cv-textures2.jpeg|Demonstration of multiple view windows in flightgear<br />
|name = CompositeViewer<br />
|started = 2020 July<br />
|description = Support for multiple independent scene views<br />
|status = * <span style="background:#ff0000 ">Aggressive OSG threading interfering with [[Canvas Path]] (race condition)</span><br />
* enabled by default on next <ref>https://sourceforge.net/p/flightgear/mailman/message/37330071/</ref><br />
* Merged into next 2020 Nov <ref>https://sourceforge.net/p/flightgear/mailman/message/37158652/</ref><br />
|developers = [[User:Cgdae|Julian Smith]]<br />
}}<br />
<br />
<br />
{{Rendering}}<br />
<br />
<br />
== Motivation ==<br />
[[File:CompositeViewer 3 cloned views and OSG stats with draw masks.png|thumb|Experimental [[CompositeViewer Support]] showing 3 cloned views, with [[Draw masks]] set (only skydome shown) + OSG stats (~ 120 fps/window) while using [[Howto:Activate multi core and multi GPU support|CullThreadPerCameraDrawThreadPerContext]] <ref>https://forum.flightgear.org/viewtopic.php?f=6&t=38334</ref>]]<br />
<br />
Until mid-2020, FlightGear only supported one view position at a time.<ref>http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg28864.html</ref>.<br />
<br />
Aircraft could define their own views and so on. But only one view could be active at a time. So no matter how many windows and cameras you defined in [[Defaults.xml]], they were all relative to the current view in FG (i.e. cockpit, tower...). <ref>http://forum.flightgear.org/viewtopic.php?p=146136#p146136</ref> <br />
<br />
Back in 2008, Tim Moore provided a patch ({{Search|keywords=CameraGroup|mode=mailing lists}}) to use the osgViewer class to [[Howto:Configure camera view windows|set up windows, manage the main camera]], etc. <ref>https://sourceforge.net/p/flightgear/mailman/message/19718339/</ref> <br />
<br />
However, these windows had to use the same camera group as the main window so could only show the view from the same eye position, though typically at a different angle/offset so that one could emulate things like side windows of a cockpit displayed in a different window or monitor.<ref>https://sourceforge.net/p/flightgear/mailman/message/37059117/</ref><br />
<br />
<!--<br />
There is some tight coupling between the Renderer.cxx and CameraGroup files (now to be found in SimGear<ref>v</ref>) The camera-infos can be configured from XML, eg to additional post-processing stages, but within each CameraInfo the actual osg::Cameras (each of which is really a rendering pass/stage) is determined by one of the buildXXXXX methods.<ref>https://sourceforge.net/p/flightgear/mailman/message/35828189/</ref><br />
--><br />
<br />
Mathias Fröhlich used the slave camera feature of osgViewer to provide a "video wall"-style of multiple displays that was demonstrated at LinuxTag for years. Later on, Tim generalized this to support general monitor arrangements (like a panoramic arc) and general combinations of screens and graphics cards. <ref>https://sourceforge.net/p/flightgear/mailman/message/24811861/</ref><br />
<br />
The default OSG model is that slave cameras are different views off-set from a common viewpoint. This is easy to understand when considering a camera's view matrix, but not necessarily intuitive when thinking about the projection matrix. Because FG has its own view system we mostly treated the slaves as independent. It seems that most other uses of cameras during rendering -- for example, render to texture cameras for effects -- are best handled by slave cameras with independent views as well.<ref>https://sourceforge.net/p/flightgear/mailman/message/36295606/</ref><br />
<br />
People requiring multiple independent views on the same scenery, e.g. cockpit and tower view [...] these each need their own camera groups and so require OSG's CompositeViewer.<ref>https://sourceforge.net/p/flightgear/mailman/message/37059117/</ref><br />
<br />
And that was not really supported by the previous architecture, neither by the tile cache nor by osgViewer::Viewer. We needed to move to a CompositeViewer model, which supports several scene graphs, and rely completely on the OSG database paging machinery.<ref>http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg28869.html</ref><br />
<br />
That required a change in the previous FlightGear architecture to use a CompositeViewer instead of a single Viewer, but we were contemplating that anyway.<ref>http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17263.html</ref><br />
<br />
The cameras in a camera group don't need to render directly to the screen. They can render to a texture which can be used either in the scene, like in a video screen in the instrument panel, or for distortion correction in a projected or dome environment. <ref>http://sourceforge.net/p/flightgear/mailman/message/19718339/</ref><br />
<br />
Open Scene Graph supports a CompositeViewer object that supports rendering from several widely-separated viewpoints, complete with support for multiple terrain pager threads. We had to move to CompositeViewer to support simultaneous views from e.g., the tower, AI models, drones, etc.<ref>http://sourceforge.net/p/flightgear/mailman/message/19718339/</ref><br />
<br />
Neither of these were previously supported. We had to start using a different OSG class, CompositeViewer, to support multiple views from independent view points. Our terrain pager needed a complete overhaul to use the [[PagedLOD]] scheme of OSG, and the Flightgear [[View manager]] would need to be aware multiple active views.<ref>=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27134.html</ref><br />
<br />
== CompositeViewer ==<br />
<br />
CompositeViewer allows multiple independent views of the Flightgear scene, e.g. in independent top-level windows, which allows for multiple independent views from different locations, allowing each view to have separate scenery loaded, using its own scenery pager.<ref>https://sourceforge.net/p/flightgear/mailman/message/37325678/</ref><br />
<br />
This is primarily needed/useful when views may need acccess to scenery (tiles) that are no longer in the cache of the main aircraft, for instance a tower view of the destination airport, or payload-specific views (think missiles) that may be out of range, and thus need their own scenery DB pager. In other words, CompositeViewer (CV) support is needed whenever a view can no longer be easily defined/described as a "child view" of the main aircraft. <br />
<br />
Previously, we were using the View(er) class which "is a" View, rather than "has a" View. The Viewer<br />
class is special case just for handling a single View and makes it<br />
easy as possible to just set up viewer with a single View of a single<br />
Scene. Slave Camera's can be used in conjunction with the View(er) in<br />
cases where the view is made up of separate windows or rendering<br />
effects that all contribute towards provided the view in intended.<br />
Think of a car simulator where you have a monitor for the windscreen,<br />
and a left and right monitor for the left and right door windows -<br />
you'd have three windows that are are controlled by a single master<br />
view direction, with each one just offset from this direction, each<br />
window maps to a GraphicsWindow. <br />
<br />
The CompositeViewer is a more complex and more flexible class that "has a" list of View(s). Each View can have it's own unique Scene or<br />
share a Scene. Each View can be composed of a single master Camera or from a set of slave Cameras as above. Multiple Views are useful when<br />
you have independent views of scene such as 3D view and a map view insert where the scene is the same but the camera that controls the<br />
view direction can be moved independantly. Alternatively you can independent Scenes in each View, or mix and match to your hearts<br />
content. <ref>https://groups.google.com/g/osg-users/c/YFYyWhr7oZo/m/7u_ZxpMkOgYJ</ref><br />
<br />
=== Status updates ===<br />
* 2021-08-27: Fernando has begun working on moving Canvas cameras out of the scene graph into dedicated PRERENDER cams ([[Post_FlightGear_2020.2_LTS_changes#Canvas|This was a long-standing issue where Canvas cameras were rendered multiple times]], once per slave camera. In the case of the Classic pipeline they were being rendered twice.), see:<br />
** {{flightgear commit|83b0a3}}<br />
** {{simgear commit|a97e14}}<br />
* 2021-08-13: Flickering (and eventually crashing) of Canvas avionics/displays (textures) in conjunction with CompositeViewer use seems related to using some of the more sophisticated OSG threading modes in combination with vector graphics (based on Shiva via [[Canvas Path]] elements) that are lacking serialization, which shows up when OSG tries to render frames concurrently.<ref>https://forum.flightgear.org/viewtopic.php?f=4&t=39475&p=390829#p390828</ref>, for now please use single-threaded mode only because Shiva cannot be considered thread-safe, i.e. needs explicit serialization in conjunction with OSG threading <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=39535&start=15#p390395</ref><br />
* 2021-08-06: Various improvements to extra views - see: {{flightgear commit|7ed93e4e64d}}<br />
* 2021-08-03: Jules pushed a change to fgdata on next to default to CompositeViewer (by setting <code>--prop:/sim/rendering/composite-viewer-enabled=1</code>). It can be turned off with command-line option <code>--composite-viewer=0</code>.<ref>https://sourceforge.net/p/flightgear/mailman/message/37330071/</ref><br />
* 2021-05-14: Fernando committed a preliminary fix for the [[OSGText Issues|osgText issue]] which might mean that it will be possible to switch to OSG 3.6 soon'ish, i.e. once we have gathered sufficient feedback <ref>https://sourceforge.net/p/flightgear/mailman/message/37282835/</ref><br />
* 2021-2-8:<br />
** Pan extra view windows in response to mouse left button drag. Unlike main view, panning is scaled by fov/windowsize, so easy to control even at high zoom levels.<br />
** Support Tower View AGL in extra view windows.<br />
** Added damping to chase views in extra view windows.<br />
** Possible fix for crash on reset with composite viewer.<br />
<br />
* 2020-12-12: One can now [https://sourceforge.net/p/flightgear/mailman/message/37174948/ configure extra view windows using properties].<br />
<br />
* 2020-11-21: Merged into next: {{flightgear commit|f62e5b9ce3462758b48f4c711eb7c3bf4bcc7061|CompositeViewer:Support for multiple view windows using osgViewer::CompositeViewer}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37158652/</ref><br />
<br />
* 2020-11-16: Some [[Hackathon_Proposal:_CompositeViewer_and_Canvas|progress on Canvas Views]] was made at the Hackathon.<br />
<br />
* 2020-10-5: Issues with window resize/close appear to be bugs in OpenSceneGraph-3.4, and are fixed by building with OpenSceneGraph-3.6.<br />
<br />
* 2020-9-27: Extra view windows now show textures and clouds etc, and rendering appears to be identical to the main view. This works by creating a new Compositor instance for each extra view window, and calling its '''update()''' method each frame.<br />
<br />
=== General information ===<br />
* Use of CompositeViewer is enabled at runtime with: '''--composite-viewer=1'''<br />
* Video showing extra view windows and initial implementation of Canvas View: [http://op59.net/cvcanvas-demo.ogv cvcanvas-demo.ogv]<br />
* When enabled, CompositeViewer requires OpenSceneGraph-3.6 to work well.<br />
* For more details see: [[ExtraViewWindows]]<br />
* CompositeViewer support will allow us to render a view to a canvas and implement things like rear-view mirrors etc - see: [[Canvas_View_Camera_Element]].<br />
<br />
=== Problems ===<br />
* for the time being, use of reset/re-init and aggressive OSG threading options seems to cause stability problems even without having cloned any views <ref>https://forum.flightgear.org/viewtopic.php?f=6&t=38334</ref><br />
* the [[PUI]] based fps/frame spacing counter implemented in $FG_ROOT/Nasal/gui.nas could probably be replaced by a Canvas implementation rendering to the [[Canvas_Snippets#Accessing_the_Canvas_Desktop|Canvas desktop]] using the [[Tooltips]] backend <ref>https://sourceforge.net/p/flightgear/mailman/message/37170351/</ref><br />
* for some people there seem to be [[Compositor]] related event handling regressions which we should keep track of once we begin supporting events per view <ref>https://sourceforge.net/p/flightgear/mailman/message/37170307/</ref><br />
<br />
=== Current limitations ===<br />
[[File:No-canvas-flickering-in-cv-mode.png|thumb|checking if the issue disappears without using the integrated UI, would also go a long way, because then we know whether it's related to the creation of the OpenGL context by Qt5.<ref>https://forum.flightgear.org/viewtopic.php?f=71&t=39535&p=390514#p390514</ref>]]<br />
[[File:Canvas-mapstructure-in-cv-mode.png|thumb|Canvas MapStructure map shown in a CompositeViewer enabled fgfs build, without any flickering/issues (and without crashing), Qt5 integration disabled.<ref>https://forum.flightgear.org/viewtopic.php?f=71&t=39535&p=390514#p390514</ref>]]<br />
[[File:CullThreadPerContext-Canvas-CV.png|thumb|CullThreadPerContext]]<br />
[[File:DrawThreadPerContext-Canvas-and-CV.png|thumb|--aircraft=ufo --prop:/sim/rendering/multithreading-mode=AutomaticSelection --composite-viewer=1]]<br />
<br />
* for the time being, Canvas based features using [[Canvas Path]] (shiva) <ref>https://forum.flightgear.org/viewtopic.php?f=71&p=390529#p390529</ref> (MFDs/avionics) won't play nicely with CompositeViewer in multi-threaded mode <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=39535&start=15#p390395</ref> <ref>https://sourceforge.net/p/flightgear/mailman/message/37333457/</ref> A [https://forum.flightgear.org/viewtopic.php?f=4&t=39475&start=60#p390949 patch shared on the forum] to add explicit synchronization using a lock/mutex<ref>https://forum.flightgear.org/viewtopic.php?f=4&t=39475&p=391021#p390955</ref>, seems to solve the problem for a number of users<ref>https://forum.flightgear.org/viewtopic.php?f=4&t=39475&p=391019#p391013</ref> Specifically, people reported:<br />
** The canvas displays are flickering when compositeviewer is at play...enabling CV support completely breaks canvases: https://seafile.merspieler.tk/f/defeb82cbabf40198169/?dl=1 <ref>https://sourceforge.net/p/flightgear/mailman/message/37330784/</ref><br />
** Even after closing the compositeviewer window some canvases stay broken. <ref>https://sourceforge.net/p/flightgear/mailman/message/37331381/</ref><br />
** The Canvas glass panels flicker [...]It happens only in multi-display mode with threading enabled: https://www.youtube.com/watch?v=byU0dv7bjHg <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=39535&p=390359#p390350</ref><br />
* we cannot currently move/use any PUI/Canvas UI in separate windows<br />
* users have been reporting a delay/freeze when cloning views <ref>https://sourceforge.net/p/flightgear/mailman/message/37161269/</ref><br />
* Extra view windows don't have keyboard handling, so for example one cannot zoom with x/X.<br />
* Sview does not currently support Fly-past view.<br />
<br />
=== Code ===<br />
<br />
Latest code can be found on the 'next' branch of flightgear, simgear and fgdata. As of 08/2021, CompositeViewer support is enabled by default on next.<br />
<br />
=== Testing ===<br />
{{Caution|For the time being, it's recommended to explicitly enable single-threaded mode when using CompositeViewer in conjunction with Canvas related features<ref>https://sourceforge.net/p/flightgear/mailman/message/37335562/</ref><ref>https://forum.flightgear.org/viewtopic.php?f=71&t=39535&start=15#p390395</ref>}}<br />
You can try using several windows on the camera group to test, no need to use several monitors. Here is the test setup Fernando is using, just two 800x600 windows <ref>https://sourceforge.net/p/flightgear/mailman/message/37330229/</ref>: https://pastebin.com/5HVsre8G<br />
<br />
<syntaxhighlight lang="xml"><?xml version="1.0"?><br />
<PropertyList><br />
<sim><br />
<rendering><br />
<camera-group><br />
<window><br />
<name type="string">main</name><br />
<host-name type="string"></host-name><br />
<display>1</display><br />
<screen>0</screen><br />
<x>0</x><br />
<y>0</y><br />
<width>800</width><br />
<height>600</height><br />
<decoration type = "bool">true</decoration><br />
<fullscreen type = "bool">false</fullscreen><br />
</window><br />
<window><br />
<name type="string">secondary</name><br />
<host-name type="string"></host-name><br />
<display>1</display><br />
<screen>0</screen><br />
<x>800</x><br />
<y>0</y><br />
<width>800</width><br />
<height>600</height><br />
<decoration type = "bool">true</decoration><br />
<fullscreen type = "bool">false</fullscreen><br />
</window><br />
<camera><br />
<name type="string">middlecamera</name><br />
<window><br />
<name>main</name><br />
</window><br />
<view><br />
<heading-deg type="double">45.0</heading-deg><br />
</view><br />
<frustum><br />
<top>0.133</top><br />
<bottom>-0.133</bottom><br />
<left>-.1668</left><br />
<right>.1668</right><br />
<near>0.4</near><br />
<far>120000.0</far><br />
</frustum><br />
</camera><br />
<camera><br />
<name type="string">leftcamera</name><br />
<window><br />
<name>secondary</name><br />
</window><br />
<view><br />
<heading-deg type="double">0.0</heading-deg><br />
</view><br />
<frustum><br />
<top>0.133</top><br />
<bottom>-0.133</bottom><br />
<left>-.1668</left><br />
<right>.1668</right><br />
<near>0.4</near><br />
<far>120000.0</far><br />
</frustum><br />
</camera><br />
<gui><br />
<window><br />
<name type="string">main</name><br />
</window><br />
</gui><br />
</camera-group><br />
</rendering><br />
</sim><br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
== Background ==<br />
<!--<br />
{{WIP}}<br />
--><br />
The natural way to manage an application that has two views on to two different scenes is to use a osgViewer::View for each separate scene, and then an osgViewer::CompositeViewer to manage these two scenes. These two views can share the same GraphicsWindow, or have their own. They may even be added/removed from the CompositeViewer, or have their rendering toggled on/off via NodeMask's on the master Camera for each View.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg24466.html</ref><br />
<br />
The Viewer class is the simplist for of viewer and<br />
inherits from osgViewer::View, so has a single master Camera, and 0 or<br />
more slave Camera. While the CompositeViewer class contains a list of<br />
osgViewer::View, again each of these View has a single master Camera,<br />
and 0 or more slave Camera.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg51806.html</ref><br />
<br />
The osgViewer:::CompositeViewer/Viewer architecture is designed to<br />
support one frame loop driving all the windows associated with that<br />
viewer, not multiple places trying to dispatch frame(). So you use a<br />
single timer. Or use multiple viewers.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg19095.html</ref><br />
<br />
* As a general approach, if you want multiple View's which have their own or share Scene's then the appropriate class to use is CompositeViewer as it's written specifically for this purpose.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg70958.html</ref><br />
* The usual way to manage multiple window views of a single scene graph is to use a CompositeViewer with multiple View's each view using its own or sharing a graphics window. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg61172.html</ref><br />
* What CompositeViewer provides is not so much performance improvement across the board, but rather far better granularity of design.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg01391.html</ref><br />
* The CompositeViewer and Viewer should have exactly the same performance characteristics w.r.t managing multiple cameras - as it's exactly the same ViewerBase code underneath that is managing all the threading and graphics rendering.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg22273.html</ref><br />
* CompositeViewer and Viewer share much of their implementation, the only key difference is that Viewer "is a" View, while CompositeViewer has a list of Views. All the event handling, camera manipulator and scene graph setting is done a the View level so has identical API to access. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg17372.html</ref><br />
=== Views ===<br />
The OSG is designed to allow you to rendering multiple views at once,<br />
there is no need to clone the scene graph, you simply add another View<br />
to a CompositeView to add the extra rendering. You can toggle<br />
optional View's on/off as you need them. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg78130.html</ref><br />
<br />
<br />
For example, you could have a working set of View's that share the scene graph, and share<br />
the same graphics context. All these Views would be added to the<br />
CompositeViewer. At start up these View's would be disabled by setting their<br />
View Camera's NodeMask to 0x0.<br />
<br />
When you need to render a View for a client you'd enable a View of one is<br />
attached and not enabled, enable by setting the Camera's NodeMask to<br />
0xffffffff. If you run out of View then simply create a new one for the<br />
purpose. Potentially you could do this on demand - so have none at start<br />
up.<br />
<br />
When you no longer need a View you could remove it, but it's lighter to<br />
just disable it via the NodeMask trick.<br />
<br />
With this approach you aren't creating/deleting graphics contexts, will<br />
lower memory usage and you'll get better performance.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg63061.html</ref><br />
<br />
Note: the slave osg::Camera aren't direct children of the View's<br />
master osg::Camera, but they have their view and projection matrices<br />
updated from the master camera.<br />
<br />
Note II: osgViewer only threads Camera that are in the viewer, not<br />
ones enclosed in the scene graph, so your Camera in Camera won't<br />
thread.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg11636.html</ref><br />
<br />
* The right way to remove a view is outside of frame(). Not from an event handler from within the view, this will crash as you'll be deleting the object you are doing the work from.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg35639.html</ref><br />
* If you want to keep the view around for future use then perhaps the easiest way to do it would be to disable the View's camera by setting its NodeMask to 0x0 i.e. view->getCamera()->setNodeMask(0x0); <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg03518.html</ref><br />
<br />
In terms of closing a View, does this View have it's own<br />
GraphicsWindow(s)? If not then just setting the View's Camera's<br />
NodeMask to 0 will switch if off and set it to 0xffffffff to switch it<br />
back on again. If the View does have it's own GraphicsWindow then<br />
you'll need to close the window and switch off the rendering via the<br />
NodeMask [...]<br />
The other approach is to simply removing the View from the<br />
CompositeView and add back in a new one when you need it. The<br />
NodeMask route is lightest weight route though and is what I'd do if<br />
it's possible. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg47608.html</ref><br />
<br />
=== DatabasePager === <br />
{{See also|Howto:Using additional OSG Pager Threads}}<br />
<br />
The OSG has the osgDB::DatabasePager which sole purpose is to do<br />
multi-threaded paging of databases. The osgViewer::Viewer and<br />
CompositeViewer both support it out of the box, as did<br />
osgProducer::Viewer before it. There is nothing you need to do in<br />
your app other than load a paged database. Paged dabases in the OSG<br />
are ones that contain osg::PagedLOD node or loaded via the TXP plugin.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg01750.html</ref><br />
<br />
<br />
* osgViewer is set up so that the Scene object manages the scene graph and the database pager assocaited with that scene graph. There is one Scene object per scene graph, and multiple views should share the same Scene instance if there share the same scene graph. Virtue of this sharing the Scene shouldn't go out of scope while at lest on View still references, and neither should its associated DatabasePager go out of scope either.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg04006.html</ref><br />
* osgViewer::Viewer/CompositeViewer all have the DatabasePager built into them, and will automatically run the database pager thread on demand and take care of all the operations required to manage a paged database.<ref>https://groups.google.com/d/msg/osg-users/eMh8DfsKZhQ/F1V5BZS3hLEJ</ref><br />
* it might just be far more productive to use the OSG's built in database paging support. All you need to do is decorate your subgraphs with a osg::PagedLOD or osg::ProxyNode, with osg::PagedLOD being the method of choice as it'll do load balancing for you - both loading new tiles on demand and deleting ones that are no longer required, all automatically done by osgDB::DatabasePager/osgViewer. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg12365.html</ref><br />
* The OSG has an database paging class call osgDB::DatabasePager that is built into the osgViewer::Viewer/CompositeViewer that will automatically load databases and merge them with the main scene graph during the update traversal. This is built around the osg::PagedLOD class, but you can also use the osg::ProxyNode.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg68474.html</ref><br />
* Normally one should ever need to worry about constructing or destructing the DatabasePager, it should happen behinds the scenes managed by osgViewer. osgViewer::Scene is used internally by osgViewer to manage one DatabasePager per scene graph. The Scene object will be shared automatically between Views if you assign the same Node pointer then you call View::setSceneData. This sharing is done automatically for you. When a Scene object is destructed it's DatabasePager will be destructed if no other references to it exist. If you have multiple Views that you should be using CompositeViewer, not multiple Viewer. If you are creating and destroying views regularly then you are probably best to enable/disable them by setting the View's master Camera's NodeMask to 0x0 and back to 0xffffffff, as this will switch off rendering but keep the backend around ready to be re-enabled.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg63057.html</ref><br />
* osgViewer automatically shares a single DatabasePager between Views when the Views share the same scene graph. This is required to avoid inconsistencies in the scene graph causing errors. Sharing a single DatabasePager doesn't prevent that pager from handling multiple viewpoints at the same time, if fact it knows nothing about viewpoints, it only handles database requests for tiles, so it totally agnostic to how you manage your viewpoints. Everything should basically just work out of the box without any need for specific settings from yourself.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg34846.html</ref><br />
<br />
<br />
The existing DatabasePager functionality can page over the network,<br />
but this isn't an issue for the DatabasePager - its purely a function<br />
of the net plugin that does the loading across the http. This means<br />
paging and reading across the network are completely orthogonal and<br />
can be mixed and matched at will.<br />
<br />
<br />
The Viewers already have support for adding and remove subgraphs from<br />
the main scene graph via the DatabasePager. You needn't add your own<br />
code as long as the database is set in a way that utilises<br />
DatabasePager.<br />
<br />
You can write your own DatabasePager functionality, but it its likely<br />
to be alot less work just to use the built in paging support, this way<br />
the task for you is just how to build you database. Teaching you how<br />
to reimplement existing functionality really is way beyond the level<br />
of support I can provide for free.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg01766.html</ref><br />
<br />
=== Crashing ===<br />
SingleThreaded means that frame() doesn't return until the draw threads have<br />
completed. At that time, you are free to make any changes you want. In other<br />
threading models, the draw threads might still be active after frame() returns,<br />
but you are guaranteed that objects with dynamic data variance have been<br />
processed (only static or unspecified data variance is left for the draw threads<br />
to work on).<br />
<br />
The update NodeVisitor is for convenience only and isn't required for any<br />
modifications.<br />
<br />
If your instability (crash?) goes away in SingleThreaded mode, then the issue is<br />
either improper use of data variance, or you have a thread safety issue in one<br />
of your callbacks.<br />
If you are seeing a crash when running single threaded then<br />
DataVariance won't be an issue, you'll need to look elsewhere.<br />
Unfortunately there is too information about the exact problem you are<br />
seeing on your system to be able to guess at what the problem might<br />
be.<br />
<br />
A general note about DataVariance, in the OSG there are internal Nodes<br />
of the scene graph - such as Group, Transform, Geode etc, setting<br />
DataVariance on these is only a hint to code that might optimize the<br />
scene graph about what is safe to replace and change and what isn't,<br />
unless you are calling the osgUtil::Optimizer is pretty likely that<br />
setting DataVariance on Node in the scene graph will have no effect on<br />
the end result - as the update, cull and draw traversals all ignore<br />
the Node's DataVariance settings.<br />
<br />
The only time that DataVariance is used is when the viewer is run<br />
multi-threaded with the DrawThreadPerContext or<br />
CullThreadPerCameraDrawThreadPerContext threading models, and where<br />
it's only the draw traversal that uses the DataVariance, and the since<br />
the draw traversal has only references to Drawable and StateSet leaves<br />
on the scene graph it's only the DataVariance on these that is<br />
checked. This means the nodes and any sate attributes attached to<br />
StateSet are ignored.<ref>https://groups.google.com/g/osg-users/c/W4OFWPp9YJ8/m/poyUdg7_oBsJ</ref><br />
<br />
First try, CullDrawThreadPerContext thread model to see if that works safely. If it does then the issue is almost certainly down to some StateSet or Drawable in your scene graph that you are modifying the contents that don't have the DataVariance set to DYNAMIC.<ref>https://groups.google.com/g/osg-users/c/jgS0PqLcvtI/m/qlPPWXTNpzIJ</ref><br />
<br />
ou only need to set the Node DataVariance as a hint to the osgUtil::Optimizer that is typically only used after loading a new model, the Node DataVariance is not used during the update, event, cull or draw traversals.<br />
<br />
However, when using DrawThreadPerContext or CullThreadPerCameraDrawThreadPerContext threading models the StateSet and Drawable DataVariance is used to prevent dynamic leaves of the scene graph being updated and rendered at the same time - the draw traversal holds back the main thread till all the dynamic objects have been dispatched.<ref>https://groups.google.com/g/osg-users/c/nH-73NNFw4A/m/Y4Qfdu4-XAIJ</ref><br />
<br />
When running in DrawThreadPerContext or CullThreadPerCameraDrawThreadPerContext threading models, these threading models use the DataVariance of StateSet and Drawable to decide when it's safe to let the next frame advance. <br />
<br />
It's only the contents of StateSet and Drawables that your need to mark as DYNAMIC if their contents are changing. If only their ownership is changing they you'd don't need to set them to DYNAMIC, even if you remove the StateSet or Drawable from the scene graph it's still safe as the rendering back end takes a reference to StateSet and Drawables that it's about to render.<br />
<br />
Node do not need to be set to DYNAMIC for the purposes of update, event, cull and draw traveresals. The only part of the OSG that checks the DataVariance of Nodes is the osgUtil::Optimizer. <ref>https://groups.google.com/g/osg-users/c/YMl1VfweIxQ/m/JGTB3hOlqDIJ</ref><br />
<br />
Changing the scene graph during event traversal shouldn't be a problem<br />
and shouldn't require you do set the Drawable and StateSet to DYNAMIC<br />
unless you are modifying the contents of these objects. The only area<br />
that might be worth looking at is if the draw traversal is access the<br />
parent lists of the Drawable and/or StateSet while these are being<br />
modified by the event traversal.<ref>https://groups.google.com/g/osg-users/c/lDoIMXxIH7U/m/wUi-g79Zn3cJ</ref><br />
<br />
=== Data Variance ===<br />
<br />
The OSG is built for multi-threading of osgViewer View's in various ways, it's not general multi-threading support, it's designed specifically for a scene graph so overheads for that multi-threading to a minimum. <br />
<br />
The multi-threading that osgViewer provides is managed by osgViewer itself so it can marshal all the tasks and synchronization correctly. <ref>https://groups.google.com/g/osg-users/c/bDexX-g2Cag/m/Oj9V4hyuAQAJ</ref><br />
<br />
OpenGL only supports thread per context, so each context can only be driven by a single thread at any time, The OSG's viewer threading is built around this constraint.<br />
Principally the rendering threads (cull and draw) don't write to the scene graph, they just read from it. There are a limited number of exceptions where nodes are view dependent and cache state within the node. This means it should be safe to run an intersection traversal at the same time as the viewer.renderingTraversals() is running.<br />
<br />
The OSG by default will use separate OpenGL objects and associated buffers for each graphics context. If you enable sharing of GL objects between contexts then you'll need to run the application single theaded to avoid these shared GL objects and associated buffers being contend.<br />
<br />
You can't use DrawThreadPerContext when sharing contexts except when your scene graph uses no OpenGL objects whatsoever. So no display lists, no VBO's, no textures etc. Basically if you want shared contexts you have to use it SingleThread so the different threads don't contend with the same resources.<ref>https://groups.google.com/g/osg-users/c/vtWa-YNQEAY/m/ykNHgbIOD4UJ</ref><br />
<br />
n the most general and conservative sense, you should set dynamic data variance<br />
on anything you need to change.<br />
<br />
But in reality, you only need to do this for objects that are referenced by the<br />
draw list / render graph. Unfortunately, there is no (header file doxygen)<br />
documentation that tells you what goes in the render graph and what doesn't. So<br />
you can either take the conservative approach, or you can dig into the source to<br />
determine whether you can get away with not marking something dynamic, even<br />
though you know you're going to modify it.<br />
<br />
For me, this boils down to a 5 second code change (to mark it dynamic) versus<br />
possibly hours of digging into the code. So I usually take the conservative<br />
approach.<br />
<br />
Specifically regarding MatrixTransform, marking it as dynamic (as I did in the<br />
Quick Start Guide) isn't necessary, as OSG's render graph is composed of copies<br />
/ concatenations of the matrix itself, and doesn't hold references to the<br />
MatrixTransform node per se.<br />
<br />
Note also that data variance is used by the osgUtil::Optimizer. Other code in<br />
OSG might also reference data variance for various purposes.<br />
<br />
The DataVariance property of osg::Object is used in couple of ways.<br />
For internal nodes of the scene it is used as a hint to operations<br />
such as the osgUtil::Optimizer that parts of the scene graph are<br />
static or dynamic and to use this information as guide to what can be<br />
optimized and in what ways - generally it means leaving DYNAMIC nodes<br />
alone. The DataVariance property on Nodes isn't used during the<br />
update, cull and draw traversals so it's effectively ignored.<br />
<br />
For the leaves of the scene graph - the osg::StateSet and<br />
osg::Drawable (and it's subclasses), the DataVariance is only used<br />
when using the DrawThreadPerContext and<br />
CullThreadPerCameraDrawThreadPerContext threading models and is used<br />
during the draw traversal to prevent the next frame from commensing<br />
till all DYNAMIC StateSet and Drawables are dispatch. For<br />
SingleThreaded and CullDrawThreadPerContext threading models the<br />
DataVariance is not used as the next frame doesn't commence till the<br />
whole draw dispatch is completed.<br />
<br />
The DataVariance of the StateAttribute subclasses is not used in<br />
update, cull or draw traversals, and like nodes is only used be<br />
specialist traversals like some of the ones contained in the<br />
Optimizer. So if you want to dynamic update a Uniform then the way to<br />
make sure that draw doesn't overlap the update of it is to set the<br />
DataVariance of the StateSet that enclose it to DYNAMIC. There isn't<br />
an automatic scheme to check the DataVariance of StateAttributes as it<br />
would be prohibitively expensive to do during the draw traversal.<ref>https://groups.google.com/g/osg-users/c/Lo98dBo07Pg/m/eqSsfES7hGcJ</ref><br />
<br />
<br />
<br />
In all the OSG 2.x series the DataVariance is used during the draw<br />
traversal to monitor when all DYNAMIC StateSet and Drawables have been<br />
dispatched, as once they have been the next frame can be started in a<br />
parallel with the remaining STATIC objects are rendered (in<br />
DrawThreadPerContex, CullThreadPerCameraDrawThreadPerContext threading<br />
models.)<br />
<br />
The rule of thumb is that the Data Variance should be set to DYNAMIC on instances that change once that have been added to the Scenegraph. The short reason why is that this allows the Cull and draw threads to correctly handle and stage any changes that may be made in the app threads to the instances <br />
<ref>https://groups.google.com/g/osg-users/c/jgS0PqLcvtI/m/qlPPWXTNpzIJ</ref><br />
<br />
<br />
With the DrawThreadPerContext and DrawThreadPerContextCullThreadPerCamera threading models the static part of the rendering can be done in parallel with the next frame. You guess this correct.<br />
<br />
The one thing I'd add is that the OSG itself doesn't attempt to sort DYNAMIC objects so that are drawn first. You can set up your StateSet::RenderBinDetails to force the dynamic objects to be drawn first, but you can only do this for objects that don't affect the rendering of other objects, or are affected by what is the fame buffer already. <br />
<br />
<br />
StateSets and Drawables must be marked as DYNAMIC is you plan to change them. That's because they are used by the rendering stage, which can overlap the next frame's update.<br />
<br />
Everything else (scene graph structure, etc.) is safe to change during the Update traversal/callbacks.<ref>https://groups.google.com/g/osg-users/c/j2_2vCDFdTw/m/oasQIb7HCgAJ</ref><br />
<br />
=== Threading ===<br />
{{See also|Multi-Threading in FlightGear}}<br />
<br />
In single threaded mode, you can safely have a single threaded viewer and still have the DatabasePager working with multi-threading in the background.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg61170.html</ref><br />
<br />
As a general note, there isn't a big difference between single<br />
threaded and multithread usage of the OSG in terms of OpenGL dispatch,<br />
with two separate windows there should be two separate graphics<br />
contexts and it should make no difference if you drive these from one<br />
thread one two, the state for each context should be kept local to<br />
each one.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg03788.html</ref><br />
<br />
running multiple windows multi-threaded will give you the<br />
best performance, the OSG is designed for this usage model, and most<br />
easily set up using the native windowing support that the OSG<br />
provides.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg16632.html</ref><br />
<br />
As long as your run the viewer multithreaded the OSG will use a<br />
barrier so that each graphics thread waits at the end of draw<br />
dispatch, then once all the threads join this barrier then all move on<br />
together and then call swap buffers. This is done to try and achieve<br />
synchronized swapping, however, it's not a full proof scheme as it<br />
doesn't use any low level driver and hardware synchronization.<br />
<br />
Extensions to some OpenGL drivers exist to enable the low level<br />
synchronisation, such as swap groups, swap ready and gen lock.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg54571.html</ref><br />
<br />
<br />
* osgViewer::CompositeViewer is designed for applications that have multiple Views. The only thing to be careful of is when you are adding and removing View's from the CompositeViewer you should do is calling stopThreading() on the viewer prior to adding or removing views, then call startThreading() afterwards. If you are running SingleThreaded or CullDrawThreadPerContext you won't need to worry about stop and starting threads.<ref>https://groups.google.com/d/msg/osg-users/7OojxLpBGdw/mzorZe3rKwEJ</ref><br />
* osgViewer::CompositeViewer runs all of the views synchronously - one frame() call dispatches update, event, cull and draw traversals for all the views. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg18308.html</ref><br />
* OpenGL doesn't support multi-threading within a single graphics context, so you are constrained to doing the rendering for each context in a single thread. The threading models that the OSG provides reflect this, enabling threading of the update, event and cull traversals in parallel with the draw thread. <ref>https://groups.google.com/d/msg/osg-users/iMJF1vp0U48/9RSD3DlPAAAJ<</ref><br />
* if any code executed by the cull or draw threads (such as your own callbacks or custom nodes) isn't thread safe, then you must use SingleThreaded. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg09620.html</ref><br />
* as long as you have two GPU's the most efficient way to drive them should be multi-threaded - there is a caveat though, hardware and drivers aren't always up to scratch, and even then they should be able to manage the multi-threads and multi-gpus seemless they fail too.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg18332.html</ref><br />
* Cull and draw can only run in a parallel once all the dynamic geometry has been dispatched, otherwise the draw will be dispatching data that is being modified by the next frames update and cull traversals. Perhaps you have some dynamic geometry or StateSet's that are holding back the next frame. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg36238.html</ref><br />
* if you are using a single graphics card for best performance one usually tries to use a single graphics window and have two cameras or more share this context.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg54512.html</ref><br />
<br />
The ThreadPerCamera is just shorthand for<br />
CullThreadPerCameraDrawThreadPerContext, which will explain a bit more<br />
what's actually happening - it's meant to allow the draw thread to<br />
progress in parallel with the next frame.<br />
<br />
<br />
There is a mechanism built into the backend to hold back the next<br />
frame if there are any Drawables or StateSet's with their DataVariance<br />
marked as DYNAMIC, however, if your whole scene is STATIC then this<br />
will allow the next frame to advance. There isn't any default<br />
additional mechanism for holding back the next frame. There are<br />
mechanisms for doing a swap ready check for multi-context systems <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg72040.html</ref><br />
<br />
As for general notes about threading, if you are working on the same<br />
graphics context as you are then all the draw dispatch and the draw<br />
GPU can only be done by a single graphics thread so there is little<br />
opportunity to make it more parallel without using another graphics<br />
card/graphics context and interleaving of frames.<br />
<br />
Cull and draw can only run in a parallel once all the dynamic geometry<br />
has been dispatched, otherwise the draw will be dispatching data that<br />
is being modified by the next frames update and cull traversals.<br />
Perhaps you have some dynamic geometry or StateSet's that are holding<br />
back the next frame.<ref>https://groups.google.com/g/osg-users/c/JY1mVGofOEg/m/8P7j5titqVcJ</ref><br />
<br />
There are limits with the time of threading you can do with cameras<br />
that share the same graphics context - the draw traversals has to be<br />
single threaded for each camera's rendering, this applies to FBO's as<br />
well as normal rendering to a graphics window.<br />
<br />
You should be able to still run multi-threaded if you have multiple<br />
graphics contexts, but the osgdistortion example just uses on graphics<br />
context, and multiple FBOs. <ref>https://groups.google.com/g/osg-users/c/RYEOlTMItbI/m/SQSrf0f5jXoJ</ref><br />
<br />
You can have a slave Camera in the Viewer that is used a prerendering<br />
camera or a Camera in the scene graph that is used a prerender camera.<br />
Cameras in the scene graph are treated almost exactly the same way as<br />
slave Camera, it's just high level things like threading and how the<br />
view and projection matrices are assigned per frame that differ. <ref>https://groups.google.com/g/osg-users/c/RNgKAZTCyN0/m/kGPsRpxLlWQJ</ref><br />
<br />
If you want to create and chain RenderStages then using an osg::Camera<br />
in the scene graph is often one of the best ways to do this, and use<br />
the Camera::setRenderOrder(..) to control the order. You can also use<br />
a custom cull traversal callback to create RenderStage/RenderBin and<br />
assign these to the rendering backend, but this does require a greater<br />
knowledge of the internals of the rendering backend.<ref>https://groups.google.com/g/osg-users/c/45_bw3QUELs/m/aXvWKsuKKgUJ</ref><br />
<br />
=== Scene Modification ===<br />
You should only update a stateset, drawable, or the scene graph structure from the update traversal, update callback, or update operation. Are you modifying anything at runtime?<br />
<br />
Outside of the Optimizer, DataVariance has no effect in SingleThreaded mode. It also has no effect on Nodes (only Drawables and StateSets). <br />
<br />
Modifying the scene graph outside of the frame call is safe in<br />
SingleThreader, and CullDrawThreadPerCamera threading models as they<br />
don't leave any threads active after the end of the<br />
renderingTraversals() method (called from frame()).<br />
<br />
With DrawThreadPerContext and CullThreadPerCamewraDrawThreadPerContext<br />
the draw threads will still be active on completion of the<br />
renderingTraversals(), so if you modifying drawables and state that<br />
the thread is still reading from in the draw traversal you will end up<br />
with problems - and potential crashes. There is a standard mechanism<br />
to deal with this issue - and that is the renderingTraversals() method<br />
to block till all dynamic objects in the draw traversals have been<br />
dispatched. The way you tell the draw traversal that an drawable or<br />
stateset will be modified dynamically is to set its data variance to<br />
DYNAMIC.<ref>https://groups.google.com/g/osg-users/c/xCW-Y721YiI/m/vuYJEx_jcAYJ</ref><br />
<br />
<code><br />
drawable->setDataVariance(osg::Object::DYNAMIC);<br />
stateset->setDataVariance(osg::Object::DYNAMIC); <br />
</code><br />
<br />
If you are modifying the stateset then you'll need<br />
to set its data variance to DYNAMIC. For a StateSet that decorates<br />
the whole scene graph you'll end you holding back the frame till the<br />
whole scene graph is completed, so it won't have any performance<br />
advantage over CullDrawThreadPerContext. You can double buffer<br />
objects to allow you to retain the STATIC data variance and keep the<br />
threads overlapping, to do this you do:<br />
<br />
<code><br />
osg::Camera* cam = getViewer()->getView(i)->getCamera();<br />
cam->setStateSet() = new StateSet; // this is where we just use a new<br />
StateSet rather than modify the previous one<br />
</code><br />
<br />
<code><br />
cam->getOrCreateStateSet()->setGlobalDefaults();<br />
... And some other changes ...<br />
</code><br />
<br />
The draw traversal takes a reference to the StateSet and Drawables so<br />
it's safe to go an remove them from the scene graph outside the<br />
frame() call, this isn't something makes then dynamic so you won't<br />
need to set their data variance to DYNAMIC.<br />
=== Sharing scenes ===<br />
The osgViewer has a mechanism for avoid multiple traversals of shared<br />
scene graphs if mutiple View's share the same root node of the scene<br />
graph. If shared component isn't the topmost node then the OSG has no<br />
straight forward way to know whether a subgraph has been traversed or<br />
not that frame. One could implement a mechanism to avoid this<br />
visiting a node multiple times in one frame but it would be really<br />
costly to do, an expense that would only be a benefit for a very small<br />
number of users, but would slow performance for everyone else.<br />
<br />
If you have a shared subgraph that you don't want traversed multiple<br />
times per frame then use an UpdateCallback that has a frameNumber<br />
member variable that keep track of the the frameNumber (use<br />
NodeVisitor::getFrameStamp()'s FrameNumber) of the last traversal,<br />
when a traversal calls the update callback you only traverse the<br />
subgraph if the frameNumber is different and then set the frameNumber<br />
to the present frame, if the frameNumber is the same then you just<br />
return immediately. This custom UpdateCallback you'd place as high as<br />
you can in your scene graph to make sure the traversal stops as soon<br />
as possible.<br />
<br />
Another approach is to move this frameNumber tracking into your<br />
existing update callbacks, and simple return right away with the<br />
frameNumber is the same. This requires a small tweak to the callbacks<br />
but is such a small change it's generally pretty easy to integrate.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg74476.html</ref><br />
* Each View has one scene graph, and can share its scene graph between other instances of View. The View can also share the same GraphicsWindow, or have its own GraphicsWindow. The View also has a master Camera, and an optional list of slave Camera so you can scale from simple views up to complete distortion correction or multiple display output setups. Each View has its own event handlers and cameras handlers. Its extremely flexible and configurable. <ref>https://groups.google.com/d/msg/osg-users/kmSNMm6w008/zBBunL-VRJsJ</ref><br />
* sharing a scene between View's is OK within one CompositeViewer as they will Views on the same scene will share the same FrameStamp i.e. there will be all at the same point in time. Sharing one scene between multiple Viewers will hit up against the problem that in one set of traversals the scene graph is one time and then the traversals from the other viewer will try to change the time back - and likely to cause a mess. This timing issue isn't likely to cause problems with high level rendering though - it should just mess up things like particle systems and sequences.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg07305.html</ref><br />
* When sharing a scene graph the osgViewer library automatically assigns an osgViewer::Scene for each unique scene graph, while sharing the Scene if you assign that scene graph to multiple View's. The Scene holds the DatabasePager for that scene graph so there isn't any overlap with multiple pagers trying to load stuff for the scene graph in an uncoordinated way.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg70958.html</ref><br />
* One way that could break this mechanism is sharing portions of the scene graph and assigning the subgraph to each View as the Scene won't pick up on the fact that it's the same overall scene graph. If you have this situationist then sharing the same complete scene graph and use a combination of NodeMask and TraversalMask for each View to make sure on the part you want visible in each View is seen.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg70958.html</ref><br />
* The best thing we could do would be to create a single GraphicsWindow and then share this between all our Views, we then won't have any problems with rendering order and sharing of textures or FBOs as it'll all be on one graphics context. See the sogcompositeviewer example for how to set up the Views/Camera & GraphicsWindow.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg16029.html</ref><br />
* Sharing a single window between multiple views is demonstated in the osgcompositeviewer example - you simply assign the same GraphicsWindow to the Camera's in each of the Views. You change views you can stop the viewer threads and then add/remove views you need then restart the threading, this will drop a few frames though due to stopping/start of threads. The other way is to switch off the rendering of the view by setting its Camera's NodeMask to 0x0 to disable it.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg18291.html</ref><br />
<br />
=== Context sharing ===<br />
The OSG allows you to create graphics context, make the context<br />
current and then dispatch rendering and do swap buffers yourself but<br />
this requires you to individually set everything up yourself.<br />
<br />
<br />
What osgViewer does is provide all the basic functionality that 99% of<br />
users need out of the box, including handling context creation,<br />
multiple contexts, handling of database threading, viewer threading,<br />
event handling etc. It makes what would be a complicated task<br />
trivial, but with encapsulating all this functionality it has to make<br />
some assumptions about the way it's used<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg36853.html</ref><br />
<br />
A sharing OpenGL contexts doesn't mean actually sharing of the<br />
context, its just sharing some data between contexts, so you don't<br />
have a "common OpenGL context", you have two separate OpenGL contexts<br />
that are sharing display lits/texture objects etc.<br />
<br />
Each GraphicsWindow "is a" GraphicsContext which maps directly to a<br />
single OpenGL graphics context. Each OpenGL graphics context has its<br />
own state machine which is mapped by a single osg::State object -<br />
which you'll find on the GraphicsContext.<br />
<br />
Sharing of display lists/texture objects between contexts on the OSG<br />
just requires you to set the State::ContextID to same value. If the<br />
GraphicsWindow implementation is set up correctly then it'll<br />
automatically assign the same ContextID for each of the seperate<br />
osg::State objects.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg02505.html</ref><br />
<br />
The scene graph is shared between the two slave Cameras. If<br />
the slave Camera have different graphics contexts then you can have<br />
separate OpenGL objects per context, but the OSG will automatically<br />
manage this all for you, it also offers the opportunity for threading<br />
the graphics contexts.<ref>https://groups.google.com/g/osg-users/c/4PECSribbLQ/m/niZFUC4Hnn0J</ref><br />
<br />
* It's possible to share contexts in the OSG [...] As for general desirability of share GL objects between contexts, yes it can reduce memory usage, but it forces you to use the OSG single threaded otherwise two contexts will be contended for the same resources that deliberately aren't mutex locked for performance reasons. There is also on a limited set of cases where drivers/hardware will actually share OpenGL contexts. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg32676.html</ref><br />
* Neither the OSG or OpenGL can provide thread safe sharing of GL objects when sharing contexts. If you want to run multiple context with multiple threads you will have to keep these contexts independent. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg75584.html</ref><br />
* If all your views share the same graphics context then it's only possible to single thread the draw dispatch. With this usage you'll be able to use DrawThreadPerContext which will allow the update and cull traversals to overlap the previous frames draw traversal, but overlap will only extend from the dispatch of the last dynamic object in the draw traversal being dispatched. If you have a large static scene then the overlap can be the whole frame, if you have lots of StateSet and Geometry with a DataVariance of DYNAMIC then the scope for threading is reduced, and at worst case will essentially be serialized and equivilant to SingleThreaded. Things that affect the draw traversals sometimes need draw threads to be stopped completely. Things like adding views to a CompositeViewer, or changing the graphics context on a camera, or things like that. It's pretty rare you need to do this. It's also pretty costly, because stopThreading() will only return once the draw threads have been stopped and deleted, and startThreading() only returns once new draw threads have been created and started.<ref>https://groups.google.com/d/msg/osg-users/chUK1HzAfLA/QW4JPCgXfoQJ</ref><br />
* an OpenGL context is tied to a single window or pixel buffer. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg75586.html</ref><br />
* Sharing contexts is also something the forces a few limits on how you use the graphics contexts, such as it's only really safe to use them single threaded. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg16791.html</ref><br />
* If you are creating new graphics contexts and applying and old scene graph to it then you can't use the Texture::setUnRefImageDataAfterApply(true) feature of osg::Texture as this will discard the imagery once it's applied to all the graphics contexts that it knows about. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg32658.html</ref> The typical problem is that the scene graph has been set up to unref texture images after apply so when it comes to reloading the texture images there aren't the to download. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg34284.html</ref><br />
<br />
=== Scene View Buffering ===<br />
Both '''DrawThreadPerContext''' and '''CullThreadPerCameraDrawThreadPerContext''' modes<br />
use osgViewer::Renderer thread with double buffered SceneViews.<br />
<br />
'''SingleThreaded''' and '''CullDrawThreadPerContext''' use a single SceneView for<br />
rendering. (CullDrawThreadPerContext also uses Renderer but only with one<br />
SceneView see osgViewer::Rendered::cull_draw method in comparison to<br />
osgViewer::Renderer::draw & osgViewer::Renderer::cull)<br />
<br />
Double buffered SceneViews means that there are two interleaved SceneViews<br />
performing cull and draw operations for subsequent odd/even frames. These<br />
two scene views share some resources but may also create some separate<br />
resources. For example, if texture is attached to RTT camera, each of these<br />
SceneViews will create two separate FBOs for<br />
this camera but these FBOs will share camera texture. But when you attach<br />
the image to RTT camera, each of these FBOs will create<br />
spearate render buffer and will read pixels to the camera image from the<br />
buffer.<ref>https://groups.google.com/g/osg-users/c/cIMLA2zkdyE/m/cUx9JZA2J4MJ</ref><br />
=== Swap Buffers ===<br />
OpenGL drivers have a FIFO, your app fills the fifo with tokens and<br />
data, at the end of the frame you send in a swap buffers token and<br />
this goes into the FIFO with everything else. Normally the swap<br />
buffers call itself doesn't block (although some implementations do<br />
this), but the FIFO itself can only be cleared at the rate for one<br />
swap buffers call per frame so it'll fill and once filled up it will<br />
effectively block until previous frame was begun dispatching. The<br />
driver may allow several frames worth data in the fifo before block,<br />
this is driver dependent, and also dependent on just how data you have<br />
to pass to OpenGL- if you have massive models the CPU will be block on<br />
the FIFO right on the same frame rather than more than one frame begin<br />
backed in the FIFO.<br />
<br />
The end result of this is simpler though - put vsync on, and your<br />
frame loop will block and should iddle while its waiting for the FIFO<br />
to begin accepting new data. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg04323.html</ref><br />
<br />
The driver will be queuing up multiple frames in the FIFO, something it<br />
does to help improve the framerate, but increases frame latency.<br />
<br />
We aren't powerless in this though, modern drivers and hardware support<br />
putting fences into the pipeline and waiting on these to be completed on<br />
the GPU. In the svn/trunk vesion of the OSG you'll find a swap buffers<br />
SyncSwapBuffersCallback implementation that does this for you. You can<br />
enable this via the env var OSG_SYNC_SWAP_BUFFERS=ON, or --sync on the<br />
command line for examples like osgviewer.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg68525.html</ref><br />
<br />
There is an OpenGL extension that supports syncronizing of swap<br />
buffers across multiple graphics contexts that allows you to assigns<br />
contexts to swap groups<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg32951.html</ref><br />
<br />
some graphics drivers will do swap buffers in sequence if you have<br />
multiple windows being rendered too, with each swap doing a vsync,<br />
which ends up with each window blocking till the end of each screen<br />
refresh. Use of the swap groups extension would be one way around<br />
this issue<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg22273.html</ref><br />
<br />
The GraphicsContext::swapBuffers() is<br />
normally what does the swap buffers and then calls<br />
GraphicsContext::clear(), with GraphicsWindowEmbedded::swapBuffers()<br />
it's a non op, because there is no way it can do a swap buffers as it<br />
doesn't actually know about a real graphics context.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg21395.html</ref><br />
<br />
=== Image Sharing ===<br />
Sharing of images is possible by using a frame<br />
buffer copy to osg::Image, or just having multiple FBO's all within<br />
one graphics context. <ref>https://groups.google.com/g/osg-users/c/9oDKlqiGba8/m/ZkjY66niTkcJ</ref><br />
<br />
If you want to use the result in a separate window/display you'll need<br />
to copy the result back to an osg::Image and then use this image on<br />
another texture on the other windows. osg::Camera supports attaching<br />
an osg::Image to it and will automatically copy the frame buffer(or<br />
FBO) to the image, and osg::Texture* all are able to detect an update<br />
to an osg::Image so will automatically download the result, so it's<br />
possible to do this wiring up relatively easily, but.. performance<br />
won't be great as it requires a round trip to the CPU/main memory.<ref>https://groups.google.com/g/osg-users/c/OBg4fBOj52Y/m/vRkBJS6GPaIJ</ref><br />
<br />
The best way to deal with the high cost of these operations is to<br />
avoid them completely. Try to use algorithms that can use render to<br />
texture using FBO's and read this textures directly in other<br />
shaders. Never try to copy the results back to the CPU/main memory,<br />
this does force you to do more work on the GPU and rely on more<br />
complex shaders but in the end it means that you don't have to force a<br />
round trip to the GPU.<br />
It's the flushing of the fifo that is the problem, that's why it's so<br />
slow, not the data transfer itself. Once you flush the fifo you loose<br />
the parallelism between the CPU and GPU.<br />
<br />
The only way to hide this is to use PBO's to do the read back and do<br />
the actual read back on the next frame rather than in the current<br />
frame. In your case you might be able to get away with this, a frames<br />
latency might not be a big issue if you can keep to a solid 60Hz and<br />
the values you are reading back aren't changing drastically between<br />
frames.<br />
osgscreencapture uses a frame latency when it double buffers the<br />
PBO's. It doesn't matter whether it's frame buffer or FBO, the PBO is<br />
only related to memory management.<ref>https://groups.google.com/g/osg-users/c/JY1mVGofOEg/m/8P7j5titqVcJ</ref><br />
<br />
<br />
* Sharing of images is possible by using a frame buffer copy to osg::Image, or just having multiple FBO's all within one graphics context. If you can have the frames all done synchronously then perhaps you could have one frame loop and just disable the cameras via camera->setNodeMask(0x0); that you don't need updating on each frame, i.e. main viewer runs at 60Hz, and the other RTT cameras run at 20Hrz so get update on frame in 3.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg07360.html</ref><br />
* ImageStream is updated by a background thread. The xine-lib and QuickTime plugins both subclass from ImageStream and OpenThreads::Thread to provide a class thatautomatically runs updates on itself - this thread updates the image data on the ImageStream and then calls dirty to tell the rendering thread that it needs to download the data to any associated texture.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg11405.html</ref><br />
* It's better to update the data stored in the Image directly and call dirty, or to allocate the image memory separately and disable the deletion of the data on the image so the osg::Image(Stream) never calls delete on the data.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg11440.html</ref><br />
<br />
=== Offscreen rendering ===<br />
The two options for off screen rendering are a PixelBuffer context or<br />
FrameBufferObject, if you have an existing on screen window in your<br />
application then using a FrameBufferObject becomes preferable. The<br />
way to do it would be to set up your viewer's off screen Camera with<br />
FBO settings and a custom final draw callback to do the read to main<br />
memory. The read will be more efficient if you use a pair of<br />
PixelBufferObjects - the osgscreencapture example illustrates this in<br />
action.<br />
<br />
If all you ever want is to render offscreen, then go with the other suggestion of creating a<br />
PBuffer (pixel buffer) context instead of a normal graphics context. The<br />
default contexts will spawn a window, the PBuffer will not.<br />
<br />
If you are already using CompositeViewer the most natural thing to do<br />
would be to have a dedicated View with it's master Camera as the<br />
offscreen camera, this way you can control the Camera's view matrix in<br />
straight forward manner in the same way to the rest of the Camera's.<br />
Also during debugging having the option of making this Camera an<br />
onscreen one would give you means to visually QA things as you go<br />
along. <ref>https://groups.google.com/g/osg-users/c/WTkiQNLE3ek/m/6eB3Z7MoEgAJ</ref><br />
<br />
FBO's aren't a direct replacement for PixelBuffer objects so you can't<br />
just miminc a osg::PixelBufferX11 by using a FBO.<br />
<br />
FBO's are GL object objects, while PixelBuffer's are graphics<br />
contexts. To create a FBO you need a graphics context. A PixelBuffer<br />
is a graphics context that has it's own frame buffer that isn't<br />
assigned to the display like a GraphicsWindow graphics context.<br />
<br />
In the past OpenGL didn't have the ability to render to anything other<br />
than graphics context's frame buffer so to PixelBuffer were the<br />
standard way to doing multi pass rendering. With the advent of<br />
FrameBufferObject OpenGL now had an ability to render to a frame<br />
buffer other than the one assigned to the graphics context for the<br />
purpose of display on the screen, as the FBO is OpenGL object within a<br />
graphics context it's more efficient than using two graphics context<br />
to do render to texture so is very much the preferred way of doing<br />
multipass techniques like Render to Texture used in shadowing,<br />
lighting etc.<br />
<br />
These days the need for PixelBuffer is much diminished as FBO's work<br />
really well for most applications, however, there are times with<br />
PixelBuffer's are still useful - if you want to render completely<br />
offscreen with any on screen window then a PixelBuffer is a perfect<br />
tool as is still the appropriate tool for the job.<ref>https://groups.google.com/g/osg-users/c/fic3TCvWacE/m/4vu5pG5pAQAJ</ref><br />
<br />
=== Multiple Viewers ===<br />
{{See also|Howto:New Canvas Execution Model}}<br />
One possible<br />
solution would be to have two separate viewers, each running their own<br />
frame() when required - you can't mix scene graphs or graphics contexts<br />
in this case though.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg30983.html</ref><br />
<br />
If you don't want the main rendering loop to wait for the rendering of all these extra views then<br />
you'll need to use a separate viewer(or compositeviewer) with it's own<br />
threading. You'll need to manage your own frame loops in the secondary<br />
viewer.<br />
<br />
The only reason to copy data is if it the data is being modified by the<br />
different threads. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg78132.html</ref><br />
<br />
this should probably be possible given separate<br />
threads for each of the viewers frame loops i.e. run them all in a<br />
background thread.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg07360.html</ref><br />
<br />
You could easily just create an entirely separate viewer for doing the<br />
screenshots. You can have this run in the background with no need to<br />
affect the main viewer's threading/graphic contexts.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg36857.html</ref><br />
<br />
you will be able to do is use two separate Viewer's. You are<br />
likely to want to run two threads for each of the viewers frame loops<br />
as well. To get the render to image result to the second viewer all<br />
you need to do is assign the same osg::Image to the first viewer's<br />
Camera for it to copy to, and then attach the same osg::Image to a<br />
texture in the scene of the second viewer. The OSG should<br />
automatically do the glReadPixels to the image data, dirty the Image,<br />
and then automatically the texture will update in the second viewer.<br />
You could potentially optimize things by using an PBO but the off the<br />
shelf osg::PixelBufferObject isn't suitable for read in this way so<br />
you'll need to roll you own support for this.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg18308.html</ref><br />
<br />
For viewers to share the same node group, you need take care of explicitly sync'ing the FrameStamp between each traversal as otherwise the state of the scene graph can get thrashed between different times.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg19107.html</ref><br />
<br />
== Related ==<br />
=== Docs ===<br />
* http://www.openscenegraph.org/index.php/documentation/guides/programming-guides/93-viewer-vs-compositeviewer<br />
* http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a00108.html<br />
* [https://www.programmersought.com/article/29045800335/ osg::FrameStamp and osg::Timer in OSG]<br />
<br />
=== Discussions ===<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17001.html<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17263.html<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27134.html<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg28869.html<br />
* http://forum.flightgear.org/viewtopic.php?f=17&t=18813<br />
* http://forum.flightgear.org/viewtopic.php?f=4&t=18785&p=199916#p199916<br />
=== Search ===<br />
* https://www.mail-archive.com/search?q=compositeviewer&l=osg-users%40lists.openscenegraph.org<br />
* https://www.mail-archive.com/search?q=pagedlod&l=osg-users%40lists.openscenegraph.org<br />
* http://www.mail-archive.com/search?q=compositeviewer&l=flightgear-devel%40lists.sourceforge.net<br />
* http://www.mail-archive.com/search?l=flightgear-devel%40lists.sourceforge.net&q=PagedLOD+<br />
* https://sourceforge.net/p/flightgear/mailman/search/?q=%22CompositeViewer%22<br />
* https://sourceforge.net/p/flightgear/mailman/search/?q=%22PagedLOD%22<br />
* https://forum.flightgear.org/search.php?st=0&sk=t&sd=d&sr=posts&keywords=CompositeViewer<br />
<br />
== References ==<br />
<br />
{{Appendix}}<br />
[[Category:Developer Plans]]</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=User:Cgdae&diff=136945User:Cgdae2023-01-01T19:53:10Z<p>Cgdae: Some improvements to formatting.</p>
<hr />
<div>== Current ==<br />
<br />
=== Control over thread-cpu affinities. ===<br />
<br />
This work is on next.<br />
<br />
By default OSG ties the main thread and others to a single CPU core early on in startup. This can cause problems on Linux if one tries to run CPU-intensive tasks on other threads, because new threads inherit their parent thread's affinity settings.<br />
<br />
For example this can make video encoding run very slowly because the internal threads created by ffmpeg can end up all trying to run on the same core.<br />
<br />
One can change the default behaviour by setting the '''/sim/thread-cpu-affinity''' property on startup with '''--prop:/sim/thread-cpu-affinity=...''':<br />
<br />
* Empty string or unset: allow OSG to set thread affinities as normal.<br />
* Set to "none": do not allow OSG to set thread affinities; the OS gets to choose what cores to use.<br />
* Set to "osg": allow OSG to set up thread affinities but attempt to cancel affinity of main thread afterwards. (This doesn't really work.)<br />
<br />
One can also change the behaviour at runtime by setting property '''/sim/affinity-control''', e.g. to test the effect of thread affinities on frame rate:<br />
<br />
* Set to "clear": remember current threads' affinities then clear all thread affinities.<br />
* Set to "revert": restore thread affinities remembered from most recent '''clear''' setting.<br />
<br />
<br />
== Completed ==<br />
<br />
These are all on next. Some items may also have been cherry-picked onto the current stable branch.<br />
<br />
* [[YASim#Torus-shaped_contact_surface_on_next|YASim tyre contact surfaces]].<br />
* [[Video encoding]] of Flightgear's main window.<br />
** E.g. see: http://op59.net/fgvideo-harrier-gr3-manhattan.mkv<br />
* [[Highlighting]].<br />
* [[SimpleTime]].<br />
* [[ExtraViewWindows|Extra view windows]].<br />
* [[Instant_Replay#Record.2Freplay_on_next|Enhancements to record/replay]].<br />
* [[Carrier_over_MP#Pilot_Using_the_Carrier|Enhancements to multiplayer carrier operation]].<br />
*[https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/debug/logdelta.hxx logdeltas] - control of debug log levels based on source filename prefixes, line numbers and function prefixes.<br />
*[[Post_FlightGear_2020.2_LTS_changes#Record.2Freplay|Record/replay]]:<br />
** Multiplayer record.<br />
**Continuous record.<br />
**Recovery snapshots.<br />
*[[Changelog_2020.1#Multiplayer |Multiplayer views]].<br />
*[[Changelog_2020.1#Graphics |Tower View AGL]].<br />
<br />
== Other ==<br />
<br />
* [[:Category:Hackathon 2021 Ideas]].<br />
*[[Walk_build_system|The Walk Flightgear Build system]] - a different kind of build system which i use to build Flightgear.<br />
*Harrier-GR3 autohover: https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Harrier-GR3/<br />
*Flightgear on [http://www.openbsd.org OpenBSD].</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=Tactical_Air_Navigation&diff=135037Tactical Air Navigation2022-05-07T23:32:40Z<p>Cgdae: Show some tacan properties</p>
<hr />
<div>[[File:Pictogram TACAN.png|frame|TACAN symbol]]<br />
'''TACtical Air Navigation''', or '''[http://en.wikipedia.org/wiki/Tactical_Air_Navigation TACAN]''', is a navigation system used by [[:Category:Military aircraft|military aircraft]]. It provides the user with a distance and bearing from a ground station. It is a more accurate version of the [http://en.wikipedia.org/wiki/Vhf VHF] omnidirectional range / Distance Measuring Equipment ([[VOR-DME]]) system that provides range and bearing information for civil aviation. At VORTAC facilities, the [[DME]] portion of the TACAN system is available for civil use.<br />
<br />
== Operation ==<br />
TACAN in general can be described as the military version of the [[VOR-DME]] system. It operates in the frequency band 960-1215 MHz. The bearing unit of TACAN is more accurate than a standard [[VOR]] since it makes use of a two frequency principle, with 15 Hz and 135 Hz components.<br />
<br />
The distance measurement component of TACAN operates with the same specifications as do civil [[DME]]'s. Therefore to reduce the number of required stations, TACAN stations are frequently co-located with [[VOR]] facilities. These co-located stations are known as [[VORTAC]]'s. This is a station composed of a [[VOR]] for civil bearing information and a TACAN for military bearing information and military/civil distance measuring information. The TACAN transponder performs the function of a [[DME]] without the need for a separate, collocated [[DME]]. Because the rotation of the antenna creates a large portion of the azimuth signal, if the antenna fails, the azimuth component is no longer available and the TACAN downgrades to a [[DME]] only mode.<br />
<br />
TACAN can operate in either receive mode (R), or transmit/receive (TR) mode. <br />
<br />
=== FlightGear ===<br />
A few planes in FlightGear are equipped with TACAN. Here's a list of known aircraft with TACAN:<br />
<br />
* [[Grumman A-6E|A-6E]]<br />
* [[Fairchild A-10|A-10]]<br />
* [[Douglas A4 Skyhawk|A4F]]<br />
* [[Rockwell B-1B Lancer|B-1B]]<br />
* [[Blackburn Buccaneer]]<br />
* [[FIAT_G91R1B|Fiat G91R1B]]<br />
* [[Grumman F-14 Tomcat]]<br />
* [[English Electric Lightning|Lightning]]<br />
* [[McDonnell Douglas F-15 Eagle]]<br />
* [[Northrop T-38|T38]]<br />
<br />
To set TACAN, go to the <tt>Equipment > Radio Settings</tt> dialog. When using in-air refuel, first read [[Howto: Air-Air Refueling]]. <br />
<br />
The F-14 and F-15 have a TACAN control panel that needs to be set correctly. Refer to their documentation pages for more information.<br />
<br />
=== Example property values ===<br />
<br />
/instrumentation/tacan/<br />
display/<br />
channel=029Y<br />
frequency/<br />
selected-mhz=109.25<br />
ident=NMZ<br />
in-range=true<br />
indicated-bearing-true-deg=...<br />
indicated-distance-nm=...<br />
name=USS Nimitz TACAN<br />
servicable=true<br />
switch-position=1<br />
<br />
'''/instrumentation/tacan/display/channel''' and '''/instrumentation/tacan/frequency/selected-mhz''' are linked.<br />
<br />
<br />
===Related===<br />
*[[Radio beacons]]<br />
*[[Radio navigation]]<br />
<br />
[[Category:Aviation]]</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=User:Cgdae&diff=135034User:Cgdae2022-05-06T22:48:13Z<p>Cgdae: /* Recent */</p>
<hr />
<div>== Recent ==<br />
<br />
Current work in progress:<br />
<br />
* Control over thread-cpu affinities.<br />
** Default settings where OSG ties main thread and others to a single cpu core early in startup, can cause problems on Linux if one tries to run cpu intensive tasks on other threads. This is because new threads inherit their parent thread's affinity settings. For example this can make video encoding run very slowly because the threads created by ffmpeg can end up all trying to run on the same core.<br />
** '''/sim/thread-cpu-affinity''': set on startup with '''--prop:/sim/thread-cpu-affinity=...'''.<br />
*** "" or unset: allow OSG to set thread affinities as normal.<br />
*** "none": do not allow OSG to set thread affinities; the OS gets to choose what cores to use.<br />
*** "osg": allow OSG to set up thread affinities but attempt to cancel affinity of main thread afterwards. (This doesn't really work.)<br />
** '''/sim/affinity-control''': change value at runtime to test the effect of thread affinities on frame rate:<br />
*** "clear": remember current threads' affinities then clear all thread affinities.<br />
*** "revert": restore thread affinities remembered from most recent '''clear''' setting.<br />
<br />
<br />
On next:<br />
<br />
* [[YASim#Torus-shaped_contact_surface_on_next|YASim tyre contact surfaces]].<br />
* [[Video encoding]] of Flightgear's main window.<br />
** E.g. see: http://op59.net/fgvideo-harrier-gr3-manhattan.mkv<br />
* [[Highlighting]].<br />
* [[SimpleTime]].<br />
* [[ExtraViewWindows|Extra view windows]].<br />
* [[Instant_Replay#Record.2Freplay_on_next|Enhancements to record/replay]].<br />
* [[Carrier_over_MP#Pilot_Using_the_Carrier|Enhancements to multiplayer carrier operation]].<br />
<br />
Other:<br />
<br />
* [[:Category:Hackathon 2021 Ideas]].<br />
*[[Walk_build_system|The Walk Flightgear Build system]] - a different kind of build system which i use to build Flightgear.<br />
*Harrier-GR3 autohover: https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Harrier-GR3/<br />
*Flightgear on [http://www.openbsd.org OpenBSD].<br />
<br />
==Old==<br />
*[https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/debug/logdelta.hxx logdeltas] - control of debug log levels based on source filename prefixes, line numbers and function prefixes.<br />
*[[Post_FlightGear_2020.2_LTS_changes#Record.2Freplay|Record/replay]]:<br />
** Multiplayer record.<br />
**Continuous record.<br />
**Recovery snapshots.<br />
*[[Changelog_2020.1#Multiplayer |Multiplayer views]].<br />
*[[Changelog_2020.1#Graphics |Tower View AGL]].</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=Video_encoding&diff=134996Video encoding2022-04-24T14:49:25Z<p>Cgdae: /* Video encoding settings */</p>
<hr />
<div>== Overview ==<br />
<br />
Flightgear on next (the development branch) has support for video encoding of the main window. This requires that ffmpeg/libav libraries are available at build time.<br />
<br />
* Videos are generated in the current directory. This can be changed by setting property '''/sim/video/directory'''.<br />
* Video files are called '''fgvideo-<aircraft>-YYYYMMDD-HHMMSS.<container>''', for example '''fgvideo-harrier-gr3-20211209-234105.mp4'''.<br />
* A convenience link is created that points to the latest video, called '''fgvideo-<aircraft>.<container>''', for example '''fgvideo-harrier-gr3.mp4''' -> '''fgvideo-harrier-gr3-20211209-234105.mp4'''.<br />
<br />
== Limitations ==<br />
<br />
* As of 2021-12-12, only Unix builds of Flightgear include support for video encoding by default.<br />
** On other platforms, if ffmpeg libraries are installed on the system, Flightgear's cmake might pick them up automatically and enable video encoding, but this hasn't been tested.<br />
* We do not (yet) record sound.<br />
<br />
== Building ==<br />
<br />
On Unix, we require these libraries and their header files to be available at build time:<br />
<br />
* avcodec<br />
* avutil<br />
* swscale<br />
* avformat<br />
<br />
If these libraries and header files are installed, a standard cmake build should automatically include video encoding support.<br />
<br />
As of 2021-12-27, [[Scripted_Compilation_on_Linux_Debian/Ubuntu|download_and_compile.sh]] installs these libraries automatically.<br />
<br />
On Devuan (and probably other Debian-based distributions), they can be manually installed with:<br />
<br />
sudo apt install libavcodec-dev libavutil-dev libswscale-dev libavformat-dev<br />
<br />
== Creating video of live Flightgear ==<br />
<br />
=== Starting/stopping video encoding ===<br />
<br />
Use menu items '''File/Video Start''' and '''File/Video Stop''' to start/stop video encoding.<br />
<br />
* If an error occurs, for example support for video encoding was not included at build time, Flightgear will show a popup warning message.<br />
<br />
=== Video encoding settings ===<br />
[[File:Video-control dialogue.png|thumb]]<br />
Menu '''File/Video Control''' opens a dialogue that allows control over various settings, including:<br />
<br />
* Container name, such as '''mp4''' or '''ogv'''.<br />
** Radio buttons are provided for common containers.<br />
** Run '''ffmpeg -formats''' in a separate terminal to see what containers are available on your system.<br />
* Codec name, such as '''mpeg2video''', '''libx264''', '''libx265'''.<br />
** Radio buttons are provided for common codecs.<br />
** Run '''ffmpeg -codecs''' in a separate terminal to see what codecs are available on your system.<br />
* Encoding quality in range '''0..1'''. Use '''-1''' for codec's default.<br />
* Encoding speed in range '''0..1'''. Use '''-1''' for codec's default.<br />
* Encoding target bitrate in bits per second. Use '''0''' for codec's default.<br />
<br />
Some combinations of container and codec are not supported by Ffmpeg, for example container '''OGV''' and codec '''H.265'''. If this happens, an error message will pop up; you can try again with different settings.<br />
<br />
== Creating video from Flightgear recordings ==<br />
<br />
Flightgear can automatically generate a video when replaying a recording file, stopping video encoding when we reach the end of the recording.<br />
<br />
Usually one would use a Continuous recording for this, as they contain full information regardless of the recording duration.<br />
<br />
* From within Flightgear:<br />
** In the '''Load Flight Recorder Tape''' dialogue, set the '''Auto-create video''' checkbox.<br />
** Optionally also set '''Fixed dt''' (see below).<br />
<br />
* With the command line '''--load-tape''' option:<br />
** Also specify '''--load-tape-create-video'''.<br />
** Optionally specify '''--load-tape-fixed-dt=...''' (see below).<br />
<br />
=== Using '''fixed-dt''' ===<br />
<br />
Setting '''fixed-dt''' to a non-zero value forces Flightgear to increment the FDM time in seconds by the specified amount each frame, instead of by the elapsed real-world time between frames. For example using a value of 0.04 will force a frame rate of 25fps.<br />
<br />
This allows creation of high quality videos from recordings, regardless of the rendering settings or speed of the host, at the expense of potentially taking longer than real time to create the recording.<br />
<br />
=== Command line examples ===<br />
<br />
Create a high quality video of a recording by running Flightgear with these command-line args:<br />
<br />
'''--load-tape=... --load-tape-create-video=1 --prop:bool:/sim/time/simple-time/enabled=true --load-tape-fixed-dt=0.04 --graphics-preset=high-quality'''<br />
<br />
Also fix video settings by setting the relevant properties:<br />
<br />
'''--load-tape=... --load-tape-create-video=1 --prop:bool:/sim/time/simple-time/enabled=true --load-tape-fixed-dt=0.04 --graphics-preset=high-quality --prop:/sim/video/container=mp4 --prop:/sim/video/codec=libx265 --prop:/sim/video/quality=0.75 --prop:/sim/video/speed=1'''<br />
<br />
=== Example video ===<br />
<br />
This 5 minute video flying around Manhattan with high rendering settings was created on a fairly slow laptop, taking about an hour to replay and encode: http://op59.net/fgvideo-harrier-gr3-20211206-230342-manhattan.mp4</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki:Village_pump&diff=134990FlightGear wiki:Village pump2022-04-19T10:16:59Z<p>Cgdae: /* 2022 Newsletters forward/backward links are broken */</p>
<hr />
<div>__NEWSECTIONLINK__<br />
{{Archives|[[/Archive 2012|2012]]|[[/Archive 2013|2013]]|[[/Archive 2014|2014]]|[[/Archive 2015|2015]]|[[/Archive 2016|2016]]|[[/Archive 2017|2017]]|[[/Archive 2018|2018]]|[[/Archive 2019|2019]]|[[/Archive 2020|2020]]}}<br />
{{shortcut|FGW:VP}}<br />
<br />
Welcome to the '''Village Pump'''. This page is used to discuss the technical issues, operations and guidelines of the [[FlightGear wiki]].<br />
<br />
Please <span class="plainlinks">[{{fullurl:{{FULLPAGENAME}}|action=edit&section=new}} add new topics]</span> to the '''bottom''' of this page.<br />
<br />
Old discussions should be moved to a [[FlightGear wiki:Village pump/Archive YEAR]]. These discussions can then be moved to a relevant talk page if appropriate.<br />
<br />
== MediaWiki updated to 1.35.1 ==<br />
Hi all,<br />
<br />
We've just updated MediaWiki (our wiki software) to version 1.35.1. The update comes with a couple of nice new features, such as [https://www.mediawiki.org/wiki/Extension:VisualEditor a visual editor] that considerably lowers the entry barrier (no need to learn wiki markup!). We've also fixed the issue that prevented users from [[FlightGear_wiki:Village_pump/Archive_2020#UTF-8_language_pages_cannot_be_edited_.28cont._from_2015.29|editing certain non-Latin articles]] and enabled TLS so your connection is now secured with HTTPS.<br />
<br />
Although we've tested the update, chances are that we've missed certain scenarios. Please let me know if something isn't working as expected.<br />
<br />
Cheers,<br />
<br />
[[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 16:59, 6 February 2021 (UTC)<br />
<br />
PS: Now that we're back in sync, you may expect more frequent updates again.<br />
<br />
: The only issues I have noted so far is that<br />
:* It seems the visual editor, when editing discussion pages, can only be used when adding a new topic, but not when editing an existing one.<br />
:* Section editing is off by default (though I think it might have been previously as well).<br />
: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 15:45, 7 February 2021 (UTC)<br />
<br />
:: Hi Johan,<br />
::* I believe that's the way they've designed it (it also works like that on Wikipedia), but I'll see if that can be changed.<br />
::* What do you mean with "section editing"? I can see <code>[ edit | edit source ]</code> links at each section title?<br />
:: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 15:57, 7 February 2021 (UTC)<br />
<br />
::: Section editing was off by default for me after the update (at least when looking in the preferences; I did open the preferences before I went through any articles).<br />
::: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 10:33, 8 February 2021 (UTC)<br />
<br />
: Thank you very much! The 6 year old UTF-8 bug is finally gone!! Everything else is looking good to me. No strange Scribuntu/lua errors from the infoboxes, SyntaxHighlight works, collapsible boxes work. Great job!<br />
<br />
: I did get one error: "Error contacting the Parsoid/RESTBase server: http-bad-status" when trying to edit. This was triggered by switching from the visual editor to the source editor using the menu bar that appears in the visual editor. But I fixed this by turning off the visual editor in my preferences.<br />
<br />
: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 21:12, 16 February 2021 (UTC)<br />
<br />
:: Hm, I cannot reproduce that here. Did it happen at a specific page? Can you try to reproduce it and provide a recipe?<br />
::[[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:37, 18 February 2021 (UTC)<br />
<br />
: Oh, just one thing if this is possible, can we have a [https://www.mediawiki.org/wiki/Manual:$wgFavicon favicon] set like the forum and the [https://flightgear.org main website]?<br />
<br />
: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 21:23, 16 February 2021 (UTC)<br />
<br />
:: Good one, done!<br />
:: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:37, 18 February 2021 (UTC)<br />
<br />
== Parameter listings in template documentation ==<br />
I noted that the skeleton examples with all parameters have been removed in some cases.<br />
<br />
I very much prefer to still having a copyable skeleton template (with prefilled month, year, and/or date when those parameters exist) before the listing of parameters, rather than having to copy a fully filled out filled out example and remove everything I do not need or have to change. It feels very unnecessary.<br />
<br />
On the other hand I do like the template data stuff very much, even though it is few extra steps.<br />
<br />
—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 11:41, 10 February 2021 (UTC)<br />
<br />
: Hi Johan,<br />
: I'm not sure if you know this, but you can now add templates through the VisualEditor. If you press "Insert > Template" from the toolbar, you get a nice popup to help you fill in the template and it can also pre-fill stuff for you (e.g., the date in [[:Template:Delete]]). The templatedata stuff on the template page is used to expand this popup form and drive the auto-fill, so most templates will not yet leverage it to the fullest. You can add/edit templatedata by clicking the "Manage TemplateData" button at the top of the edit page of templates. See the documentation at {{mediawiki|Help:TemplateData}} (that page is unfortunately quite messy, I know) and {{mediawiki|Extension:TemplateData}}. <br />
: I feel like we should encourage people as much as possible to use the VisualEditor, as it can help prevent mistakes or incomplete templates. Would this remove the need to have copy & pastable templates? Maybe we'll just have to try and see. There's lots of new stuff to discover and tweak :-)<br />
: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:20, 11 February 2021 (UTC)<br />
<br />
== Removing the "Goal" heading from template documentation ==<br />
As we will likely go through and edit most of the template documentation to replace the current documentation of template parameters with template data, I would like to also remove the ''Goal'' heading from the template documentation and move that up to being a regular lead section.<br />
<br />
I feel that the heading is largely redundant and have previously stuck to it mostly for consistency.<br />
<br />
—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 11:48, 10 February 2021 (UTC)<br />
<br />
: Agree!<br />
: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:20, 11 February 2021 (UTC)<br />
<br />
== Basic question sub page/sandbox ==<br />
<br />
Hi,<br />
New to the wiki here and hoping to contribute in some small way. I don't see any instructions (or menu options) on how to crate a sub page or sandbox in order to start drafting an article. I'll also aim to update the wiki on how to crate a sub page as it might help others with the same question.<br />
Many thanks<br />
[[User:Volador|Volador]] ([[User talk:Volador|talk]]) 08:33, 7 April 2021 (UTC)<br />
<br />
== MediaWiki updated to 1.35.3 ==<br />
We have updated MediaWiki to its latest version 1.35.3 today. Although we've tested the update, chances are that we've missed certain scenarios. Please report any issues that you may encounter.<br />
<br />
[[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:45, 23 July 2021 (UTC)<br />
<br />
== Backup and shutdown plan ==<br />
<br />
Hello. In the past, I have contributed to sites such as Yahoo Answers, which disappointingly ended up shutting down with little notice after operating seemingly well for a long time, i.e. over a decade.<br />
<br />
In the unlikely case that this wiki ends up shutting down at some point in future, I would like to ask whether the wiki has a backup plan. Since text compresses efficiently, will a compressed archive of users' contributions be released? And how long in advance would there be a warning? [[User:Gordon|Gordon]] ([[User talk:Gordon|talk]]) 13:13, 13 February 2022 (UTC)<br />
<br />
: Hi Gorden and welcome!<br />
: Yes, we make regular backups. There is no intention to shutdown the wiki at any point and as we are not a commercial project, we have absolutely no reason to withhold any data that you've contributed. I could imagine that at some point the contents of the wiki may be moved to a different platform (who knows what'll be available in years from now), but definitely not deleted. Note that the wiki is also occasionally archived to the [http://web.archive.org/web/*/wiki.flightgear.org* Internet Archive].<br />
: Does that give you enough reassurance to contribute?<br />
: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:25, 14 February 2022 (UTC)<br />
<br />
:: Yes, sounds good. Thanks much. As a side note, the Internet Archive saves pages' lastest revisions but not their full history. It just serves as additional surface backup. [[User:Gordon|Gordon]] ([[User talk:Gordon|talk]]) 20:48, 18 February 2022 (UTC)<br />
<br />
== 2022 Newsletters forward/backward links are broken ==<br />
<br />
Recently the chain of newsletters for 2022 appears to have been broken. There was a February newsletter and a April newsletter, but no March newsletter, and the Feb and Mar newsletters did not link to each other.<br />
<br />
In the last day or so, [[User:Aepcam]] has created a March newsletter. But the links are still not working. For example both the March and April newsletters have "Create next Edition >" links that would create a new May newsletter.<br />
<br />
See:<br />
<br />
* [[FlightGear_Newsletter_February_2022]]<br />
* [[FlightGear_Newsletter_March_2022]]<br />
* [[FlightGear_Newsletter_April_2022]]<br />
<br />
Could someone who knows how these things work, take a look?<br />
<br />
Thanks.<br />
<br />
[[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 20:16, 18 April 2022 (UTC)<br />
<br />
: Hi,<br />
: This looks to me as if it's still working like it used to? "Please help us write the coming edition" links to the April newsletter (which is being written now) and "Create next edition" links to May, which is the next edition after that. Or did you mean something else?<br />
: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:04, 19 April 2022 (UTC)<br />
<br />
:: The problem i was seeing has been fixed by this change (i think by you?): https://wiki.flightgear.org/w/index.php?title=FlightGear_Newsletter_March_2022&diff=134988&oldid=134976<br />
<br />
:: Thanks.<br />
<br />
:: [[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 10:16, 19 April 2022 (UTC)</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki:Village_pump&diff=134985FlightGear wiki:Village pump2022-04-18T20:33:06Z<p>Cgdae: /* 2022 Newsletters forward/backward links are broken */</p>
<hr />
<div>__NEWSECTIONLINK__<br />
{{Archives|[[/Archive 2012|2012]]|[[/Archive 2013|2013]]|[[/Archive 2014|2014]]|[[/Archive 2015|2015]]|[[/Archive 2016|2016]]|[[/Archive 2017|2017]]|[[/Archive 2018|2018]]|[[/Archive 2019|2019]]|[[/Archive 2020|2020]]}}<br />
{{shortcut|FGW:VP}}<br />
<br />
Welcome to the '''Village Pump'''. This page is used to discuss the technical issues, operations and guidelines of the [[FlightGear wiki]].<br />
<br />
Please <span class="plainlinks">[{{fullurl:{{FULLPAGENAME}}|action=edit&section=new}} add new topics]</span> to the '''bottom''' of this page.<br />
<br />
Old discussions should be moved to a [[FlightGear wiki:Village pump/Archive YEAR]]. These discussions can then be moved to a relevant talk page if appropriate.<br />
<br />
== MediaWiki updated to 1.35.1 ==<br />
Hi all,<br />
<br />
We've just updated MediaWiki (our wiki software) to version 1.35.1. The update comes with a couple of nice new features, such as [https://www.mediawiki.org/wiki/Extension:VisualEditor a visual editor] that considerably lowers the entry barrier (no need to learn wiki markup!). We've also fixed the issue that prevented users from [[FlightGear_wiki:Village_pump/Archive_2020#UTF-8_language_pages_cannot_be_edited_.28cont._from_2015.29|editing certain non-Latin articles]] and enabled TLS so your connection is now secured with HTTPS.<br />
<br />
Although we've tested the update, chances are that we've missed certain scenarios. Please let me know if something isn't working as expected.<br />
<br />
Cheers,<br />
<br />
[[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 16:59, 6 February 2021 (UTC)<br />
<br />
PS: Now that we're back in sync, you may expect more frequent updates again.<br />
<br />
: The only issues I have noted so far is that<br />
:* It seems the visual editor, when editing discussion pages, can only be used when adding a new topic, but not when editing an existing one.<br />
:* Section editing is off by default (though I think it might have been previously as well).<br />
: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 15:45, 7 February 2021 (UTC)<br />
<br />
:: Hi Johan,<br />
::* I believe that's the way they've designed it (it also works like that on Wikipedia), but I'll see if that can be changed.<br />
::* What do you mean with "section editing"? I can see <code>[ edit | edit source ]</code> links at each section title?<br />
:: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 15:57, 7 February 2021 (UTC)<br />
<br />
::: Section editing was off by default for me after the update (at least when looking in the preferences; I did open the preferences before I went through any articles).<br />
::: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 10:33, 8 February 2021 (UTC)<br />
<br />
: Thank you very much! The 6 year old UTF-8 bug is finally gone!! Everything else is looking good to me. No strange Scribuntu/lua errors from the infoboxes, SyntaxHighlight works, collapsible boxes work. Great job!<br />
<br />
: I did get one error: "Error contacting the Parsoid/RESTBase server: http-bad-status" when trying to edit. This was triggered by switching from the visual editor to the source editor using the menu bar that appears in the visual editor. But I fixed this by turning off the visual editor in my preferences.<br />
<br />
: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 21:12, 16 February 2021 (UTC)<br />
<br />
:: Hm, I cannot reproduce that here. Did it happen at a specific page? Can you try to reproduce it and provide a recipe?<br />
::[[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:37, 18 February 2021 (UTC)<br />
<br />
: Oh, just one thing if this is possible, can we have a [https://www.mediawiki.org/wiki/Manual:$wgFavicon favicon] set like the forum and the [https://flightgear.org main website]?<br />
<br />
: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 21:23, 16 February 2021 (UTC)<br />
<br />
:: Good one, done!<br />
:: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:37, 18 February 2021 (UTC)<br />
<br />
== Parameter listings in template documentation ==<br />
I noted that the skeleton examples with all parameters have been removed in some cases.<br />
<br />
I very much prefer to still having a copyable skeleton template (with prefilled month, year, and/or date when those parameters exist) before the listing of parameters, rather than having to copy a fully filled out filled out example and remove everything I do not need or have to change. It feels very unnecessary.<br />
<br />
On the other hand I do like the template data stuff very much, even though it is few extra steps.<br />
<br />
—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 11:41, 10 February 2021 (UTC)<br />
<br />
: Hi Johan,<br />
: I'm not sure if you know this, but you can now add templates through the VisualEditor. If you press "Insert > Template" from the toolbar, you get a nice popup to help you fill in the template and it can also pre-fill stuff for you (e.g., the date in [[:Template:Delete]]). The templatedata stuff on the template page is used to expand this popup form and drive the auto-fill, so most templates will not yet leverage it to the fullest. You can add/edit templatedata by clicking the "Manage TemplateData" button at the top of the edit page of templates. See the documentation at {{mediawiki|Help:TemplateData}} (that page is unfortunately quite messy, I know) and {{mediawiki|Extension:TemplateData}}. <br />
: I feel like we should encourage people as much as possible to use the VisualEditor, as it can help prevent mistakes or incomplete templates. Would this remove the need to have copy & pastable templates? Maybe we'll just have to try and see. There's lots of new stuff to discover and tweak :-)<br />
: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:20, 11 February 2021 (UTC)<br />
<br />
== Removing the "Goal" heading from template documentation ==<br />
As we will likely go through and edit most of the template documentation to replace the current documentation of template parameters with template data, I would like to also remove the ''Goal'' heading from the template documentation and move that up to being a regular lead section.<br />
<br />
I feel that the heading is largely redundant and have previously stuck to it mostly for consistency.<br />
<br />
—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 11:48, 10 February 2021 (UTC)<br />
<br />
: Agree!<br />
: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:20, 11 February 2021 (UTC)<br />
<br />
== Basic question sub page/sandbox ==<br />
<br />
Hi,<br />
New to the wiki here and hoping to contribute in some small way. I don't see any instructions (or menu options) on how to crate a sub page or sandbox in order to start drafting an article. I'll also aim to update the wiki on how to crate a sub page as it might help others with the same question.<br />
Many thanks<br />
[[User:Volador|Volador]] ([[User talk:Volador|talk]]) 08:33, 7 April 2021 (UTC)<br />
<br />
== MediaWiki updated to 1.35.3 ==<br />
We have updated MediaWiki to its latest version 1.35.3 today. Although we've tested the update, chances are that we've missed certain scenarios. Please report any issues that you may encounter.<br />
<br />
[[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:45, 23 July 2021 (UTC)<br />
<br />
== Backup and shutdown plan ==<br />
<br />
Hello. In the past, I have contributed to sites such as Yahoo Answers, which disappointingly ended up shutting down with little notice after operating seemingly well for a long time, i.e. over a decade.<br />
<br />
In the unlikely case that this wiki ends up shutting down at some point in future, I would like to ask whether the wiki has a backup plan. Since text compresses efficiently, will a compressed archive of users' contributions be released? And how long in advance would there be a warning? [[User:Gordon|Gordon]] ([[User talk:Gordon|talk]]) 13:13, 13 February 2022 (UTC)<br />
<br />
: Hi Gorden and welcome!<br />
: Yes, we make regular backups. There is no intention to shutdown the wiki at any point and as we are not a commercial project, we have absolutely no reason to withhold any data that you've contributed. I could imagine that at some point the contents of the wiki may be moved to a different platform (who knows what'll be available in years from now), but definitely not deleted. Note that the wiki is also occasionally archived to the [http://web.archive.org/web/*/wiki.flightgear.org* Internet Archive].<br />
: Does that give you enough reassurance to contribute?<br />
: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:25, 14 February 2022 (UTC)<br />
<br />
:: Yes, sounds good. Thanks much. As a side note, the Internet Archive saves pages' lastest revisions but not their full history. It just serves as additional surface backup. [[User:Gordon|Gordon]] ([[User talk:Gordon|talk]]) 20:48, 18 February 2022 (UTC)<br />
<br />
== 2022 Newsletters forward/backward links are broken ==<br />
<br />
Recently the chain of newsletters for 2022 appears to have been broken. There was a February newsletter and a April newsletter, but no March newsletter, and the Feb and Mar newsletters did not link to each other.<br />
<br />
In the last day or so, [[User:Aepcam]] has created a March newsletter. But the links are still not working. For example both the March and April newsletters have "Create next Edition >" links that would create a new May newsletter.<br />
<br />
See:<br />
<br />
* [[FlightGear_Newsletter_February_2022]]<br />
* [[FlightGear_Newsletter_March_2022]]<br />
* [[FlightGear_Newsletter_April_2022]]<br />
<br />
Could someone who knows how these things work, take a look?<br />
<br />
Thanks.<br />
<br />
[[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 20:16, 18 April 2022 (UTC)</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki:Village_pump&diff=134984FlightGear wiki:Village pump2022-04-18T20:30:39Z<p>Cgdae: /* 2022 Newsletters forward/backward links are broken */</p>
<hr />
<div>__NEWSECTIONLINK__<br />
{{Archives|[[/Archive 2012|2012]]|[[/Archive 2013|2013]]|[[/Archive 2014|2014]]|[[/Archive 2015|2015]]|[[/Archive 2016|2016]]|[[/Archive 2017|2017]]|[[/Archive 2018|2018]]|[[/Archive 2019|2019]]|[[/Archive 2020|2020]]}}<br />
{{shortcut|FGW:VP}}<br />
<br />
Welcome to the '''Village Pump'''. This page is used to discuss the technical issues, operations and guidelines of the [[FlightGear wiki]].<br />
<br />
Please <span class="plainlinks">[{{fullurl:{{FULLPAGENAME}}|action=edit&section=new}} add new topics]</span> to the '''bottom''' of this page.<br />
<br />
Old discussions should be moved to a [[FlightGear wiki:Village pump/Archive YEAR]]. These discussions can then be moved to a relevant talk page if appropriate.<br />
<br />
== MediaWiki updated to 1.35.1 ==<br />
Hi all,<br />
<br />
We've just updated MediaWiki (our wiki software) to version 1.35.1. The update comes with a couple of nice new features, such as [https://www.mediawiki.org/wiki/Extension:VisualEditor a visual editor] that considerably lowers the entry barrier (no need to learn wiki markup!). We've also fixed the issue that prevented users from [[FlightGear_wiki:Village_pump/Archive_2020#UTF-8_language_pages_cannot_be_edited_.28cont._from_2015.29|editing certain non-Latin articles]] and enabled TLS so your connection is now secured with HTTPS.<br />
<br />
Although we've tested the update, chances are that we've missed certain scenarios. Please let me know if something isn't working as expected.<br />
<br />
Cheers,<br />
<br />
[[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 16:59, 6 February 2021 (UTC)<br />
<br />
PS: Now that we're back in sync, you may expect more frequent updates again.<br />
<br />
: The only issues I have noted so far is that<br />
:* It seems the visual editor, when editing discussion pages, can only be used when adding a new topic, but not when editing an existing one.<br />
:* Section editing is off by default (though I think it might have been previously as well).<br />
: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 15:45, 7 February 2021 (UTC)<br />
<br />
:: Hi Johan,<br />
::* I believe that's the way they've designed it (it also works like that on Wikipedia), but I'll see if that can be changed.<br />
::* What do you mean with "section editing"? I can see <code>[ edit | edit source ]</code> links at each section title?<br />
:: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 15:57, 7 February 2021 (UTC)<br />
<br />
::: Section editing was off by default for me after the update (at least when looking in the preferences; I did open the preferences before I went through any articles).<br />
::: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 10:33, 8 February 2021 (UTC)<br />
<br />
: Thank you very much! The 6 year old UTF-8 bug is finally gone!! Everything else is looking good to me. No strange Scribuntu/lua errors from the infoboxes, SyntaxHighlight works, collapsible boxes work. Great job!<br />
<br />
: I did get one error: "Error contacting the Parsoid/RESTBase server: http-bad-status" when trying to edit. This was triggered by switching from the visual editor to the source editor using the menu bar that appears in the visual editor. But I fixed this by turning off the visual editor in my preferences.<br />
<br />
: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 21:12, 16 February 2021 (UTC)<br />
<br />
:: Hm, I cannot reproduce that here. Did it happen at a specific page? Can you try to reproduce it and provide a recipe?<br />
::[[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:37, 18 February 2021 (UTC)<br />
<br />
: Oh, just one thing if this is possible, can we have a [https://www.mediawiki.org/wiki/Manual:$wgFavicon favicon] set like the forum and the [https://flightgear.org main website]?<br />
<br />
: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 21:23, 16 February 2021 (UTC)<br />
<br />
:: Good one, done!<br />
:: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:37, 18 February 2021 (UTC)<br />
<br />
== Parameter listings in template documentation ==<br />
I noted that the skeleton examples with all parameters have been removed in some cases.<br />
<br />
I very much prefer to still having a copyable skeleton template (with prefilled month, year, and/or date when those parameters exist) before the listing of parameters, rather than having to copy a fully filled out filled out example and remove everything I do not need or have to change. It feels very unnecessary.<br />
<br />
On the other hand I do like the template data stuff very much, even though it is few extra steps.<br />
<br />
—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 11:41, 10 February 2021 (UTC)<br />
<br />
: Hi Johan,<br />
: I'm not sure if you know this, but you can now add templates through the VisualEditor. If you press "Insert > Template" from the toolbar, you get a nice popup to help you fill in the template and it can also pre-fill stuff for you (e.g., the date in [[:Template:Delete]]). The templatedata stuff on the template page is used to expand this popup form and drive the auto-fill, so most templates will not yet leverage it to the fullest. You can add/edit templatedata by clicking the "Manage TemplateData" button at the top of the edit page of templates. See the documentation at {{mediawiki|Help:TemplateData}} (that page is unfortunately quite messy, I know) and {{mediawiki|Extension:TemplateData}}. <br />
: I feel like we should encourage people as much as possible to use the VisualEditor, as it can help prevent mistakes or incomplete templates. Would this remove the need to have copy & pastable templates? Maybe we'll just have to try and see. There's lots of new stuff to discover and tweak :-)<br />
: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:20, 11 February 2021 (UTC)<br />
<br />
== Removing the "Goal" heading from template documentation ==<br />
As we will likely go through and edit most of the template documentation to replace the current documentation of template parameters with template data, I would like to also remove the ''Goal'' heading from the template documentation and move that up to being a regular lead section.<br />
<br />
I feel that the heading is largely redundant and have previously stuck to it mostly for consistency.<br />
<br />
—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 11:48, 10 February 2021 (UTC)<br />
<br />
: Agree!<br />
: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:20, 11 February 2021 (UTC)<br />
<br />
== Basic question sub page/sandbox ==<br />
<br />
Hi,<br />
New to the wiki here and hoping to contribute in some small way. I don't see any instructions (or menu options) on how to crate a sub page or sandbox in order to start drafting an article. I'll also aim to update the wiki on how to crate a sub page as it might help others with the same question.<br />
Many thanks<br />
[[User:Volador|Volador]] ([[User talk:Volador|talk]]) 08:33, 7 April 2021 (UTC)<br />
<br />
== MediaWiki updated to 1.35.3 ==<br />
We have updated MediaWiki to its latest version 1.35.3 today. Although we've tested the update, chances are that we've missed certain scenarios. Please report any issues that you may encounter.<br />
<br />
[[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:45, 23 July 2021 (UTC)<br />
<br />
== Backup and shutdown plan ==<br />
<br />
Hello. In the past, I have contributed to sites such as Yahoo Answers, which disappointingly ended up shutting down with little notice after operating seemingly well for a long time, i.e. over a decade.<br />
<br />
In the unlikely case that this wiki ends up shutting down at some point in future, I would like to ask whether the wiki has a backup plan. Since text compresses efficiently, will a compressed archive of users' contributions be released? And how long in advance would there be a warning? [[User:Gordon|Gordon]] ([[User talk:Gordon|talk]]) 13:13, 13 February 2022 (UTC)<br />
<br />
: Hi Gorden and welcome!<br />
: Yes, we make regular backups. There is no intention to shutdown the wiki at any point and as we are not a commercial project, we have absolutely no reason to withhold any data that you've contributed. I could imagine that at some point the contents of the wiki may be moved to a different platform (who knows what'll be available in years from now), but definitely not deleted. Note that the wiki is also occasionally archived to the [http://web.archive.org/web/*/wiki.flightgear.org* Internet Archive].<br />
: Does that give you enough reassurance to contribute?<br />
: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:25, 14 February 2022 (UTC)<br />
<br />
:: Yes, sounds good. Thanks much. As a side note, the Internet Archive saves pages' lastest revisions but not their full history. It just serves as additional surface backup. [[User:Gordon|Gordon]] ([[User talk:Gordon|talk]]) 20:48, 18 February 2022 (UTC)<br />
<br />
== 2022 Newsletters forward/backward links are broken ==<br />
<br />
Recently the chain of newsletters for 2022 appears to have been broken. There was a February newsletter and a April newsletter, but no March newsletter, and the Feb and Mar newsletters did not link to each other.<br />
<br />
In the last day or so, [[User:Aepcam]] has created a March newsletter. But the links are still not working. For example both the March and April newsletters have "Create next Edition >" links that would create a new May newsletter.<br />
<br />
Could someone who knows how these things work, take a look?<br />
<br />
Thanks.<br />
<br />
[[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 20:16, 18 April 2022 (UTC)</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=User_talk:Aepcam&diff=134983User talk:Aepcam2022-04-18T20:19:32Z<p>Cgdae: /* Changes to 2022 March newsletter */</p>
<hr />
<div>Hi! Are you sure it is a good way to work to create hundreds of untranslated /es page first and then start translating (which I assume you intend to do eventually:)? I must say that to me it seems more efficient (and less disrupting to the rest of folks here) to start with the important pages (e.g. the main page - though I know you have made that one already) and really make a translation before moving on to more pages. [[User:AndersG|AndersG]] 20:01, 29 September 2009 (UTC)<br />
<br />
::Hi Aepcam, if you want to help translate articles, you should probably concentrate on the most important -and most popular- pages, many other articles are not that relevant to newcomers. You may want to check out http://wiki.flightgear.org/index.php/Special:Statistics for a list of popular articles.--[[User:MILSTD|MILSTD]] 18:05, 1 October 2009 (UTC)<br />
<br />
== Ready logotypes ==<br />
<br />
Thank you for those nifty little logotypes. :-) I think it will help people find what they are looking for a little bit faster, so I helped a little bit making a template that would make for less typing and in addition automatically categorise the pages with the template.<br />
<br />
I have a slight suggestion: Why not "Aerotowable ready" (as in being able to be towed behind an aerotow) instead of "Soaring ready"? It might be a bit long word to fit in the logo, but... ;-)<br />
<br />
--[[User:Johan G|Johan G]] 19:53, 20 February 2012 (EST)<br />
<br />
:Thank you for creating category.<br />
:I was on doubts getting name's label. For sure Aerotowable is too long, however as a non native english speaker, allways I need yours feedbacks (that's help me a lot). I think aerotow can be used by twice in those aircraft that can aerotow and also in those which can be towed behind, just identificating a nexus word "Aerotow" as a sinthesis of same activity, for sure with your help we'll find a good solution if those label could be confuse.<br />
:Check News letter, I made others.<br />
:Thanks <br />
:{{unsigned2|02:17, 21 February 2012|Aepcam}}<br />
<br />
:: I will go ahead and add more similar templates for the other logotypes for now. --[[User:Johan G|Johan G]] 15:29, 21 February 2012 (EST)<br />
<br />
::: Thanks, Johan G.<br />
:::{{unsigned2|00:15, 22 February 2012|Aepcam}}<br />
<br />
=== Incorporating into aircraft infobox ===<br />
How about incorporating the templates into the aircraft infobox? IMO the current location is "wrong", as those logos (no matter how nice they are) are certainly not the most important thing of the entire article (placed all the way on top). Incorporating them with the rest of the aircraft info (status rating, type etc.) in the infobox would make it a lot clearer I think...<br />
<br />
[[User:Gijs|Gijs]] 07:25, 18 March 2012 (EDT)<br />
<br />
PS, please sign your messages on talk pages with <code><nowiki>~~~~</nowiki></code>.<br />
<br />
: I'm totally agree in to incorporate the templates into aircraft infobox. I was thinking so when I'd created it, however those are placed on top (not for the importance) just for first approval look, easy to remove using first line code. <br />
: Because the diversity of aircrafts infoboxes, we should unified to the last one I think you made, but how, I don't know, but you count with my help.<br />
: [[User:Aepcam|Aepcam]] 01:56, 19 March 2012 (EDT) Michat<br />
<br />
:: You both have a point there. Thanks for the input Gijs. (I added some indentation to parts of your post Aepcam. I hope you don't mind). <br />
:: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 06:54, 19 March 2012 (EDT)<br />
<br />
:: As far as I know there's just one aircraft infobox? Anyway, I've added the ready icons option to it. All you need to do is add something like <code>|ready = bombable/airrefuel</code> to the infobox. And delete the old image of course ;) All available options can be seen at {{tl|Infobox Aircraft}}. To add new icons, look at {{tl|Ready}}.<br />
:: [[User:Gijs|Gijs]] 13:51, 19 March 2012 (EDT)<br />
<br />
::: I'm testing infobox icon at [[Douglas A-4 Skyhawk]] with bad results because an image size variation causes that the result is not well legible :(<br />
::: Do you now if is possible by clicking infobox icon to go directly to the respective category group page.?<br />
::: Do you create the dual control icon category? if so what is the name of it. It was the first I tried to, but i didn't find its name.<br />
::: Thats all for the moment, your feedback will be appreciated cause coding isn't my strong point.<br />
:::[[User:Aepcam|Aepcam]] 15:39, 19 March 2012 (EDT) Michat<br />
<br />
:::: The system is in {{tl|Ready}} (click it to visit the template page, where it is explained how to add new icons). I did forget the dual control icon, added now. I'll link the icons to the category, good idea!<br />
:::: [[User:Gijs|Gijs]] 15:43, 19 March 2012 (EDT)<br />
<br />
::: please consider to make a first example of a complete infobox, so I can follow your procedure. :) thanks<br />
::: [[User:Aepcam|Aepcam]] 15:48, 19 March 2012 (EDT) Michat<br />
<br />
:::: See [[Schleicher ASK 13]] for an example of two icons. You can add all icons, but I don't think we've got an aircraft that fits all... :)<br />
:::: Oh and please use the "Show preview" button before saving a page. If you're just interested in how something looks/works, it's not needed to save the page (and thus eat up server space). Previews are free, and help a lot in saving space and making the history of articles clear.<br />
:::: [[User:Gijs|Gijs]] 15:53, 19 March 2012 (EDT)<br />
<br />
::::: Thanks I'll following ask 13 example. I'll use preview, anyway I'm so afraid at saving/preview moments cause is not the first time I lost long update on an expire session. Thanks for you help Gijs. <br />
::::: [[User:Aepcam|Aepcam]] 16:02, 19 March 2012 (EDT) Michat<br />
<br />
::: Everything is updated, now I have to modify dual control icon, it seems to be bigger than others. :) thanks for you tips<br />
::: [[User:Aepcam|Aepcam]] 17:16, 19 March 2012 (EDT) Michat<br />
<br />
:::: resolved dual control image size difference. Now Its OK. Many thanks.:)<br />
:::: {{unsigned|22:40, 19 March 2012|Aepcam}}<br />
<br />
::: Glad to see that everything worked out well! We can always improve it if we want so. <br />
::: [[User:Gijs|Gijs]] 17:56, 19 March 2012 (EDT)<br />
<br />
::: Gijs, please can you also create ready cat. for the aircraft of the month. I should remove all aircraft of the month's icons in those awarded aircraft pages, but I need that category in order to include those icons on infobox as we did before with other categories. Thanks by anticipate.<br />
::: Best regards... Michat<br />
::: [[User:Aepcam|Aepcam]] 00:26, 11 April 2012 (EDT)<br />
<br />
:::: {{done}} ;)<br />
:::: [[User:Gijs|Gijs]] 05:30, 11 April 2012 (EDT)<br />
<br />
=== Language Support ===<br />
:::: Hi GIJS, this is Michat. I'm suffering serious problems with my PC. Actually I can only use wiki from a neighbourg PC with very low connection speed. I have open a discussion here [[Talk:FlightGear Newsletter May 2012]] , but I thinking that nobody read it yet.<br />
Can you please take a look on it ? <br />
<br />
Okay I'll try to repair and boot my PC, but it seems no good. :( <br />
Thanks<br />
<br />
Michat [[User:Aepcam|Aepcam]] 07:00, 23 May 2012 (EDT)<br />
<br />
== FGTour/Embassy ==<br />
Hi,<br />
<br />
could you please have a look at the question posed at [[Talk:Portal:FGembassyTour]], before continuouning all the hard work?<br />
<br />
Thanks!<br />
[[User:Gijs|Gijs]] 15:51, 3 January 2013 (EST)<br />
<br />
: Hi, I have answered it know, I din't see it.<br />
: Thanks Gijs<br />
: [[User:Aepcam|Aepcam]] 18:28, 3 January 2013 (EST)<br />
<br />
:: Hi again,<br />
:: All images that you've uploaded recently have either copyright violations, wrong sources or both. I'll delete them if that isn't fixed before the weekend.<br />
:: Cheers,<br />
:: [[User:Gijs|Gijs]] 10:28, 8 January 2013 (EST)<br />
<br />
== Renaming articles ==<br />
<br />
Hi,<br />
<br />
the wiki has a feature to rename articles. When you click the little triangle next to the search field and select "Move", you can enter the new name of the article. This way, we preserve the history of an article. In contrast to creating a new article and deleting the old one. ;-)<br />
<br />
I've fixed this for the Spanish altitude article.<br />
<br />
Thanks!<br />
[[User:Gijs|Gijs]] 15:28, 17 April 2013 (UTC)<br />
<br />
: Hi<br />
: Thanks for the tip Gijs, I'll check the way you did it.<br />
: Understand that feature is also changes the old way that we had using redirect when mistakes on title occurred. ?<br />
: I understand that if we change title page links will not been broken. Is that correct?<br />
: Now I'm trying a shared laptop, its quite horrible to use finger pad, I lost today's big wiki segment due to electrostatic. Sorry if I decided to save often. Finger pad is able to close almost PC session just with a pullover touch contact....<br />
: Michat<br />
: [[User:Aepcam|Aepcam]] 15:47, 17 April 2013 (UTC)<br />
<br />
:: Yes, when moving an article, the old page becomes a redirect to the new. And next to that it also takes care of talk pages, so it's a wonderful feature :-)<br />
:: [[User:Gijs|Gijs]] 16:12, 17 April 2013 (UTC)<br />
<br />
<br />
. . . . . .<br />
<br />
Indeed ;)<br />
Michat<br />
[[User:Aepcam|Aepcam]] 16:37, 17 April 2013 (UTC)<br />
<br />
== Map icons ==<br />
<br />
Hi,<br />
<br />
please take a look at Hooray's comment at [[File talk:Radioaidstonavnondirectionalradiobeaconsmallwithrwy.png]]<br />
<br />
Cheers,<br />
[[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 12:05, 29 March 2014 (UTC)<br />
<br />
== The Antonov aircraft ==<br />
My apologies for being a bit slow on moving around the Antonov aircraft. It seems {{usr|Gijs}} did the bulk of that job.<br />
<br />
—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 14:47, 14 May 2015 (EDT)<br />
<br />
[[User:Aepcam|Aepcam]] ([[User talk:Aepcam|talk]]) 20:38, 14 May 2015 (EDT)<br />
<br />
Very appreciated, thank you both.<br />
Michat<br />
<br />
== Changes to 2022 March newsletter ==<br />
<br />
Hi, your recent changes to https://wiki.flightgear.org/FlightGear_Newsletter_March_2022 appear to have removed two items:<br />
<br />
* YASim now supports torus contact surfaces for landing gear<br />
* Pipistrel's electric trainer aircraft<br />
<br />
Was this intentional?<br />
<br />
[[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 19:18, 18 April 2022 (UTC)<br />
<br />
<br />
Ah, i see that the information is still on the next newsletter, https://wiki.flightgear.org/FlightGear_Newsletter_April_2022. So you're quite right to exclude the information from the March newsletter. Thanks for clarifying.<br />
<br />
I was confused because the March newsletter (that i think you created?) does not have a link to the April newsletter (so i thought it was the new latest newsletter) - instead it has a link saying "Create next Edition >" which creates a new '''May''' newsletter. Presumably the wiki template system's database has got messed up, but i've no idea how to fix things.<br />
<br />
Thanks again.<br />
<br />
[[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 20:05, 18 April 2022 (UTC)<br />
<br />
FYI i've asked for someone to take a look at this, see: [[FlightGear_wiki:Village_pump#2022_Newsletters_forward.2Fbackward_links_are_broken]]<br />
<br />
[[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 20:19, 18 April 2022 (UTC)</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=FlightGear_wiki:Village_pump&diff=134982FlightGear wiki:Village pump2022-04-18T20:16:56Z<p>Cgdae: /* 2022 Newsletters forward/backward links are broken */ new section</p>
<hr />
<div>__NEWSECTIONLINK__<br />
{{Archives|[[/Archive 2012|2012]]|[[/Archive 2013|2013]]|[[/Archive 2014|2014]]|[[/Archive 2015|2015]]|[[/Archive 2016|2016]]|[[/Archive 2017|2017]]|[[/Archive 2018|2018]]|[[/Archive 2019|2019]]|[[/Archive 2020|2020]]}}<br />
{{shortcut|FGW:VP}}<br />
<br />
Welcome to the '''Village Pump'''. This page is used to discuss the technical issues, operations and guidelines of the [[FlightGear wiki]].<br />
<br />
Please <span class="plainlinks">[{{fullurl:{{FULLPAGENAME}}|action=edit&section=new}} add new topics]</span> to the '''bottom''' of this page.<br />
<br />
Old discussions should be moved to a [[FlightGear wiki:Village pump/Archive YEAR]]. These discussions can then be moved to a relevant talk page if appropriate.<br />
<br />
== MediaWiki updated to 1.35.1 ==<br />
Hi all,<br />
<br />
We've just updated MediaWiki (our wiki software) to version 1.35.1. The update comes with a couple of nice new features, such as [https://www.mediawiki.org/wiki/Extension:VisualEditor a visual editor] that considerably lowers the entry barrier (no need to learn wiki markup!). We've also fixed the issue that prevented users from [[FlightGear_wiki:Village_pump/Archive_2020#UTF-8_language_pages_cannot_be_edited_.28cont._from_2015.29|editing certain non-Latin articles]] and enabled TLS so your connection is now secured with HTTPS.<br />
<br />
Although we've tested the update, chances are that we've missed certain scenarios. Please let me know if something isn't working as expected.<br />
<br />
Cheers,<br />
<br />
[[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 16:59, 6 February 2021 (UTC)<br />
<br />
PS: Now that we're back in sync, you may expect more frequent updates again.<br />
<br />
: The only issues I have noted so far is that<br />
:* It seems the visual editor, when editing discussion pages, can only be used when adding a new topic, but not when editing an existing one.<br />
:* Section editing is off by default (though I think it might have been previously as well).<br />
: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 15:45, 7 February 2021 (UTC)<br />
<br />
:: Hi Johan,<br />
::* I believe that's the way they've designed it (it also works like that on Wikipedia), but I'll see if that can be changed.<br />
::* What do you mean with "section editing"? I can see <code>[ edit | edit source ]</code> links at each section title?<br />
:: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 15:57, 7 February 2021 (UTC)<br />
<br />
::: Section editing was off by default for me after the update (at least when looking in the preferences; I did open the preferences before I went through any articles).<br />
::: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 10:33, 8 February 2021 (UTC)<br />
<br />
: Thank you very much! The 6 year old UTF-8 bug is finally gone!! Everything else is looking good to me. No strange Scribuntu/lua errors from the infoboxes, SyntaxHighlight works, collapsible boxes work. Great job!<br />
<br />
: I did get one error: "Error contacting the Parsoid/RESTBase server: http-bad-status" when trying to edit. This was triggered by switching from the visual editor to the source editor using the menu bar that appears in the visual editor. But I fixed this by turning off the visual editor in my preferences.<br />
<br />
: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 21:12, 16 February 2021 (UTC)<br />
<br />
:: Hm, I cannot reproduce that here. Did it happen at a specific page? Can you try to reproduce it and provide a recipe?<br />
::[[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:37, 18 February 2021 (UTC)<br />
<br />
: Oh, just one thing if this is possible, can we have a [https://www.mediawiki.org/wiki/Manual:$wgFavicon favicon] set like the forum and the [https://flightgear.org main website]?<br />
<br />
: [[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 21:23, 16 February 2021 (UTC)<br />
<br />
:: Good one, done!<br />
:: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:37, 18 February 2021 (UTC)<br />
<br />
== Parameter listings in template documentation ==<br />
I noted that the skeleton examples with all parameters have been removed in some cases.<br />
<br />
I very much prefer to still having a copyable skeleton template (with prefilled month, year, and/or date when those parameters exist) before the listing of parameters, rather than having to copy a fully filled out filled out example and remove everything I do not need or have to change. It feels very unnecessary.<br />
<br />
On the other hand I do like the template data stuff very much, even though it is few extra steps.<br />
<br />
—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 11:41, 10 February 2021 (UTC)<br />
<br />
: Hi Johan,<br />
: I'm not sure if you know this, but you can now add templates through the VisualEditor. If you press "Insert > Template" from the toolbar, you get a nice popup to help you fill in the template and it can also pre-fill stuff for you (e.g., the date in [[:Template:Delete]]). The templatedata stuff on the template page is used to expand this popup form and drive the auto-fill, so most templates will not yet leverage it to the fullest. You can add/edit templatedata by clicking the "Manage TemplateData" button at the top of the edit page of templates. See the documentation at {{mediawiki|Help:TemplateData}} (that page is unfortunately quite messy, I know) and {{mediawiki|Extension:TemplateData}}. <br />
: I feel like we should encourage people as much as possible to use the VisualEditor, as it can help prevent mistakes or incomplete templates. Would this remove the need to have copy & pastable templates? Maybe we'll just have to try and see. There's lots of new stuff to discover and tweak :-)<br />
: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:20, 11 February 2021 (UTC)<br />
<br />
== Removing the "Goal" heading from template documentation ==<br />
As we will likely go through and edit most of the template documentation to replace the current documentation of template parameters with template data, I would like to also remove the ''Goal'' heading from the template documentation and move that up to being a regular lead section.<br />
<br />
I feel that the heading is largely redundant and have previously stuck to it mostly for consistency.<br />
<br />
—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 11:48, 10 February 2021 (UTC)<br />
<br />
: Agree!<br />
: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:20, 11 February 2021 (UTC)<br />
<br />
== Basic question sub page/sandbox ==<br />
<br />
Hi,<br />
New to the wiki here and hoping to contribute in some small way. I don't see any instructions (or menu options) on how to crate a sub page or sandbox in order to start drafting an article. I'll also aim to update the wiki on how to crate a sub page as it might help others with the same question.<br />
Many thanks<br />
[[User:Volador|Volador]] ([[User talk:Volador|talk]]) 08:33, 7 April 2021 (UTC)<br />
<br />
== MediaWiki updated to 1.35.3 ==<br />
We have updated MediaWiki to its latest version 1.35.3 today. Although we've tested the update, chances are that we've missed certain scenarios. Please report any issues that you may encounter.<br />
<br />
[[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:45, 23 July 2021 (UTC)<br />
<br />
== Backup and shutdown plan ==<br />
<br />
Hello. In the past, I have contributed to sites such as Yahoo Answers, which disappointingly ended up shutting down with little notice after operating seemingly well for a long time, i.e. over a decade.<br />
<br />
In the unlikely case that this wiki ends up shutting down at some point in future, I would like to ask whether the wiki has a backup plan. Since text compresses efficiently, will a compressed archive of users' contributions be released? And how long in advance would there be a warning? [[User:Gordon|Gordon]] ([[User talk:Gordon|talk]]) 13:13, 13 February 2022 (UTC)<br />
<br />
: Hi Gorden and welcome!<br />
: Yes, we make regular backups. There is no intention to shutdown the wiki at any point and as we are not a commercial project, we have absolutely no reason to withhold any data that you've contributed. I could imagine that at some point the contents of the wiki may be moved to a different platform (who knows what'll be available in years from now), but definitely not deleted. Note that the wiki is also occasionally archived to the [http://web.archive.org/web/*/wiki.flightgear.org* Internet Archive].<br />
: Does that give you enough reassurance to contribute?<br />
: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 10:25, 14 February 2022 (UTC)<br />
<br />
:: Yes, sounds good. Thanks much. As a side note, the Internet Archive saves pages' lastest revisions but not their full history. It just serves as additional surface backup. [[User:Gordon|Gordon]] ([[User talk:Gordon|talk]]) 20:48, 18 February 2022 (UTC)<br />
<br />
== 2022 Newsletters forward/backward links are broken ==<br />
<br />
Recently the chain of newsletters for 2022 appears to have been broken. There was a February newsletter and a April newsletter, but no March newsletter, and the Feb and Mar newsletters did not link to each other.<br />
<br />
In the last day or so, [[talk:Aepcam]] has created a March newsletter. But the links are still not working. For example both the March and April newsletters have "Create next Edition >" links that would create a new May newsletter.<br />
<br />
Could someone who knows how these things work, take a look?<br />
<br />
Thanks.<br />
<br />
[[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 20:16, 18 April 2022 (UTC)</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=User_talk:Aepcam&diff=134981User talk:Aepcam2022-04-18T20:06:03Z<p>Cgdae: /* Changes to 2022 March newsletter */</p>
<hr />
<div>Hi! Are you sure it is a good way to work to create hundreds of untranslated /es page first and then start translating (which I assume you intend to do eventually:)? I must say that to me it seems more efficient (and less disrupting to the rest of folks here) to start with the important pages (e.g. the main page - though I know you have made that one already) and really make a translation before moving on to more pages. [[User:AndersG|AndersG]] 20:01, 29 September 2009 (UTC)<br />
<br />
::Hi Aepcam, if you want to help translate articles, you should probably concentrate on the most important -and most popular- pages, many other articles are not that relevant to newcomers. You may want to check out http://wiki.flightgear.org/index.php/Special:Statistics for a list of popular articles.--[[User:MILSTD|MILSTD]] 18:05, 1 October 2009 (UTC)<br />
<br />
== Ready logotypes ==<br />
<br />
Thank you for those nifty little logotypes. :-) I think it will help people find what they are looking for a little bit faster, so I helped a little bit making a template that would make for less typing and in addition automatically categorise the pages with the template.<br />
<br />
I have a slight suggestion: Why not "Aerotowable ready" (as in being able to be towed behind an aerotow) instead of "Soaring ready"? It might be a bit long word to fit in the logo, but... ;-)<br />
<br />
--[[User:Johan G|Johan G]] 19:53, 20 February 2012 (EST)<br />
<br />
:Thank you for creating category.<br />
:I was on doubts getting name's label. For sure Aerotowable is too long, however as a non native english speaker, allways I need yours feedbacks (that's help me a lot). I think aerotow can be used by twice in those aircraft that can aerotow and also in those which can be towed behind, just identificating a nexus word "Aerotow" as a sinthesis of same activity, for sure with your help we'll find a good solution if those label could be confuse.<br />
:Check News letter, I made others.<br />
:Thanks <br />
:{{unsigned2|02:17, 21 February 2012|Aepcam}}<br />
<br />
:: I will go ahead and add more similar templates for the other logotypes for now. --[[User:Johan G|Johan G]] 15:29, 21 February 2012 (EST)<br />
<br />
::: Thanks, Johan G.<br />
:::{{unsigned2|00:15, 22 February 2012|Aepcam}}<br />
<br />
=== Incorporating into aircraft infobox ===<br />
How about incorporating the templates into the aircraft infobox? IMO the current location is "wrong", as those logos (no matter how nice they are) are certainly not the most important thing of the entire article (placed all the way on top). Incorporating them with the rest of the aircraft info (status rating, type etc.) in the infobox would make it a lot clearer I think...<br />
<br />
[[User:Gijs|Gijs]] 07:25, 18 March 2012 (EDT)<br />
<br />
PS, please sign your messages on talk pages with <code><nowiki>~~~~</nowiki></code>.<br />
<br />
: I'm totally agree in to incorporate the templates into aircraft infobox. I was thinking so when I'd created it, however those are placed on top (not for the importance) just for first approval look, easy to remove using first line code. <br />
: Because the diversity of aircrafts infoboxes, we should unified to the last one I think you made, but how, I don't know, but you count with my help.<br />
: [[User:Aepcam|Aepcam]] 01:56, 19 March 2012 (EDT) Michat<br />
<br />
:: You both have a point there. Thanks for the input Gijs. (I added some indentation to parts of your post Aepcam. I hope you don't mind). <br />
:: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 06:54, 19 March 2012 (EDT)<br />
<br />
:: As far as I know there's just one aircraft infobox? Anyway, I've added the ready icons option to it. All you need to do is add something like <code>|ready = bombable/airrefuel</code> to the infobox. And delete the old image of course ;) All available options can be seen at {{tl|Infobox Aircraft}}. To add new icons, look at {{tl|Ready}}.<br />
:: [[User:Gijs|Gijs]] 13:51, 19 March 2012 (EDT)<br />
<br />
::: I'm testing infobox icon at [[Douglas A-4 Skyhawk]] with bad results because an image size variation causes that the result is not well legible :(<br />
::: Do you now if is possible by clicking infobox icon to go directly to the respective category group page.?<br />
::: Do you create the dual control icon category? if so what is the name of it. It was the first I tried to, but i didn't find its name.<br />
::: Thats all for the moment, your feedback will be appreciated cause coding isn't my strong point.<br />
:::[[User:Aepcam|Aepcam]] 15:39, 19 March 2012 (EDT) Michat<br />
<br />
:::: The system is in {{tl|Ready}} (click it to visit the template page, where it is explained how to add new icons). I did forget the dual control icon, added now. I'll link the icons to the category, good idea!<br />
:::: [[User:Gijs|Gijs]] 15:43, 19 March 2012 (EDT)<br />
<br />
::: please consider to make a first example of a complete infobox, so I can follow your procedure. :) thanks<br />
::: [[User:Aepcam|Aepcam]] 15:48, 19 March 2012 (EDT) Michat<br />
<br />
:::: See [[Schleicher ASK 13]] for an example of two icons. You can add all icons, but I don't think we've got an aircraft that fits all... :)<br />
:::: Oh and please use the "Show preview" button before saving a page. If you're just interested in how something looks/works, it's not needed to save the page (and thus eat up server space). Previews are free, and help a lot in saving space and making the history of articles clear.<br />
:::: [[User:Gijs|Gijs]] 15:53, 19 March 2012 (EDT)<br />
<br />
::::: Thanks I'll following ask 13 example. I'll use preview, anyway I'm so afraid at saving/preview moments cause is not the first time I lost long update on an expire session. Thanks for you help Gijs. <br />
::::: [[User:Aepcam|Aepcam]] 16:02, 19 March 2012 (EDT) Michat<br />
<br />
::: Everything is updated, now I have to modify dual control icon, it seems to be bigger than others. :) thanks for you tips<br />
::: [[User:Aepcam|Aepcam]] 17:16, 19 March 2012 (EDT) Michat<br />
<br />
:::: resolved dual control image size difference. Now Its OK. Many thanks.:)<br />
:::: {{unsigned|22:40, 19 March 2012|Aepcam}}<br />
<br />
::: Glad to see that everything worked out well! We can always improve it if we want so. <br />
::: [[User:Gijs|Gijs]] 17:56, 19 March 2012 (EDT)<br />
<br />
::: Gijs, please can you also create ready cat. for the aircraft of the month. I should remove all aircraft of the month's icons in those awarded aircraft pages, but I need that category in order to include those icons on infobox as we did before with other categories. Thanks by anticipate.<br />
::: Best regards... Michat<br />
::: [[User:Aepcam|Aepcam]] 00:26, 11 April 2012 (EDT)<br />
<br />
:::: {{done}} ;)<br />
:::: [[User:Gijs|Gijs]] 05:30, 11 April 2012 (EDT)<br />
<br />
=== Language Support ===<br />
:::: Hi GIJS, this is Michat. I'm suffering serious problems with my PC. Actually I can only use wiki from a neighbourg PC with very low connection speed. I have open a discussion here [[Talk:FlightGear Newsletter May 2012]] , but I thinking that nobody read it yet.<br />
Can you please take a look on it ? <br />
<br />
Okay I'll try to repair and boot my PC, but it seems no good. :( <br />
Thanks<br />
<br />
Michat [[User:Aepcam|Aepcam]] 07:00, 23 May 2012 (EDT)<br />
<br />
== FGTour/Embassy ==<br />
Hi,<br />
<br />
could you please have a look at the question posed at [[Talk:Portal:FGembassyTour]], before continuouning all the hard work?<br />
<br />
Thanks!<br />
[[User:Gijs|Gijs]] 15:51, 3 January 2013 (EST)<br />
<br />
: Hi, I have answered it know, I din't see it.<br />
: Thanks Gijs<br />
: [[User:Aepcam|Aepcam]] 18:28, 3 January 2013 (EST)<br />
<br />
:: Hi again,<br />
:: All images that you've uploaded recently have either copyright violations, wrong sources or both. I'll delete them if that isn't fixed before the weekend.<br />
:: Cheers,<br />
:: [[User:Gijs|Gijs]] 10:28, 8 January 2013 (EST)<br />
<br />
== Renaming articles ==<br />
<br />
Hi,<br />
<br />
the wiki has a feature to rename articles. When you click the little triangle next to the search field and select "Move", you can enter the new name of the article. This way, we preserve the history of an article. In contrast to creating a new article and deleting the old one. ;-)<br />
<br />
I've fixed this for the Spanish altitude article.<br />
<br />
Thanks!<br />
[[User:Gijs|Gijs]] 15:28, 17 April 2013 (UTC)<br />
<br />
: Hi<br />
: Thanks for the tip Gijs, I'll check the way you did it.<br />
: Understand that feature is also changes the old way that we had using redirect when mistakes on title occurred. ?<br />
: I understand that if we change title page links will not been broken. Is that correct?<br />
: Now I'm trying a shared laptop, its quite horrible to use finger pad, I lost today's big wiki segment due to electrostatic. Sorry if I decided to save often. Finger pad is able to close almost PC session just with a pullover touch contact....<br />
: Michat<br />
: [[User:Aepcam|Aepcam]] 15:47, 17 April 2013 (UTC)<br />
<br />
:: Yes, when moving an article, the old page becomes a redirect to the new. And next to that it also takes care of talk pages, so it's a wonderful feature :-)<br />
:: [[User:Gijs|Gijs]] 16:12, 17 April 2013 (UTC)<br />
<br />
<br />
. . . . . .<br />
<br />
Indeed ;)<br />
Michat<br />
[[User:Aepcam|Aepcam]] 16:37, 17 April 2013 (UTC)<br />
<br />
== Map icons ==<br />
<br />
Hi,<br />
<br />
please take a look at Hooray's comment at [[File talk:Radioaidstonavnondirectionalradiobeaconsmallwithrwy.png]]<br />
<br />
Cheers,<br />
[[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 12:05, 29 March 2014 (UTC)<br />
<br />
== The Antonov aircraft ==<br />
My apologies for being a bit slow on moving around the Antonov aircraft. It seems {{usr|Gijs}} did the bulk of that job.<br />
<br />
—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 14:47, 14 May 2015 (EDT)<br />
<br />
[[User:Aepcam|Aepcam]] ([[User talk:Aepcam|talk]]) 20:38, 14 May 2015 (EDT)<br />
<br />
Very appreciated, thank you both.<br />
Michat<br />
<br />
== Changes to 2022 March newsletter ==<br />
<br />
Hi, your recent changes to https://wiki.flightgear.org/FlightGear_Newsletter_March_2022 appear to have removed two items:<br />
<br />
* YASim now supports torus contact surfaces for landing gear<br />
* Pipistrel's electric trainer aircraft<br />
<br />
Was this intentional?<br />
<br />
[[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 19:18, 18 April 2022 (UTC)<br />
<br />
<br />
Ah, i see that the information is still on the next newsletter, https://wiki.flightgear.org/FlightGear_Newsletter_April_2022. So you're quite right to exclude the information from the March newsletter. Thanks for clarifying.<br />
<br />
I was confused because the March newsletter (that i think you created?) does not have a link to the April newsletter (so i thought it was the new latest newsletter) - instead it has a link saying "Create next Edition >" which creates a new '''May''' newsletter. Presumably the wiki template system's database has got messed up, but i've no idea how to fix things.<br />
<br />
Thanks again.<br />
<br />
[[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 20:05, 18 April 2022 (UTC)</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=Video_encoding&diff=134979Video encoding2022-04-18T19:47:32Z<p>Cgdae: /* Building */</p>
<hr />
<div>== Overview ==<br />
<br />
Flightgear on next (the development branch) has support for video encoding of the main window. This requires that ffmpeg/libav libraries are available at build time.<br />
<br />
* Videos are generated in the current directory. This can be changed by setting property '''/sim/video/directory'''.<br />
* Video files are called '''fgvideo-<aircraft>-YYYYMMDD-HHMMSS.<container>''', for example '''fgvideo-harrier-gr3-20211209-234105.mp4'''.<br />
* A convenience link is created that points to the latest video, called '''fgvideo-<aircraft>.<container>''', for example '''fgvideo-harrier-gr3.mp4''' -> '''fgvideo-harrier-gr3-20211209-234105.mp4'''.<br />
<br />
== Limitations ==<br />
<br />
* As of 2021-12-12, only Unix builds of Flightgear include support for video encoding by default.<br />
** On other platforms, if ffmpeg libraries are installed on the system, Flightgear's cmake might pick them up automatically and enable video encoding, but this hasn't been tested.<br />
* We do not (yet) record sound.<br />
<br />
== Building ==<br />
<br />
On Unix, we require these libraries and their header files to be available at build time:<br />
<br />
* avcodec<br />
* avutil<br />
* swscale<br />
* avformat<br />
<br />
If these libraries and header files are installed, a standard cmake build should automatically include video encoding support.<br />
<br />
As of 2021-12-27, [[Scripted_Compilation_on_Linux_Debian/Ubuntu|download_and_compile.sh]] installs these libraries automatically.<br />
<br />
On Devuan (and probably other Debian-based distributions), they can be manually installed with:<br />
<br />
sudo apt install libavcodec-dev libavutil-dev libswscale-dev libavformat-dev<br />
<br />
== Creating video of live Flightgear ==<br />
<br />
=== Starting/stopping video encoding ===<br />
<br />
Use menu items '''File/Video Start''' and '''File/Video Stop''' to start/stop video encoding.<br />
<br />
* If an error occurs, for example support for video encoding was not included at build time, Flightgear will show a popup warning message.<br />
<br />
=== Video encoding settings ===<br />
[[File:Video-control dialogue.png|thumb]]<br />
Menu '''File/Video Control''' opens a dialogue that allows control over various settings, including:<br />
<br />
* Container name, such as '''mp4''' or '''ogv'''.<br />
** Radio buttons are provided for common containers.<br />
** Run '''ffmpeg -formats''' in a separate terminal to see what containers are available on your system.<br />
* Codec name, such as '''mpeg2video''', '''libx264''', '''libx265'''.<br />
** Radio buttons are provided for common codecs.<br />
** Run '''ffmpeg -codecs''' in a separate terminal to see what codecs are available on your system.<br />
* Encoding quality in range '''0..1'''. Use '''-1''' for codec's default.<br />
* Encoding speed in range '''0..1'''. Use '''-1''' for codec's default.<br />
* Encoding target bitrate in bits per second. Use '''0''' for codec's default.<br />
<br />
== Creating video from Flightgear recordings ==<br />
<br />
Flightgear can automatically generate a video when replaying a recording file, stopping video encoding when we reach the end of the recording.<br />
<br />
Usually one would use a Continuous recording for this, as they contain full information regardless of the recording duration.<br />
<br />
* From within Flightgear:<br />
** In the '''Load Flight Recorder Tape''' dialogue, set the '''Auto-create video''' checkbox.<br />
** Optionally also set '''Fixed dt''' (see below).<br />
<br />
* With the command line '''--load-tape''' option:<br />
** Also specify '''--load-tape-create-video'''.<br />
** Optionally specify '''--load-tape-fixed-dt=...''' (see below).<br />
<br />
=== Using '''fixed-dt''' ===<br />
<br />
Setting '''fixed-dt''' to a non-zero value forces Flightgear to increment the FDM time in seconds by the specified amount each frame, instead of by the elapsed real-world time between frames. For example using a value of 0.04 will force a frame rate of 25fps.<br />
<br />
This allows creation of high quality videos from recordings, regardless of the rendering settings or speed of the host, at the expense of potentially taking longer than real time to create the recording.<br />
<br />
=== Command line examples ===<br />
<br />
Create a high quality video of a recording by running Flightgear with these command-line args:<br />
<br />
'''--load-tape=... --load-tape-create-video=1 --prop:bool:/sim/time/simple-time/enabled=true --load-tape-fixed-dt=0.04 --graphics-preset=high-quality'''<br />
<br />
Also fix video settings by setting the relevant properties:<br />
<br />
'''--load-tape=... --load-tape-create-video=1 --prop:bool:/sim/time/simple-time/enabled=true --load-tape-fixed-dt=0.04 --graphics-preset=high-quality --prop:/sim/video/container=mp4 --prop:/sim/video/codec=libx265 --prop:/sim/video/quality=0.75 --prop:/sim/video/speed=1'''<br />
<br />
=== Example video ===<br />
<br />
This 5 minute video flying around Manhattan with high rendering settings was created on a fairly slow laptop, taking about an hour to replay and encode: http://op59.net/fgvideo-harrier-gr3-20211206-230342-manhattan.mp4</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=User_talk:Aepcam&diff=134977User talk:Aepcam2022-04-18T19:18:15Z<p>Cgdae: /* Changes to 2022 March newsletter */ new section</p>
<hr />
<div>Hi! Are you sure it is a good way to work to create hundreds of untranslated /es page first and then start translating (which I assume you intend to do eventually:)? I must say that to me it seems more efficient (and less disrupting to the rest of folks here) to start with the important pages (e.g. the main page - though I know you have made that one already) and really make a translation before moving on to more pages. [[User:AndersG|AndersG]] 20:01, 29 September 2009 (UTC)<br />
<br />
::Hi Aepcam, if you want to help translate articles, you should probably concentrate on the most important -and most popular- pages, many other articles are not that relevant to newcomers. You may want to check out http://wiki.flightgear.org/index.php/Special:Statistics for a list of popular articles.--[[User:MILSTD|MILSTD]] 18:05, 1 October 2009 (UTC)<br />
<br />
== Ready logotypes ==<br />
<br />
Thank you for those nifty little logotypes. :-) I think it will help people find what they are looking for a little bit faster, so I helped a little bit making a template that would make for less typing and in addition automatically categorise the pages with the template.<br />
<br />
I have a slight suggestion: Why not "Aerotowable ready" (as in being able to be towed behind an aerotow) instead of "Soaring ready"? It might be a bit long word to fit in the logo, but... ;-)<br />
<br />
--[[User:Johan G|Johan G]] 19:53, 20 February 2012 (EST)<br />
<br />
:Thank you for creating category.<br />
:I was on doubts getting name's label. For sure Aerotowable is too long, however as a non native english speaker, allways I need yours feedbacks (that's help me a lot). I think aerotow can be used by twice in those aircraft that can aerotow and also in those which can be towed behind, just identificating a nexus word "Aerotow" as a sinthesis of same activity, for sure with your help we'll find a good solution if those label could be confuse.<br />
:Check News letter, I made others.<br />
:Thanks <br />
:{{unsigned2|02:17, 21 February 2012|Aepcam}}<br />
<br />
:: I will go ahead and add more similar templates for the other logotypes for now. --[[User:Johan G|Johan G]] 15:29, 21 February 2012 (EST)<br />
<br />
::: Thanks, Johan G.<br />
:::{{unsigned2|00:15, 22 February 2012|Aepcam}}<br />
<br />
=== Incorporating into aircraft infobox ===<br />
How about incorporating the templates into the aircraft infobox? IMO the current location is "wrong", as those logos (no matter how nice they are) are certainly not the most important thing of the entire article (placed all the way on top). Incorporating them with the rest of the aircraft info (status rating, type etc.) in the infobox would make it a lot clearer I think...<br />
<br />
[[User:Gijs|Gijs]] 07:25, 18 March 2012 (EDT)<br />
<br />
PS, please sign your messages on talk pages with <code><nowiki>~~~~</nowiki></code>.<br />
<br />
: I'm totally agree in to incorporate the templates into aircraft infobox. I was thinking so when I'd created it, however those are placed on top (not for the importance) just for first approval look, easy to remove using first line code. <br />
: Because the diversity of aircrafts infoboxes, we should unified to the last one I think you made, but how, I don't know, but you count with my help.<br />
: [[User:Aepcam|Aepcam]] 01:56, 19 March 2012 (EDT) Michat<br />
<br />
:: You both have a point there. Thanks for the input Gijs. (I added some indentation to parts of your post Aepcam. I hope you don't mind). <br />
:: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 06:54, 19 March 2012 (EDT)<br />
<br />
:: As far as I know there's just one aircraft infobox? Anyway, I've added the ready icons option to it. All you need to do is add something like <code>|ready = bombable/airrefuel</code> to the infobox. And delete the old image of course ;) All available options can be seen at {{tl|Infobox Aircraft}}. To add new icons, look at {{tl|Ready}}.<br />
:: [[User:Gijs|Gijs]] 13:51, 19 March 2012 (EDT)<br />
<br />
::: I'm testing infobox icon at [[Douglas A-4 Skyhawk]] with bad results because an image size variation causes that the result is not well legible :(<br />
::: Do you now if is possible by clicking infobox icon to go directly to the respective category group page.?<br />
::: Do you create the dual control icon category? if so what is the name of it. It was the first I tried to, but i didn't find its name.<br />
::: Thats all for the moment, your feedback will be appreciated cause coding isn't my strong point.<br />
:::[[User:Aepcam|Aepcam]] 15:39, 19 March 2012 (EDT) Michat<br />
<br />
:::: The system is in {{tl|Ready}} (click it to visit the template page, where it is explained how to add new icons). I did forget the dual control icon, added now. I'll link the icons to the category, good idea!<br />
:::: [[User:Gijs|Gijs]] 15:43, 19 March 2012 (EDT)<br />
<br />
::: please consider to make a first example of a complete infobox, so I can follow your procedure. :) thanks<br />
::: [[User:Aepcam|Aepcam]] 15:48, 19 March 2012 (EDT) Michat<br />
<br />
:::: See [[Schleicher ASK 13]] for an example of two icons. You can add all icons, but I don't think we've got an aircraft that fits all... :)<br />
:::: Oh and please use the "Show preview" button before saving a page. If you're just interested in how something looks/works, it's not needed to save the page (and thus eat up server space). Previews are free, and help a lot in saving space and making the history of articles clear.<br />
:::: [[User:Gijs|Gijs]] 15:53, 19 March 2012 (EDT)<br />
<br />
::::: Thanks I'll following ask 13 example. I'll use preview, anyway I'm so afraid at saving/preview moments cause is not the first time I lost long update on an expire session. Thanks for you help Gijs. <br />
::::: [[User:Aepcam|Aepcam]] 16:02, 19 March 2012 (EDT) Michat<br />
<br />
::: Everything is updated, now I have to modify dual control icon, it seems to be bigger than others. :) thanks for you tips<br />
::: [[User:Aepcam|Aepcam]] 17:16, 19 March 2012 (EDT) Michat<br />
<br />
:::: resolved dual control image size difference. Now Its OK. Many thanks.:)<br />
:::: {{unsigned|22:40, 19 March 2012|Aepcam}}<br />
<br />
::: Glad to see that everything worked out well! We can always improve it if we want so. <br />
::: [[User:Gijs|Gijs]] 17:56, 19 March 2012 (EDT)<br />
<br />
::: Gijs, please can you also create ready cat. for the aircraft of the month. I should remove all aircraft of the month's icons in those awarded aircraft pages, but I need that category in order to include those icons on infobox as we did before with other categories. Thanks by anticipate.<br />
::: Best regards... Michat<br />
::: [[User:Aepcam|Aepcam]] 00:26, 11 April 2012 (EDT)<br />
<br />
:::: {{done}} ;)<br />
:::: [[User:Gijs|Gijs]] 05:30, 11 April 2012 (EDT)<br />
<br />
=== Language Support ===<br />
:::: Hi GIJS, this is Michat. I'm suffering serious problems with my PC. Actually I can only use wiki from a neighbourg PC with very low connection speed. I have open a discussion here [[Talk:FlightGear Newsletter May 2012]] , but I thinking that nobody read it yet.<br />
Can you please take a look on it ? <br />
<br />
Okay I'll try to repair and boot my PC, but it seems no good. :( <br />
Thanks<br />
<br />
Michat [[User:Aepcam|Aepcam]] 07:00, 23 May 2012 (EDT)<br />
<br />
== FGTour/Embassy ==<br />
Hi,<br />
<br />
could you please have a look at the question posed at [[Talk:Portal:FGembassyTour]], before continuouning all the hard work?<br />
<br />
Thanks!<br />
[[User:Gijs|Gijs]] 15:51, 3 January 2013 (EST)<br />
<br />
: Hi, I have answered it know, I din't see it.<br />
: Thanks Gijs<br />
: [[User:Aepcam|Aepcam]] 18:28, 3 January 2013 (EST)<br />
<br />
:: Hi again,<br />
:: All images that you've uploaded recently have either copyright violations, wrong sources or both. I'll delete them if that isn't fixed before the weekend.<br />
:: Cheers,<br />
:: [[User:Gijs|Gijs]] 10:28, 8 January 2013 (EST)<br />
<br />
== Renaming articles ==<br />
<br />
Hi,<br />
<br />
the wiki has a feature to rename articles. When you click the little triangle next to the search field and select "Move", you can enter the new name of the article. This way, we preserve the history of an article. In contrast to creating a new article and deleting the old one. ;-)<br />
<br />
I've fixed this for the Spanish altitude article.<br />
<br />
Thanks!<br />
[[User:Gijs|Gijs]] 15:28, 17 April 2013 (UTC)<br />
<br />
: Hi<br />
: Thanks for the tip Gijs, I'll check the way you did it.<br />
: Understand that feature is also changes the old way that we had using redirect when mistakes on title occurred. ?<br />
: I understand that if we change title page links will not been broken. Is that correct?<br />
: Now I'm trying a shared laptop, its quite horrible to use finger pad, I lost today's big wiki segment due to electrostatic. Sorry if I decided to save often. Finger pad is able to close almost PC session just with a pullover touch contact....<br />
: Michat<br />
: [[User:Aepcam|Aepcam]] 15:47, 17 April 2013 (UTC)<br />
<br />
:: Yes, when moving an article, the old page becomes a redirect to the new. And next to that it also takes care of talk pages, so it's a wonderful feature :-)<br />
:: [[User:Gijs|Gijs]] 16:12, 17 April 2013 (UTC)<br />
<br />
<br />
. . . . . .<br />
<br />
Indeed ;)<br />
Michat<br />
[[User:Aepcam|Aepcam]] 16:37, 17 April 2013 (UTC)<br />
<br />
== Map icons ==<br />
<br />
Hi,<br />
<br />
please take a look at Hooray's comment at [[File talk:Radioaidstonavnondirectionalradiobeaconsmallwithrwy.png]]<br />
<br />
Cheers,<br />
[[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 12:05, 29 March 2014 (UTC)<br />
<br />
== The Antonov aircraft ==<br />
My apologies for being a bit slow on moving around the Antonov aircraft. It seems {{usr|Gijs}} did the bulk of that job.<br />
<br />
—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 14:47, 14 May 2015 (EDT)<br />
<br />
[[User:Aepcam|Aepcam]] ([[User talk:Aepcam|talk]]) 20:38, 14 May 2015 (EDT)<br />
<br />
Very appreciated, thank you both.<br />
Michat<br />
<br />
== Changes to 2022 March newsletter ==<br />
<br />
Hi, your recent changes to https://wiki.flightgear.org/FlightGear_Newsletter_March_2022 appear to have removed two items:<br />
<br />
* YASim now supports torus contact surfaces for landing gear<br />
* Pipistrel's electric trainer aircraft<br />
<br />
Was this intentional?<br />
<br />
[[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 19:18, 18 April 2022 (UTC)</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=Video_encoding&diff=134958Video encoding2022-04-14T16:23:52Z<p>Cgdae: /* Limitations */</p>
<hr />
<div>== Overview ==<br />
<br />
Flightgear on next (the development branch) has support for video encoding of the main window. This requires that ffmpeg/libav libraries are available at build time.<br />
<br />
* Videos are generated in the current directory. This can be changed by setting property '''/sim/video/directory'''.<br />
* Video files are called '''fgvideo-<aircraft>-YYYYMMDD-HHMMSS.<container>''', for example '''fgvideo-harrier-gr3-20211209-234105.mp4'''.<br />
* A convenience link is created that points to the latest video, called '''fgvideo-<aircraft>.<container>''', for example '''fgvideo-harrier-gr3.mp4''' -> '''fgvideo-harrier-gr3-20211209-234105.mp4'''.<br />
<br />
== Limitations ==<br />
<br />
* As of 2021-12-12, only Unix builds of Flightgear include support for video encoding by default.<br />
** On other platforms, if ffmpeg libraries are installed on the system, Flightgear's cmake might pick them up automatically and enable video encoding, but this hasn't been tested.<br />
* We do not (yet) record sound.<br />
<br />
== Building ==<br />
<br />
On Unix, we require these libraries and their header files to be available at build time:<br />
<br />
* avcodec<br />
* avuti<br />
* swscale<br />
* avformat<br />
<br />
If these libraries are installed, a standard cmake build should automatically include video encoding support.<br />
<br />
As of 2021-12-27, [[Scripted_Compilation_on_Linux_Debian/Ubuntu|download_and_compile.sh]] installs these libraries automatically.<br />
<br />
On Devuan (and probably other Debian-based distributions), they can be manually installed with:<br />
<br />
sudo apt install libavcodec-dev libavutil-dev libswscale-dev libavformat-dev<br />
<br />
== Creating video of live Flightgear ==<br />
<br />
=== Starting/stopping video encoding ===<br />
<br />
Use menu items '''File/Video Start''' and '''File/Video Stop''' to start/stop video encoding.<br />
<br />
* If an error occurs, for example support for video encoding was not included at build time, Flightgear will show a popup warning message.<br />
<br />
=== Video encoding settings ===<br />
[[File:Video-control dialogue.png|thumb]]<br />
Menu '''File/Video Control''' opens a dialogue that allows control over various settings, including:<br />
<br />
* Container name, such as '''mp4''' or '''ogv'''.<br />
** Radio buttons are provided for common containers.<br />
** Run '''ffmpeg -formats''' in a separate terminal to see what containers are available on your system.<br />
* Codec name, such as '''mpeg2video''', '''libx264''', '''libx265'''.<br />
** Radio buttons are provided for common codecs.<br />
** Run '''ffmpeg -codecs''' in a separate terminal to see what codecs are available on your system.<br />
* Encoding quality in range '''0..1'''. Use '''-1''' for codec's default.<br />
* Encoding speed in range '''0..1'''. Use '''-1''' for codec's default.<br />
* Encoding target bitrate in bits per second. Use '''0''' for codec's default.<br />
<br />
== Creating video from Flightgear recordings ==<br />
<br />
Flightgear can automatically generate a video when replaying a recording file, stopping video encoding when we reach the end of the recording.<br />
<br />
Usually one would use a Continuous recording for this, as they contain full information regardless of the recording duration.<br />
<br />
* From within Flightgear:<br />
** In the '''Load Flight Recorder Tape''' dialogue, set the '''Auto-create video''' checkbox.<br />
** Optionally also set '''Fixed dt''' (see below).<br />
<br />
* With the command line '''--load-tape''' option:<br />
** Also specify '''--load-tape-create-video'''.<br />
** Optionally specify '''--load-tape-fixed-dt=...''' (see below).<br />
<br />
=== Using '''fixed-dt''' ===<br />
<br />
Setting '''fixed-dt''' to a non-zero value forces Flightgear to increment the FDM time in seconds by the specified amount each frame, instead of by the elapsed real-world time between frames. For example using a value of 0.04 will force a frame rate of 25fps.<br />
<br />
This allows creation of high quality videos from recordings, regardless of the rendering settings or speed of the host, at the expense of potentially taking longer than real time to create the recording.<br />
<br />
=== Command line examples ===<br />
<br />
Create a high quality video of a recording by running Flightgear with these command-line args:<br />
<br />
'''--load-tape=... --load-tape-create-video=1 --prop:bool:/sim/time/simple-time/enabled=true --load-tape-fixed-dt=0.04 --graphics-preset=high-quality'''<br />
<br />
Also fix video settings by setting the relevant properties:<br />
<br />
'''--load-tape=... --load-tape-create-video=1 --prop:bool:/sim/time/simple-time/enabled=true --load-tape-fixed-dt=0.04 --graphics-preset=high-quality --prop:/sim/video/container=mp4 --prop:/sim/video/codec=libx265 --prop:/sim/video/quality=0.75 --prop:/sim/video/speed=1'''<br />
<br />
=== Example video ===<br />
<br />
This 5 minute video flying around Manhattan with high rendering settings was created on a fairly slow laptop, taking about an hour to replay and encode: http://op59.net/fgvideo-harrier-gr3-20211206-230342-manhattan.mp4</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=Talk:FlightGear_Newsletter_April_2022&diff=134929Talk:FlightGear Newsletter April 20222022-04-08T09:05:44Z<p>Cgdae: </p>
<hr />
<div>I think we should remove the big text block "Note FlightGear is currently undergoing a lot of huge changes ...".<br />
<br />
This text block has been included in the last 9 newsletters with, i think, no changes in that time.<br />
<br />
IMHO this text block dominates the newsletter too much, making the page ugly and hard to read. The information is certainly useful, but no more so than other information in the newsletter. So i think it should be included in a more standard way, for example as a shortened summary with a link to the full information.<br />
<br />
[[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 11:13, 4 April 2022 (UTC)<br />
<br />
: Agree. You could even remove it as far as I'm concerned, as it's not even "news" anyway if it's been included for months already. It'd be far better to focus the section on actual new developments or status updates.<br />
: Might also be a good moment to cleanup some of the other "standard" items?<br />
: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 16:35, 4 April 2022 (UTC)<br />
<br />
<br />
Thanks to Hooray for fixing this.<br />
<br />
[[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 09:05, 8 April 2022 (UTC)</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=FlightGear_Newsletter_April_2022&diff=134922FlightGear Newsletter April 20222022-04-07T15:17:03Z<p>Cgdae: /* Development news */</p>
<hr />
<div><!--<br />
<br />
NOTES TO EDITORS<br />
<br />
* Headings<br />
* DO NOT DELETE HEADINGS prior to final cleanup<br />
* Current headings and their order is merely a suggestion based on what have been used earlier<br />
* Changes made to headings or structure should also be copied the Newsletter template http://wiki.flightgear.org/User:Skybike/Template:This_months_newsletter/Newsletter_example<br />
<br />
* Final cleanup before write protecting<br />
* Remove unused headings<br />
* Remove {{Appendix}} if not used.<br />
* Update "Category: Changes after" to the FG version current at the 1st of this month<br />
* Finally remove this comment<br />
* Update [[Next Newsletter]] and [[FlightGear Newsletter]]<br />
<br />
* Discussion, issues and suggestions<br />
* Regarding this newsletter issue, please use the discussion page<br />
* Regarding the newsletter in general, primarily use the FlightGear Newsletter discussion page (Talk:FlightGear Newsletter)<br />
* Regarding this Newsletter template, please use FIXME<br />
<br />
+++ {{Newsletter-header|{{#time: F | 2022-04}}}} +++<br />
-->{{User:Skybike/Template:Newsletter-header-translate|2022-04}}<br />
{{TOC_right|limit=2}}<br />
''We would like to emphasize that the monthly newsletter cannot live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) is welcome to contribute to the newsletter. If you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''<br />
<br />
''The new Visual Editor makes editing the wiki as simple as using a Word-processor, and even easier than using the forum as you don't even need to know the syntax for a url. Just hit the 'edit' link and start.''<br />
<br />
== Development news ==<br />
<!-- News about FlightGear itself. The FlightGear mailing list and/or core developers are a good source. --><br />
<br />
* YASim now supports torus contact surfaces for landing gear, which can be a better model of a tyre than a single contact point. See: [[YASim#Torus-shaped_contact_surface_on_next|YASim tyre contact surfaces]].<br />
<br />
<!-- == Related Software tools and projects == --><br />
<!-- Those not being part of FlightGear itself, like for example OpenRadar, TerreMaster or flightgear-atc.alwaysdata.net. --><br />
<br />
== In the hangar ==<br />
<!-- News about new and upgraded aircraft and related stuff. The official forum and other ones usually are a good source for this. --><br />
<!-- === New aircraft === --><br />
<br />
=== Updated aircraft ===<br />
Pipistrel's electric trainer aircraft, the [[Pipistrel Velis Electro|Velis Electro]] and [[Pipistrel Alpha Electro|Alpha Electro]] have received a lot of updates, including a more in-depth systems and instruments simulation as well as an improved exterior and interior model. Changes are currently available on fgaddon next only.<br/><br />
[[File:Velis-Electro-Cockpit-1.jpg|frameless|The cockpit of the updates Pipistrel Velis Electro]]<br />
<br />
<!-- === Liveries === --><br />
<!-- === Instruments === --><br />
<!-- === Aircraft reviews === --><br />
<br />
== Scenery corner ==<br />
<!-- Scenery development news --><br />
<br />
<!-- === Scenery Models === --><br />
<br />
<!-- === Airports === --><br />
<br />
<!-- === Land cover === --><br />
<br />
<!-- === Osm2city === --><br />
<br />
<!-- === New OSM2City areas === --><br />
<br />
<!-- == Interview with a contributor == --><br />
<br />
<!-- == Suggested flights == --><br />
<br />
== Help wanted ==<br />
{{Help wanted}}<br />
<br />
== AI == <br />
<br />
<!-- === AI traffic === --><br />
The AI team makes FlightGear more realistic, colorful and lively every month. You can support the development of ''Interactive Traffic'' and contribute at the FlightGear {{forum link|title=AI|f=23}}.<br />
<br />
<!-- === AI scenarios === --><br />
<br />
== Community news ==<br />
<!-- === FlightGear on YouTube === --><br />
<!-- embed video as {{#ev:youtube|VCc6PwRI1LA}}--><br />
<br />
<!-- === Forum news === --><br />
<br />
<!-- === Wiki updates === --><br />
<br />
<!-- === Article of the month === --><br />
=== FlightGear on Facebook ===<br />
Since early December 2010, FlightGear has an [https://www.facebook.com/FlightGear official Facebook page]. If you have a Facebook account please feel free to join the page.<br />
<br />
=== FlightGear on Instagram ===<br />
In January 2018 the [https://www.instagram.com/flightgear_sim/ @flightgear_sim Instagram account] was brought back to life. If you've got nice screenshots to be featured, feel free to {{forum link|text=contact the maintainer|t=33636}}.<br />
<br />
=== FlightGear on FlightSim.com ===<br />
FlightGear has also a [https://www.flightsim.com/vbfs/forumdisplay.php?102-FlightGear sub-forum] on flightsim.com - just like the commercial flight sims. It is an opportunity to showcase what FG can do, get people curious and answer any questions they may have with regard to the software or the project.<br />
<br />
== Multiplayer events ==<br />
<!-- === Upcoming events === --><br />
<br />
<!-- === Finished events === --><br />
<br />
<!-- == FlightGear events == --><br />
<!-- For example presence at FSWeekend --><br />
<br />
<!-- == Hardware reviews == --><br />
<br />
== Contributing ==<br />
=== Translators needed ===<br />
{|<br />
| [[File:en.gif]]<br />
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at [[Help:Translate]].<br />
|-<br />
| [[File:fr.gif]]<br />
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].<br />
|-<br />
| [[File:de.gif]]<br />
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang mit dem [[:de:Help:Übersetzen|Help:Übersetzen]] an.<br />
|-<br />
| [[File:nl.gif]]<br />
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].<br />
|-<br />
| [[File:es.gif]]<br />
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].<br />
|-<br />
| [[File:cat.gif]]<br />
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].<br />
|-<br />
| [[File:pt.gif]]<br />
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help:Traduzir|Help:Traduzir]].<br />
|-<br />
| [[File:zh.gif]]<br />
| FlightGear 百科仍然需要志愿者将其翻译为各种语言。如果你有兴趣让FlightGear百科支持更多语言, 你可以查看 [[Help:Translate]].<br />
|}<br />
<br />
=== FlightGear logos ===<br />
If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit [[FlightGear logos]] for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.<br />
<br />
=== Screenshots ===<br />
The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings ([[anti-aliasing]], texture sharpening, etc.). More info at [[Howto:Make nice screenshots]].<br />
<br />
==== Screenshot of the Month ====<br />
<!--FlightGear's Screenshot of the Month {{#time: F | 2022-04}} 2022 is FIXME by {{usr|FIXME}}<br />
ADD IMAGE --><br />
If you want to participate in the screenshot contest<!-- of {{#time: F | 2022-04 + 1month}}-->, you can submit your candidate to the {{forum link|title=this|f=88|t=}}. Be sure to see the first post for participation rules. For purposes of convenience and organization, at the end of the month or after 20 entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there.<!--Once the voting has finished, the best screenshot will be presented in the Newsletter edition of {{#time: F | 2022-04 + 1month}}--><br />
<br />
''Thanks for reading {{PAGENAME}}!''<br />
<br />
{{Appendix}}<br />
<!--<small><div style="text-align: center; size: 15px">About the [[FlightGear Newsletter]] - Information for [[Template:Welcome to the wiki|new Wiki users]] - Manual to the FlightGear Wiki [[Help:Your_first_article#Formatting_the_wiki_text|syntax]] - Edit the [[User:Skybike/Template:This_months_newsletter/Newsletter_example|draft]] for coming newsletters</div></small>--><br />
<br />
[[Category:Changes after 2020.3]]<!--Has a new version been released this month? Use previous version!--><br />
[[Category:FlightGear Newsletter|2022 04]]<br />
<br />
<!--[[de:FlightGear Newsletter {{#time: F Y | 2022-04 | de }}]]--></div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=Talk:FlightGear_Newsletter_April_2022&diff=134899Talk:FlightGear Newsletter April 20222022-04-04T11:13:59Z<p>Cgdae: Complain about big text block "Note FlightGear is currently undergoing a lot of huge changes ..."</p>
<hr />
<div>I think we should remove the big text block "Note FlightGear is currently undergoing a lot of huge changes ...".<br />
<br />
This text block has been included in the last 9 newsletters with, i think, no changes in that time.<br />
<br />
IMHO this text block dominates the newsletter too much, making the page ugly and hard to read. The information is certainly useful, but no more so than other information in the newsletter. So i think it should be included in a more standard way, for example as a shortened summary with a link to the full information.<br />
<br />
[[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 11:13, 4 April 2022 (UTC)</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=Template:Help_wanted&diff=134815Template:Help wanted2022-03-23T11:45:43Z<p>Cgdae: /* Post LTS work */ Video encoding on Windows and Mac.</p>
<hr />
<div>=== Post LTS work ===<br />
<br />
After the 2020.2 release, some work lies ahead to improve the LTS and to help us pave the way for migrating to the OpenGL Core profile - any help would be greatly appreciated. <br />
<br />
This may for example include:<br />
* [[OpenGL#Status|Switching to the OpenGL Core profile]]<br />
* [[Aircraft_testing_checklist|Checking that aircraft work with the LTS and documenting any major problems]]<br />
* [[Unifying_the_2D_rendering_backend_via_canvas#HUD|Porting the legacy HUD system to become Canvas based]]<br />
* [[Cppunit effort]] and [[FlightGear Headless]] (see Testing)<br />
* [[Deboosting FlightGear]]<br />
* Include ffmpeg libraries in Windows and Mac builds, to enable [[Video_encoding|built-in video encoding]].<br />
<br />
Please get in touch via the developers mailing list to learn more.<br />
See [[Post FlightGear 2020.2 LTS changes]] and [[2022.X Release Plan]] for more details.<br />
<br />
=== World Scenery 3.0 ===<br />
<br />
<br />
The FlightGear project is in the process of exploring how [[Virtual Planet Builder]] can be adopted. For details, see: [[World Scenery 3.0 roadmap]]<br />
<br />
=== Aerial (drone) photos for Terrain textures ===<br />
Wanted: good ''top-down'' aerial photos to create textures from to use with the procedural Regional Texturing system. {{wikipedia|Aerial_photography#Radio-controlled_model_aircraft|Drones}} with cameras are ideal. People with access to drones are in a good position to take high-quality photographs.<br />
<br />
A particular need as of 2020 is ''photos of agriculture'' (farm lands) from different parts of the world.<br />
<br />
Good GPLv2 compatible photos suitable for textures are hard to find, and an easy way is for people to take photos of their region. Flightgear's procedural systems can do a lot with less art content, so photo contributions can strongly improve visuals.<br />
<br />
See: [[Howto:Create_textures_from_photos#Taking_your_own_photos|How to: take photos of terrain for textures]]. For examples of final textures: see /data/Textures/Terrain. e.g. [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Textures/Terrain/uk_countryside2.png UK countryside].<br />
<br />
You can get in touch via the [https://forum.flightgear.org/viewforum.php?f=5 Scenery forum] or the [[Mailing_lists|flightgear-devel]] mailing list<br />
<br />
=== Photos of trees for textures ===<br />
Wanted: good quality photos of different trees and vegetation from various parts of the world. Flightgear's vegetation system can handle [[:File:EC_135_in_Hawaii_(Flightgear_2018.x).jpg|multiple layers]] of trees and bushes. <br />
<br />
Strong shadows should be avoided. Each tree should be against a background of a different colour: [https://commons.wikimedia.org/wiki/File:Tree_on_skyline_-_geograph.org.uk_-_817006.jpg sky] (preferably) , [https://commons.wikimedia.org/wiki/File:Tree_on_the_skyline_-_geograph.org.uk_-_409721.jpg clouds] , or [https://commons.wikimedia.org/wiki/File:Tree,_sky,_top_roof.jpg buildings]. This allows the tree to be separated from the background in a photo-editor like GIMP.<br />
<br />
See: [[Howto:Create_textures_from_photos#Taking_your_own_photos|How to: take photos of vegetation]]. For examples of final textures: see /data/Textures/Trees. e.g. [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Textures/Trees/coniferous-alt.png Coniferous].<br />
<br />
You can get in touch via the [https://forum.flightgear.org/viewforum.php?f=5 Scenery forum] or the [[Mailing_lists|flightgear-devel]] mailing list.<br />
<br />
===Submissions of labels for craft===<br />
Wanted: Submissions of labels (tags) giving a rough description of aircraft - [[Catalog_metadata|Metadata]] tags. A quick read of a craft's Wikipedia page will normally be enough to set labels. This info will be searchable from the [[FlightGear_Qt_launcher|launcher]] GUI. For example, filtering craft by propulsion like single-propeller or 4-engine jet craft, or by a manufacturer like Airbus or Grumman, or by speed like supersonic craft, or craft by era like WW2. A list of tags is [[Catalog_metadata#Supported_Tags|here]] - more can be added if needed. To [[Catalog_metadata#Adding_metadata_to_aircraft|add tags]] to craft yourself, the tags are stored in the set-xml file. <br />
<br />
A list of FGAddon craft needing tags is [http://adalin.com/ehtw.info/flightgear-metadata.txt here]. See [https://forum.flightgear.org/viewtopic.php?f=6&t=31915 this] forum thread to submit tags. The [[Mailing_lists|flightgear-devel]] mailing list or the craft's maintainer can also be contacted.<br />
<br />
=== Windows Package Maintainer ===<br />
The core team needs help from Windows users able to maintain a good working Window build.<br />
This process already exists to support our Nightly and Release builds, but we are seeking additional help to keep it in good working order.<br />
The ability to compile FG from source and some Windows batch scripting is a required skill.<br />
If you are willing and able to take up this role, please reach out to James Turner (mailing list), or get in touch via the forum <ref>https://forum.flightgear.org/viewtopic.php?f=42&t=37155</ref><br />
<br />
<references/><noinclude><br />
[[Category:Newsletter templates]]<br />
[[Category:Undocumented templates]]<br />
</noinclude></div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=Post_FlightGear_2020.2_LTS_changes&diff=134814Post FlightGear 2020.2 LTS changes2022-03-23T11:35:26Z<p>Cgdae: /* Changes that are already on next */</p>
<hr />
<div>== Changes that are already on next ==<br />
<br />
* [[YASim#Torus-shaped_contact_surface_on_next]] - YASim tyre contact surfaces.<br />
* [[Video_encoding]] - video encoding of Flightgear's main window.<br />
* [[Instant_Replay]] - new Record/replay functionality.<br />
* [[Highlighting]] - highlight animated parts of the user aircraft and show associated properties.<br />
* [[ExtraViewWindows]].<br />
* [[SimpleTime]] - an alternative to [[Real_Time_manual|Real time]] mode.<br />
* [[Carrier_over_MP#Pilot_Using_the_Carrier|Simplifications to Multiplayer carrier operation]].<br />
<br />
== Code clean-ups and changes ==<br />
{{Mergeto|2022.X Release Plan}}<br />
<br />
Collecting what's going to change : this will also be used to work out what manual or automatic migrations are required to keep aircraft working. It's expected that for the first few months of 'next', there will be higher than usual breakage, i.e regular might not be possible.<br />
<br />
As a general guideline, the minimum system to develop / build the code on will be Ubuntu 18.04 LTS (Bionic) : the versions below correspond to what is available in a stock Bionic install.<br />
<br />
# Make C++14 (possibly C++17 to facilitate {{Abbr|VSG|Vulkan Scene Graph}} [[Vulkan Scene Graph|migration]]? <ref>https://sourceforge.net/p/flightgear/mailman/message/37041706/</ref> <ref>https://sourceforge.net/p/flightgear/mailman/message/37042499/</ref>) the minimum required version (will make it easier to continue [[Deboosting FlightGear|replacing Boost]] items with std:: ones) <ref>https://sourceforge.net/p/flightgear/mailman/message/36988831/</ref> <ref>https://sourceforge.net/p/flightgear/mailman/message/36984349/</ref><br />
# Make CMake 3.6 the minimum required version: this will allow simplifying a bunch of compatibility logic in the build files <ref>https://sourceforge.net/p/flightgear/mailman/message/37020794/</ref> {{Progressbar|70}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37091728/</ref><br />
## <del>Blocked by: [[OSGText Issues]]</del> <ref>https://sourceforge.net/p/flightgear/mailman/message/37284981/</ref><br />
# Use CMake OBJECT_LIBRARY to improve how we collect sources together when building each sub-dir {{Progressbar|10}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37042800/</ref><br />
# Make Qt 5.9 the minimum for the launcher {{Done}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37041064/</ref><br />
# Drop 32-bit windows support <ref>https://sourceforge.net/p/flightgear/mailman/message/34899704/</ref><br />
# Drop the pre-2017.x MultiPlayer message format - this will fix warnings from some aircraft about MP packet overflows <ref>https://sourceforge.net/p/flightgear/mailman/message/36300829/</ref><br />
# Drop the KLN-89 code, since it's unused and not maintained for a long time: Canvas and the regular GPS code can easily implement a working KLN-89 or similar equipment now <ref>https://sourceforge.net/p/flightgear/mailman/message/36327950/</ref><br />
# Switch to Compositor mode as the only rendering option {{Progressbar|90}} <ref>https://sourceforge.net/p/flightgear/mailman/message/36606242/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/37039397/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/37040359/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/37148477/</ref><br />
# Drop [[Rembrandt]] support from C++ (really part of the above) <ref>https://sourceforge.net/p/flightgear/mailman/message/36340736/</ref><br />
# Drop the C++ [[NavDisplay]]: the Canvas version replaces it <ref>https://sourceforge.net/p/flightgear/mailman/message/36975265/</ref><br />
<br />
== Carriers and AI ==<br />
<br />
Ricbhard has been working on carriers since April 2020; originally the intention was to release as part of the 2020.2 LTS however the changes have grown into a set of new features rather than bugfixes and are therefore more suited to a longer development and review process.<ref>https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/aaa9a3ee-ca18-e3af-1538-0cd59ae7a752%40zaretto.com/#msg37038519</ref><br />
<br />
* {{done}} Improved view support - so that the nearest tower will include carriers<br />
* {{done}} Changes to core code to support moving towers.<br />
* {{Progressbar|80}} Multiple (tower) views - permit selection of LSO, PLAT and Tower as part of the "Tower view"; selection mechanism TDB. Consider revisions to the existing view system to better support this.<br />
* {{done}} Extend XML to include definitions for FLOLS touchdown position, LSO view position, Tower View position, deck angle.<br />
* {{Progressbar|80}} Improve 3d models for IFLOLS to ensure that a ball call can be made.<br />
* {{Progressbar|80}} Improve logic for IFLOLS lights; not quite an LSO simulation more of an approximation of the definitive cases (e.g. waveoff)<br />
* {{pending}} Animate the lineup lights on the stern (of Nimitz class).<br />
* {{Progressbar|100}} Improved support for Precision Approach Landing System (PALS) (AN/SPN-46); to support lineup deviation as well as glideslope (ball) deviation.<br />
* {{Progressbar|70}} Change approach deviations to use new aircraft reference point rather than eyepoint; it is probably more correct to use the eyepoint when in the cockpit view - but for external views this can be slightly inaccurate when outside the aircraft to completely wrong when in tower/LSO view. The reference point is taken as the aircraft position with an optional model defined x,y,z offset. This allows ball tuning on a per aircraft basis.<br />
* {{Pending}} Improved support for AI logic to permit XML definition of e.g. LSO logic. Possibly a version of the autopilot / state machine that can be included as "logic blocks"<br />
* {{Pending}} Review 3d model usage for all Nimitz class and either add LOD selection (low, medium, high)<br />
* {{Pending}} Review and include Marsdolphin contributions for MP Carrier (i.e. MP trumman)<br />
*{{Progressbar|20}} Possible extra visual aids for Case 1 and Case 2 recovery training (e.g. a set of markers to fly through)<br />
* {{Pending}} Better integration of carriers with JSBSim to permit catapult hookup<br />
* {{Pending}} Simulate carrier operations Flight Deck Personnel, e.g. yellow shirts.<br />
* {{Pending}} Animation of arrestor wires<br />
* {{Pending}} Add some sort of trap grading (approach/touchdown plot)<br />
<br />
see https://www.cnatra.navy.mil/local/docs/pat-pubs/P-816.pdf for T-45 carrier operations<br />
<br />
== Possible additional items ==<br />
{{Main article|2022.X Release Plan}}<br />
<br />
===2D Panels ===<br />
The idea is to remove all 'raw' OpenGL or OpenSceneGraph code from the panel code, it should be 100% done with Canvas elements. Eg use the Canvas Transform to compute the matrices<ref>https://sourceforge.net/p/flightgear/flightgear/merge-requests/217/#a8d5</ref><br />
* [[Canvas_News#2D_Panels|Remove the 2D panel code in favour of Canvas]] (this requires completing some work to load 2D panel elements as Canvas, from XML) <ref>https://sourceforge.net/p/flightgear/mailman/message/36973988/</ref> (as of 06/2020, Gaétan Allaert is still working on the replacement of the 2D panel by canvas <ref>https://sourceforge.net/p/flightgear/mailman/message/37042351/</ref>) {{Progressbar|80}}<ref>https://sourceforge.net/u/gallaert/flightgear/ci/789f5bdbce10637222ffa25206938947fec4bc64/</ref><br />
<br />
=== Canvas ===<br />
<br />
<br />
{{See also|Unifying the 2D rendering backend via canvas}}<br />
* Note that the canvas currently assumes render-to-texture, but for the GUI I'm not sure that's actually desirable - simply a separate camera per GUI window may be sufficient. Since the camera already arranges everything beneath the RTT camera this should be fairly minor change, if it's desirable.(Saves some memory, makes re-sizing GUI windows a little easier, might make clipping or other state management less efficient in the main GUI camera ... but probably not)<ref>https://sourceforge.net/p/flightgear/mailman/message/29608899/</ref><br />
* Remove the C++ HUD in favour of Canvas-based version: this requires some kind of migration script or framework, so we have at least the default UFO HUD available <ref>https://sourceforge.net/p/flightgear/mailman/message/36973988/</ref><br />
* <del>Review Tim's original suggestion<ref>https://sourceforge.net/p/flightgear/mailman/message/36659646/</ref>: Another [Canvas] optimization is to use a pre-render camera that isn't in the scene graph to do the Canvas rendering. '''Otherwise the Canvas textures are rendered at least twice, in the near and far cameras'''. <ref>https://sourceforge.net/p/flightgear/mailman/message/36352621/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/37042457/</ref> Tim Moore’s canvas-rendering-on-a-pre-camera fix, again should give us a nice perf win for Canvas-intensive acft<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>, since within each camera pass (far camera, near camera), all the passes of a technique are run.<ref>https://sourceforge.net/p/flightgear/mailman/message/29563353/</ref> Also, Mathias stated once: that it would be good to be able to specify a completely different scenegraph in some subcameras, i.e. for having panel like instruments on an additional screen/display for example.<ref>https://sourceforge.net/p/flightgear/mailman/message/19718354/</ref></del><br />
** https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Canvas/FGCanvasSystemAdapter.cxx#l70<br />
** https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Viewer/renderer_compositor.cxx#l927 (compositor renderer)<br />
** https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Viewer/renderer_legacy.cxx#l1842 (legacy renderer)<br />
* <del>As per James' comments: Investigate adapting the [[Canvas Popout Windows|WindowBuilder to allow OSG windows to be created dynamically]] for features like Stuart's [[FG1000]] to be shown in a separate window (canvas placement)</del> <ref>https://sourceforge.net/p/flightgear/mailman/message/37058207/</ref> (this is basically now possible thanks to Jules' CompositeViewer work)<br />
* Review/integrate experimental C++ patches for new Canvas elements floating around on the forum, namely:<br />
** [[Canvas View Camera Element#Proof of Concept|view manager support]]<br />
** [[Howto:Extending Canvas to support rendering 3D models|3d model support]]<br />
<br />
== fgdata clean-ups ==<br />
=== /Nasal ===<br />
2do: list outdated / deprecated functions for removal (I remember one comment saying: remove after FG 3.0 or something)<br />
* Clean up the GPS code with respect to FG_210_COMPAT :<br />
<br />
== Property tree clean-up ==<br />
remove /yasim/* "new" path is /fdm/yasim (since version 201x.?)<br />
<br />
== References ==<br />
{{Appendix}}<br />
<br />
[[Category:Core development]]<br />
<br />
[[Category:Release plans]]</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=User:Cgdae&diff=134813User:Cgdae2022-03-23T11:30:05Z<p>Cgdae: </p>
<hr />
<div>== Recent ==<br />
<br />
Current work in progress:<br />
<br />
* .<br />
<br />
On next:<br />
<br />
* [[YASim#Torus-shaped_contact_surface_on_next|YASim tyre contact surfaces]].<br />
* [[Video encoding]] of Flightgear's main window.<br />
** E.g. see: http://op59.net/fgvideo-harrier-gr3-manhattan.mkv<br />
* [[Highlighting]].<br />
* [[SimpleTime]].<br />
* [[ExtraViewWindows|Extra view windows]].<br />
* [[Instant_Replay#Record.2Freplay_on_next|Enhancements to record/replay]].<br />
* [[Carrier_over_MP#Pilot_Using_the_Carrier|Enhancements to multiplayer carrier operation]].<br />
<br />
Other:<br />
<br />
* [[:Category:Hackathon 2021 Ideas]].<br />
*[[Walk_build_system|The Walk Flightgear Build system]] - a different kind of build system which i use to build Flightgear.<br />
*Harrier-GR3 autohover: https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Harrier-GR3/<br />
*Flightgear on [http://www.openbsd.org OpenBSD].<br />
<br />
<br />
==Old==<br />
*[https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/debug/logdelta.hxx logdeltas] - control of debug log levels based on source filename prefixes, line numbers and function prefixes.<br />
*[[Post_FlightGear_2020.2_LTS_changes#Record.2Freplay|Record/replay]]:<br />
** Multiplayer record.<br />
**Continuous record.<br />
**Recovery snapshots.<br />
*[[Changelog_2020.1#Multiplayer |Multiplayer views]].<br />
*[[Changelog_2020.1#Graphics |Tower View AGL]].</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=YASim&diff=134810YASim2022-03-21T14:23:31Z<p>Cgdae: /* Torus-shaped contact surface on next */ Updated with recent change to allow backwards compatibility.</p>
<hr />
<div>[[File:yasimlogo.png|thumb]] <br />
<br />
'''YASim''' is one of two [[flight dynamics model]]s commonly used in [[FlightGear]]. The flight dynamics model (FDM) determines how the [[aircraft]] moves and flies.<br />
<br />
Gary Neely wrote in his [http://www.buckarooshangar.com/flightgear/ introduction to YASim]:<br />
<br />
:''The FDM is the mathematical model that controls the physics of flight within the simulator. The physical 3D aircraft model has nothing to do with flight dynamics-- in essence it's just a picture to look at. It's the FDM that dictates how the model flies.''<br />
<br />
:''Why YASim? YASim uses the geometry of the aircraft to generate the base flight characteristics. While this suggests a 'realistic' or out-of-the-box approach, it is a only rough approximation that will require much tweaking before you get a result that approaches realism. If you have solid flight data for your aircraft such as wind-tunnel data or you are looking to eventually generate a hyper-realistic simulation, JSBSim is probably a better approach. If you lack such data but know the geometry of the aircraft and have access to the same flight characteristics and limits as a real pilot would, then YASim can provide a solution that is more than sufficient for most simulation needs.''<br />
<br />
== Coordinate system notes ==<br />
All positions specified are in metres (which is weird, since all other units in the file are English). The X axis points forward, Y is left, and Z is up. Take your right hand, and hold it like a gun. Your first and second fingers are the X and Y axes, and your upwards-pointing thumb is the Z. This is slightly different from the coordinate system used by [[JSBSim]]. Sorry. The origin can be placed anywhere, so long as you are consistent. I use the nose of the aircraft.<br />
<br />
(In the [[JSBSim_Aerodynamics#Frames|JSBSim coordinate system]], X and Z are the same as in YASim, but Y points to the right instead of left.)<br />
<br />
=== Checking alignment with Blender ===<br />
<br />
Blender can display a '''.ac''' model and a yasim model at the same time, allowing one to check whether the wings, gear contact points etc are aligned correctly. But it seems that Blender ignores any top-level <code>loc <x> <y> <z></code> specification in the '''.ac''' file, which makes it non-trivial to check alignment if such a specification is used.<br />
<br />
== YASim design notes ==<br />
Andy Ross's original design notes for YASim can be found in [https://pdfhost.io/v/~iYsLl7xS_alldvi.pdf this PDF file]. These provide some useful background for how YASim works.<br />
<br />
== XML Elements ==<br />
<!-- To future editors: The all lowercase headings are XML tags and should ''probably'' be left that way --><br />
=== airplane ===<br />
The top-level element for the file. It contains the following attributes: <br />
* '''mass:''' The empty (no fuel) weight, in pounds. It does include the weight of the engine(s), so when you add the engine weight in its tag, it acts just like a ballast.<br />
* '''version:''' The version attribute is used to maintain compatibility when updating yasim (e.g. bugfixes). If this attribute i not given, the original version will be used. Several bugfixes to YASim were implemented in FlightGear 3.2 (see [[FlightGear Newsletter April 2014]]), some more are fixed in FlightGear 2017.2. <br />
Available versions are:<br />
* <code>YASIM_VERSION_ORIGINAL</code> explicitly use the old buggy calculations (same as no version attribute at all)<br />
* <code>YASIM_VERSION_32</code> enable bugfixes up to version 3.2<br />
* <code>2017.2</code> enable bugfixes up to version 2017.2<br />
* <code>2018.1</code> (FIXME) no bugfixes by now. Use this version if your aircraft makes use of new features in YASim 2018.1 so it will cause at least a warning with older FG versions. <br />
* <code>YASIM_VERSION_CURRENT</code> use latest version compiled into the users FlightGear. <br />
{{Warning| Using YASIM_VERSION_CURRENT might make the aircraft unusable in case of future changes to YASim without updating the aircraft accordingly.}}<br />
<br />
'''New in 2018.1'''<br />
* '''mtow-lbs''' and '''mtow-kg:''' use one of them to specify max. takeoff weight. Does not affect the FDM, but is used by CLI tool to calculate some numbers.<br />
<br />
=== approach ===<br />
The approach parameters for the aircraft. The solver will generate an aircraft that matches these settings (by adjusting the parameters of the surface like drag and lift). It is extremely important to give parameters which could be really achieved by defined aircraft geometry, otherwise, it gives an unstable or not flyable result. The element can (and should) contain <control> elements indicating pilot input settings, such as flaps and throttle, for the approach.<br />
<br />
* '''speed:''' The approach airspeed, in knots TAS.<br />
* '''aoa:''' The approach angle of attack, in degrees<br />
* '''fuel:''' Fraction (0-1) of fuel in the tanks. Default is 0.2.<br />
<br />
=== cruise ===<br />
The cruise speed and altitude for the solver to match. As above, this should contain <control> elements indicating aircraft configuration. Especially, make sure the engines are generating enough thrust at cruise!<br />
* '''speed:''' The cruise speed, in knots TAS.<br />
* '''alt:''' The cruise altitude, in feet MSL.<br />
* '''fuel:''' Fraction (0-1) of fuel in the tanks. Default is 0.2.<br />
=== cockpit ===<br />
The location of the cockpit (pilot eyepoint).<br />
* '''x,y,z:''' eyepoint location (see coordinates note)<br />
<br />
=== fuselage ===<br />
This defines a tubelike structure. It will be given an even mass and aerodynamic force distribution by the solver. You can have as many as you like, in any orientation you please.<br />
* '''ax,ay,az:''' One end of the tube (typically the front)<br />
* '''bx,by,bz:''' The other ("back") end.<br />
* '''width:''' The width of the tube, in metres.<br />
* '''taper:''' The approximate radius at the "tips" of the fuselage expressed as a fraction (0-1) of the width value.<br />
* '''midpoint:''' The location of the widest part of the fuselage, expressed as a fraction of the distance between A and B.<br />
* '''idrag:''' Multiplier for the "induced drag" generated by this object. Default is one. With idrag=0 the fuselage generates only drag.<br />
* '''cx,cy,cz:''' Factors for the generated drag in the fuselages "local coordinate system" with x pointing from end to front, z perpendicular to x with y=0 in the aircraft coordinate system. E.g. for a fuselage of a height of 2 times the width you can define cy=2 and (due to the doubled front surface) cx=2.<br />
<br />
=== Surfaces ===<br />
==== wing ====<br />
This defines the main wing of the aircraft. You can have only one (but see below about using vstab objects for extra lifting surfaces). The wing should have a <stall> subelement to indicate stall behavior, control surface subelements (flap0, flap1, spoiler, slat) to indicate what and where the control surfaces are, and <control> subelements to map user input properties to the control surfaces.<br />
* '''x,y,z:''' The "base" of the wing, specified as the location of the mid-chord (not leading edge, trailing edge, or aerodynamic center) point at the root of the LEFT (!) wing.<br />
* '''length:''' The length from the midchord point of the base of the wing to the midchord point at the tip. Note that this is not the same thing as span.<br />
* '''chord:''' The chord of the wing at its base, along the X axis (not normal to the leading edge, as it is sometimes defined).<br />
* '''incidence:''' The incidence angle at the wing root, in degrees. Zero is level with the fuselage (as in an aerobatic plane), positive means that the leading edge is higher than the trailing edge (as in a trainer).<br />
* '''twist:''' The difference between the incidence angle at the wing root and the incidence angle at the wing tip. Typically, this is a negative number so that the wing tips have a lower angle of attack and stall after the wing root (washout).<br />
* '''taper:''' The taper fraction, expressed as the tip chord divided by the root chord. A taper of one is a hershey bar wing, and zero would be a wing ending at a point. Defaults to one.<br />
* '''sweep:''' The sweep angle of the wing, in degrees. Zero is no sweep, positive angles are swept back. Defaults to zero. [This looks to be the sweep of the mid-chord of the wing, not the sweep of the leading edge.]<br />
* '''dihedral:''' The dihedral angle of the wing. Positive angles are upward dihedral. Defaults to zero.<br />
* '''idrag:''' Multiplier for the "induced drag" generated by this surface. In general, low aspect wings will generate less induced drag per-AoA than high aspect (glider) wings. This value isn't constrained well by the solution process, and may require tuning to get throttle settings correct in high AoA (approach) situations.<br />
* '''effectiveness:''' Multiplier for the "normal" drag generated by the wing. Defaults to 1. Arbitrary, dimensionless factor. <br />
* '''camber:''' The lift produced by the wing at zero angle of attack, expressed as a fraction of the maximum lift produced at the stall AoA.<br />
* '''flow:''' The flow regime for the wing. Valid values are "SUBSONIC" (default) and "TRANSONIC". Setting surface to transonic adds more lift above mach number 0.6 by applying a Prandl/Glauert correction term to each surface-element. The effect is a more balanced lift/drag distribution reported by the solver. Use for anything that flies faster than mach 0.6 or has supercritical airfoils.<br />
* '''mcrit:''' The critical mach number for the wing. This point defines the begin of exponential drag rise due to mach speed. Default "0.6", only available if flow="TRANSONIC".<br />
<br />
'''Wing section support (since 2018.1):'''<br />
<br />
Wing section support to define variable geometry (geometry parameters per section)<br />
* More than one <wing>-element is allowed now. <br />
* x, y, z, chord and incidence attribute shall be specifed only for the first <wing> in the XML file. They will be overridden for subsequent <wing>-elements.<br />
* Use '''append="1"''' for additional '''wing''' elements to skip x, y, z, chord and incidence attribute as the will be calculated from previous '''wing''' element tip chord. This workaround is currently needed due to limitations in the XML parser.<br />
<br />
==== hstab ====<br />
These define the horizontal stabilizer of the aircraft. Internally, it is just a wing object and therefore works the same in XML. <br />
You are allowed only one hstab object; the solver needs to know which wing's incidence to play with to get the aircraft trimmed correctly.<br />
<br />
'''New in 2018.1:'''<br />
* '''hstab''' supports sections in the same way '''wing''' does, but it is still considered as /the/ (only) hstab used by the solver.<br />
* '''incidence-min-deg''' and '''incidence-max-deg''': optional attributes to limit valid result range fore the solver. Use with care or you won't get a solution.<br />
<br />
==== vstab ====<br />
A "vertical" stabilizer. Like hstab, this is just another wing, with a few special properties. The surface is not "mirrored" as are wing and hstab objects. If you define a left wing only, you'll only get a left wing. The default dihedral, if unspecified, is 90 degrees instead of zero. But all parameters are equally settable, so there's no requirement that this object be "vertical" at all. You can use it for anything you like, such as extra wings for biplanes. Most importantly, these surfaces are not involved with the solver computation, so you can have none, or as many as you like.<br />
<br />
==== mstab ====<br />
A mirrored horizontal stabilizer. Exactly the same as wing, but not involved with the solver computation, so you can have none, or as many as you like.<br />
<br />
==== stall ====<br />
A subelement of a wing (or hstab/vstab/mstab) that specifies the stall behavior.<br />
* '''aoa:''' The stall angle (maximum lift) in degrees. Note that this is relative to the wing, not the fuselage (since the wing may have a non-zero incidence angle).<br />
* '''width:''' The "width" of the stall, in degrees. A high value indicates a gentle stall. Low values are viscious for a non-twisted wing, but are acceptable for a twisted one (since the whole wing will not stall at the same time).<br />
* '''peak:''' The height of the lift peak, relative to the post-stall secondary lift peak at 45 degrees. Defaults to 1.5. This one is deep voodoo, and probably doesn't need to change much. Bug me for an explanation if you're curious.<br />
<br />
==== flap0, flap1, slat, spoiler ====<br />
These are subelements of wing/hstab/vstab objects, and specify the location and effectiveness of the control surfaces.<br />
* '''start:''' The position along the wing where the control surface begins.Zero is the root, one is the tip.<br />
* '''end:''' The position where the surface ends, as above.<br />
* '''lift:''' The lift multiplier for a flap or slat at full extension. One is a no-op, a typical aileron might be 1.2 or so, a giant jetliner flap 2.0, and a spoiler 0.0. For spoilers, the interpretation is a little different -- they spoil only "prestall" lift. Lift due purely to "flat plate" effects isn't affected. For typical wings that stall at low AoA's essentially all lift is pre-stall and you don't have to care. Jet fighters tend not to have wing spoilers, for exactly this reason. This value is not applicable to slats, which affect stall AoA only.<br />
* '''drag:''' The drag multiplier, as above. Typically should be higher than the lift multiplier for flaps.<br />
* '''aoa:''' Applicable only to slats. This indicates the angle by which the stall AoA is translated by the slat extension.<br />
<br />
=== Rotor and rotorgear ===<br />
YASim has also possibility to simulate rotorcraft blades. The number properties of rotor elements are large therefore are spitted to the separate page [[Howto:Make a helicopter#XML%20Elements|howto make a helicopter in YASim]].<br />
<br />
=== Engine ===<br />
==== Thruster ====<br />
A very simple "thrust only" engine object. Useful for things like thrust vectoring nozzles. All it does is map its THROTTLE input axis to its output thrust rating. Does not consume fuel, etc...<br />
* '''thrust:''' Maximum thrust in pounds<br />
* '''x,y,z:''' The point on the airframe where thrust will be applied.<br />
* '''vx,vy,vy:''' The direction of the thrust in airframe coordinates. The vector will be normalized automatically, so any non-zero vector will work fine.<br />
<br />
Example: <br />
<br />
<syntaxhighlight lang="xml" line><br />
<thruster x="0" y="0" z="0.03" vx="1" vy="0" vz="0" thrust="6.61"><br />
<control-input axis="/controls/engines/engine[0]/throttle" control="THROTTLE" src0="-1" src1="1" dst0="-1" dst1="1"/><br />
</thruster><br />
</syntaxhighlight><br />
<br />
==== Jet ====<br />
A turbojet/fan engine. It accepts a <control> subelement to map a property to its throttle setting, and an <actionpt> subelement to place the action point of the thrust at a different position than the mass of the engine.<br />
* '''x,y,z:''' The location of the engine, as a point mass. If no actionpt is specified, this will also be the point of application of thrust.<br />
* '''mass:''' The mass of the engine, in pounds.<br />
* '''thrust:''' The maximum sea-level thrust, in pounds.<br />
* '''afterburner:''' Maximum total thrust with afterburner/reheat, in pounds [defaults to "no additional thrust"].<br />
* '''rotate:''' Vector angle of the thrust in degrees about the Y axis [0].<br />
* '''n1-idle:''' Idling low pressure core / fan speed [55]. <br />
* '''n1-max:''' Maximum low pressure core / fan speed [102].<br />
* '''n2-idle:''' Idling high pressure core speed [73].<br />
* '''n2-max:''' Maximum high pressure core speed [103].<br />
* '''tsfc:''' Thrust-specific fuel consumption [0.8]. This should be considerably lower for modern turbofans.<br />
* '''atsfc:''' (version >= 2016.3.1) Thrust specific fuel consumption with afterburner on. When set to zero defaults to older behaviour where it is calculated from dry fuel consumption [0].<br />
* '''egt:''' Exhaust gas temperature at takeoff in K [1050].<br />
* '''epr:''' Engine pressure ratio at takeoff [3.0].<br />
* '''exhaust-speed:''' The maximum exhaust speed in knots [~1555].<br />
* '''spool-time:''' Time, in seconds, for the engine to respond to 90% of a commanded powersetting.<br />
<br />
==== Propeller ====<br />
A propeller. This element requires an engine subtag. Currently <piston-engine> and <turbine-engine> are supported.<br />
* '''x,y,z:''' The position of the mass (!) of the engine/propeller combination. If the point of force application is different (and it will be) it should be set with an <actionpt> subelement.<br />
* '''mass:''' The mass of the engine/propeller, in pounds.<br />
* '''moment:''' The moment, in kg-metres^2. This has to be hand calculated and guessed at for now. A more automated system will be forthcoming. Use a negative moment value for counter-rotating ("European" -- CCW as seen from behind the prop) propellers. A good guess for this value is the radius of the prop (in meters) squared times the mass (kg) divided by three; that is the moment of a plain "stick" bolted to the prop shaft.<br />
* '''radius:''' The radius, in meters, or the propeller.<br />
* '''cruise-speed:''' The max efficiency cruise speed of the propeller. Generally not the same as the aircraft's cruise speed.<br />
* '''cruise-rpm:''' The RPM of the propeller at max-eff. cruise.<br />
* '''cruise-power:''' The power sunk by the prop at cruise, in horsepower.<br />
* '''cruise-alt:''' The reference cruise altitude in feet.<br />
* '''takeoff-power:''' The takeoff power required by the propeller...<br />
* '''takeoff-rpm:''' ...at the given takeoff RPM.<br />
* '''gear-ratio:''' The factor by which the engine RPM is multiplied to produce the propeller RPM. Optional (defaults to 1.0).<br />
* '''contra:''' When set (contra="1"), this indicates that the propeller is a contra-rotating pair. It will not contribute to the aircraft's net gyroscopic moment, nor will it produce asymmetric torque on the aircraft body. Asymmetric slipstream effects, when implemented, will also be zero when this is set.<br />
<br />
<br />
YASim assumes a fixed-pitch propeller by default. If your engine is using a constant-speed propeller, you'll also need to provide these attributes:<br />
<br />
* '''min-rpm:''' The minimum operational RPM for a constant speed propeller. This is the speed to which the prop governor will seek when the blue lever is at a minimum. The coarse-stop attribute limits how far the governor can go into trying to reach this RPM.<br />
* '''max-rpm:''' The maximum operational RPM for a constant speed propeller. See above. The fine-stop attribute limits how far the governor can go in trying to reach this RPM.<br />
* '''fine-stop:''' The minimum pitch of the propeller (high RPM) as a ratio of ideal cruise pitch. This is set to 0.25 by default -- a higher value will result in a lower RPM at low power settings (e.g. idle, taxi, and approach).<br />
* '''coarse-stop:''' The maximum pitch of the propeller (low RPM) as a ratio of ideal cruise pitch. This is set to 4.0 by default -- a lower value may result in a higher RPM at high power settings.<br />
<br />
<br />
===== piston-engine =====<br />
<br />
A piston engine definition. This must be a subelement of an enclosing <propeller> tag.<br />
<br />
* '''eng-power:''' Maximum BHP of the engine at sea level.<br />
* '''eng-rpm:''' The engine RPM at which eng-power is developed<br />
* '''displacement:''' The engine displacement in cubic inches.<br />
* '''compression:''' The engine compression ratio.<br />
<br />
<syntaxhighlight lang="xml" line><br />
<piston-engine eng-power="2" eng-rpm="3800" displacement="20" ><br />
<control-input axis="/controls/engines/engine[0]/throttle" control="THROTTLE"/><br />
<control-input axis="/controls/engines/engine[0]/starter" control="STARTER"/><br />
<control-input axis="/controls/engines/engine[0]/magnetos" control="MAGNETOS"/><br />
<control-input axis="/controls/engines/engine[0]/mixture" control="MIXTURE"/><br />
</piston-engine><br />
</syntaxhighlight><br />
<br />
===== electric-engine =====<br />
<br />
A simplified electric DC engine model. The model is available since the end of April 2020, therefore it is currently available in daily build FlightGear snapshots. This definition must be a subelement of an enclosing <propeller> tag.<br />
<br />
* '''Kv''' electric engine constant in revolutions per minute to volt. <br />
* '''voltage''' The voltage applied to the motor e.g. Nominal battery voltage in Volts. <br />
* '''Rm''' The engine winding resistance in Ohms.<br />
<br />
<br />
Example:<br />
<br />
<syntaxhighlight lang="xml" line><br />
<propeller x="0.02" y="0" z="0.03"<br />
mass="0.05"<br />
moment="0.0006"<br />
radius="0.203"<br />
cruise-speed="26"<br />
cruise-rpm="7000"<br />
cruise-power="0.5"<br />
cruise-alt="2000"<br />
takeoff-power="0.70"<br />
takeoff-rpm="9200"<br />
contra="1"><br />
<actionpt x="0" y="0" z="0.03"/><br />
<electric-engine Kv="750" voltage="15" Rm="0.02" ><br />
<control-input axis="/controls/engines/engine[0]/throttle" control="THROTTLE"/><br />
</electric-engine><br />
</propeller><br />
</syntaxhighlight><br />
<br />
=== Landing gear ===<br />
==== gear ====<br />
Defines a landing gear. Accepts <control> subelements to map properties to steering and braking. Can also be used to simulate floats. Although the coefficients are still called ..fric, it is calculated in fluids as a drag (proportional to the square of the speed). In fluids gears are not considered to detect crashes (as on ground). <br />
* '''x,y,z:''' The location of the fully-extended gear tip.<br />
* '''compression:''' The distance in metres along the "up" axis that the gear will compress.<br />
* '''initial-load:''' The initial load of the spring in multiples of compression. Defaults to 0. (With this parameter a lower spring-constants will be used for the gear-> can reduce numerical problems (jitter)) '''Note:''' the spring-constant is varied from 0% compression to 20% compression to get continuous behavior around 0 compression. (could be physically explained by wheel deformation)<br />
* '''upx/upy/upz:''' The direction of compression, defaults to vertical (0,0,1) if unspecified. These are used only for a direction -- the vector need not be normalized, as the length is specified by "compression".<br />
* '''sfric:''' Static (non-skidding) coefficient of friction. Defaults to 0.8.<br />
* '''dfric:''' Dynamic friction. Defaults to 0.7.<br />
* '''stiction:''' Stiction to ground. Defaults to 0. stiction = "1" ensures the gear isn't sliding unintentionally (Note: please correct docu here for more detailed facts, developers didn't document this extension here and this is based on trial and guessing only)<br />
* '''spring:''' A dimensionless multiplier for the automatically generated spring constant. Increase to make the gear stiffer, decrease to make it squishier.<br />
* '''damp:''' A dimensionless multiplier for the automatically generated damping coefficient. Decrease to make the gear "bouncier", increase to make it "slower". Beware of increasing this too far: very high damping forces can make the numerics unstable. If you can't make the gear stop bouncing with this number, try increasing the compression length instead.<br />
* '''on-water:''' if this is set to "0" the gear will be ignored if on water. Defaults to "0"<br />
* '''on-solid:''' if this set to "0" the gear will be ignored if not on water. Defaults to "1"<br />
* '''speed-planing:'''<br />
* '''spring-factor-not-planing:''' At zero speed the spring factor is multiplied by spring-factor-not-planing. Above speed-planing this factor is equal to 1. The idea is, to use this for floats simulating the transition from swimming to planing. speed-planing defaults to 0, spring-factor-not-planing defaults to 1.<br />
* '''reduce-friction-by-extension:''' at full extension the friction is reduced by this relative value. 0.7 means 30% friction at full extension. If you specify a value greater than one, the friction will be zero before reaching full extension. Defaults to "0"<br />
* '''ignored-by-solver:''' with the on-water/on-solid tags you can have more than one set of gears in one aircraft, If the solver (who automatically generates the spring constants) would take all gears into account, the result would be wrong. E. G. set this tag to "1" for all gears, which are not active on runways. Defaults to "0". You can not exclude all gears in the solving process.<br />
<br />
Will define two properties associated with compression of landing gear:<br />
<br />
* '''compression-norm''' - range from 0..1, 0 means gear fully extended, 1 means fully compressed.<br />
* '''compression-m''' - vertical distance in metres that the wheel has moved in order to be on top of ground; this will usually be different from the animation distance.<br />
<br />
<syntaxhighlight lang="xml" line><br />
<!-- front gear --><br />
<br />
<gear x="0.0" y="0.0" z="-0.205"<br />
spring="0.9"<br />
damp="0.8"<br />
dfric="0.9"<br />
sfric="1.1"<br />
compression="0.051"><br />
<control-input axis="/controls/flight/rudder" control="STEER" square="true" src0="-1.0" src1="1.0" dst0="-0.3" dst1="0.3"/><br />
<control-input axis="/controls/gear/brake-right" control="BRAKE" split="true"/><br />
<control-input axis="/controls/gear/brake-parking" control="BRAKE" split="true"/><br />
</gear><br />
<br />
<!-- two rear gears --><br />
<br />
<gear x="-0.4" y="0.25" z="-0.205"<br />
spring="0.9"<br />
damp="0.8"<br />
dfric="0.9"<br />
sfric="1.1"<br />
compression="0.051"><br />
<control-input axis="/controls/gear/brake-right" control="BRAKE" split="true"/><br />
<control-input axis="/controls/gear/brake-parking" control="BRAKE" split="true"/><br />
</gear><br />
<br />
<gear x="-0.4" y="-0.25" z="-0.205"<br />
spring="0.9"<br />
damp="0.8"<br />
dfric="0.9"<br />
sfric="1.1"<br />
compression="0.051"><br />
<control-input axis="/controls/gear/brake-left" control="BRAKE" split="true"/><br />
<control-input axis="/controls/gear/brake-parking" control="BRAKE" split="true"/><br />
</gear><br />
</syntaxhighlight><br />
<br />
===== Torus-shaped contact surface on next =====<br />
<br />
On next as of 2022-3-19 one can specify a torus-shaped tyre contact surface using these new parameters:<br />
<br />
* '''wheel-x'''<br />
* '''wheel-y'''<br />
* '''wheel-z'''<br />
* '''wheel-radius''' (default 0)<br />
* '''tyre-radius''' (default 0)<br />
* '''wheel-axle-x'''<br />
* '''wheel-axle-y'''<br />
* '''wheel-axle-z'''<br />
<br />
The contact point will be the lowest point on a torus with radius '''tyre-radius''' wrapped around a wheel with radius '''wheel-radius''' centred on point '''(wheel-x, wheel-y, wheel-z)''' with orientation defined by '''wheel-axle'''. This contact point will depend on the aircraft's orientation relative to the ground.<br />
<br />
If not specified, '''wheel-axle''' defaults to (0, 1, 0), giving a conventional vertical wheel in line with the aircraft. Other values may allow modelling of, for example, a Bf109's non-vertical undercarriage.<br />
<br />
Default values of zero for wheel-radius and tyre-radius give a fixed contact point at (wheel-x, wheel-y, wheel-z).<br />
<br />
If an aircraft also specifies an old-style contact point with '''(x, y, z)''' it will work with both new and old builds of Flightgear.<br />
<br />
==== Launchbar ====<br />
Defines a catapult launchbar or strop.<br />
* '''x,y,z:''' The location of the mount point of the launch bar or strop on the aircraft.<br />
* '''length:''' The length of the launch bar from mount point to tip<br />
* '''down-angle:''' The max angle below the horizontal the launchbar can achieve.<br />
* '''up-angle:''' The max angle above the horizontal the launchbar can achieve.<br />
* '''holdback-{x,y,z}:''' The location of the holdback mount point on the aircraft.<br />
* '''holdback-length:''' The length of the holdback from mount point to tip. Note: holdback up-angle and down-angle are the same as those defined for the launchbar and are not specified in the configuration.<br />
<br />
=== Fuel ===<br />
==== tank ====<br />
A fuel tank. Tanks in the aircraft are identified numerically (starting from zero), in the order they are defined in the file. If the left tank is first, "tank[0]" will be the left tank. <br />
* '''x,y,z:''' The location of the tank.<br />
* '''capacity:''' The maximum contents of the tank, in pounds. Not gallons -- YASim supports fuels of varying densities.<br />
* '''jet:''' A boolean. If present, this causes the fuel density to be treated as Jet-A. Otherwise, gasoline density is used. A more elaborate density setting (in pounds per gallon, for example) would be easy to implement. Bug me.<br />
<br />
=== Center of Gravity ===<br />
==== Ballast ====<br />
This is a mechanism for modifying the mass distribution of the aircraft. A ballast setting specifies that a particular amount of the empty weight of the aircraft must be placed at a given location. The remaining non-ballast weight will be distributed "intelligently" across the fuselage and wing objects. Note again: this does NOT change the empty weight of the aircraft. <br />
* '''x,y,z:''' The location of the ballast.<br />
* '''mass:''' How much mass, in pounds, to put there. Note that this value can be negative. I find that I often need to "lighten" the tail of the aircraft.<br />
<br />
<br />
<syntaxhighlight lang="xml" line><br />
<ballast x="-0.24" y="0.0" z="0.33" mass-kg="0.5"/><br />
</syntaxhighlight><br />
<br />
==== Weight ====<br />
This is an added weight, something not part of the empty weight of the aircraft, like passengers, cargo, or external stores. The actual value of the mass is not specified here, instead, a mapping to a property is used. This allows external code, such as the panel, to control the weight (loading a given cargo configuration from preference files, dropping bombs at runtime, etc...)<br />
* '''x,y,z:''' The location of the weight.<br />
* '''mass-prop:''' The name of the fgfs property containing the mass, in pounds, of this weight.<br />
* '''size:''' The aerodynamic "size", in metres, of the object. This is important for external stores, which will cause drag. For reasonably aerodynamic stuff like bombs, the size should be roughly the width of the object. For other stuff, you're on your own. The default is zero, which results in no aerodynamic force (internal cargo).<br />
* '''solve-weight:''' Subtag of approach and cruise parameters. Used to specify a non-zero setting for a <weight> tag during solution. The default is to assume all weights are zero at the given performance numbers.<br />
* '''idx:''' Index of the weight in the file (starting with zero).<br />
* '''weight:''' Weight setting in pounds.<br />
<br />
<syntaxhighlight lang="xml" line><br />
<weight x="-0.06471" y="0.225" z="-0.2" mass-prop="/sim/weight[0]/weight-kg"/><br />
</syntaxhighlight><br />
<br />
=== Controls ===<br />
==== control-input ====<br />
This element manages a mapping from fgfs properties (user input) to settable values on the aircraft's objects. Note that the value to be set MUST (!) be valid on the given object type. This is not checked for by the parser, and will cause a runtime crash if you try it. Wing's don't have throttle controls, etc... Note that multiple axes may be set on the same value. They are summed before setting.<br />
* '''axis:''' The name of the double-valued fgfs property "axis" to use as input, such as "/controls/flight/aileron".<br />
* '''control:''' Which control axis to set on the objects. It can have the following values:<br />
** THROTTLE - The throttle on a jet or propeller. <br />
** MIXTURE - The mixture on a propeller.<br />
** REHEAT - The afterburner on a jet<br />
** PROP - The propeller advance<br />
** BRAKE - The brake on a gear.<br />
** STEER - The steering angle on a gear. <br />
** INCIDENCE - The incidence angle of a wing.<br />
** FLAP0 - The flap0 deflection of a wing. <br />
** FLAP1 - The flap1 deflection of a wing. <br />
** SLAT - The slat extension of a wing. <br />
** SPOILER - The spoiler extension for a wing. <br />
** CYCLICAIL - The "aileron" cyclic input of a rotor <br />
** CYCLICELE - The "elevator" cyclic input of a rotor <br />
** COLLECTIVE - The collective input of a rotor<br />
** ROTORENGINEON - If not equal zero the rotor is rotating <br />
** WINCHRELSPEED - The relative winch speed <br />
** {... and many more, see [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/FDM/YASim/ControlMap.cpp#l25 ControlMap.cpp] ...}<br />
* '''invert:''' Negate the value of the property before settling on the object.<br />
* '''split:''' Applicable to wing control surfaces. Sets the normal value on the left-wing, and a negated value on the right-wing.<br />
* '''square:''' Squares the value before setting. Useful for controls like a steering that needs a wide range, yet lots of sensitivity in the center. Obviously only applicable to values that have a range of [-1:1] or [0:1]. <br />
* '''src0/src1/dst0/dst1:''' If present, these define a linear mapping from the source to the output value. Input values in the range src0-src1 are mapped linearly to dst0-dst1, with clamping for input values that lie outside the range.<br />
<br />
==== control-output ====<br />
This can be used to pass the value of a YASim control axis (after all mapping and summing is applied) back to the property tree.<br />
* '''control:''' Name of the control axis. See above.<br />
* '''prop:''' Property node to receive the value.<br />
* '''side:''' Optional, for split controls. Either "right" or "left" <br />
* '''min/max:''' Clamping applied to output value.<br />
<br />
==== control-speed ====<br />
Some controls (most notably flaps and hydraulics) have maximum slew rates and cannot respond instantly to pilot input. This can be implemented with a control-speed tag, which defines a "transition time" required to slew through the full input range. Note that this tag is semi-deprecated, complicated control input filtering can be done much more robustly from a Nasal script.<br />
* '''control:''' Name of the control axis. See above.<br />
* '''transition-time:''' Time in seconds to slew through input range.<br />
<br />
==== control-setting ====<br />
This tag is used to define a particular setting for a control axis inside the <cruise> or <approach> tags, where obviously property input is not available. It can be used, for example, to inform the solver that the approach performance values assume full flaps, etc...<br />
* '''axis:''' Name of the control input (i.e. a property name)<br />
* '''value:''' Value of the control axis.<br />
<br />
=== Winch and Aerotow ===<br />
==== hitch ====<br />
A hitch, can be used for winch-start (in gliders) or aerotow (in gliders and motor aircraft) or for external cargo with helicopter. You can do aerotow over the net via multiplayer (see j3 and bocian as an example).<br />
* '''name:''' the name of the hitch. must be aerotow if you want to do aerotow via multiplayer. You will find many properties at /sim/hitches/name. Most of them are directly tied to the internal variables, you can modify them as you like. You can add a listener to the property "broken", e. g. for playing a sound.<br />
* '''x,y,z:''' The position of the hitch<br />
* '''force-is-calculated-by-other:''' if you want to simulate aerotowing over the internet, set this value to "1" in the motor aircraft. Don't specify or set this to zero in gliders. In a LAN the time lag might be small enough to set it on both aircraft to "0". It's intended, that this is done automatically in the future.<br />
==== tow ====<br />
The tow used for aerotow or winch. This must be a subelement of an enclosing <hitch> tag.<br />
* '''length:''' upstretched length in metres<br />
* '''weight-per-meter:''' in kg/metre<br />
* '''elastic-constant:''' lower values give higher elasticity<br />
* '''break-force:''' in N<br />
* '''mp-auto-connect-period:''' the every x seconds a towed multiplayer aircraft is searched. If found, this tow is connected automatically, parameters are copied from the other aircraft. Should be set only in the motor aircraft, not in the glider<br />
==== winch ====<br />
The tow used for aerotow or winch. This must be a subelement of an enclosing <hitch> tag.<br />
* '''max-tow-length:''' in m<br />
* '''min-tow-length''': in m<br />
* '''initial-tow-length:''' in m. The initial tow length also defines the length/search radius used for the mp-autoconnect feature<br />
* '''max-winch-speed:''' in m/s<br />
* '''power:''' in kW<br />
* '''max-force:''' in N<br />
<br />
<br />
<syntaxhighlight lang="xml" line><br />
<hitch name="winch" x="0.0" y="0.0" z="0.0"><br />
<tow length="50" weight-per-meter="0.0035" elastic-constant="40000" break-force="10000"/><br />
<!-- 3mm paracord--><br />
<winch max-tow-length="1000" min-tow-length="1" initial-tow-length="1000" max-winch-speed="20" power="2" max-force="80"/><br />
<control-input axis="/controls/winch/place" control="PLACEWINCH"/><br />
</hitch><br />
<hitch name="aerotow" x="0.0" y="0.0" z="0.0" force-is-calculated-by-other="0"><br />
<tow length="60" weight-per-meter="0.0035" elastic-constant="9000" break-force="100" mp-auto-connect-period="0.0"/><br />
<winch max-tow-length="1000" min-tow-length="60" initial-tow-length="60"/><br />
<control-input axis="/controls/aerotow/find-aircraft" control="FINDAITOW"/><br />
</hitch><br />
</syntaxhighlight><br />
<br />
== Visualization ==<br />
<br />
=== Blender visualization tool ===<br />
<br />
[[File:Yasim_visualisation_dc6.png|thumb|dc6 FDM in Blender]]To make the programmed aircraft visible it is possible to load and compare it with the 3D model within [[Blender]]. They applaud for this ''very'' useful script goes to M. Franz, thank you very much!<br />
<br />
For Blender versions <= 2.4 the script is located in FlightGears source code {{flightgear file|utils/Modeller/yasim_import.py}}.<br />
<br />
For Blender versions newer than 2.4, please see [[Blender YASim import]].<br />
<br />
The howto, taken from inside the script:<br />
<br />
yasim_import.py loads and visualizes a YASim FDM geometry<br />
=========================================================<br />
<br />
It is recommended to load the model superimposed over a greyed out and immutable copy of the aircraft model:<br />
<br />
(0) put this script into ~/.blender/scripts/<br />
(1) load or import aircraft model (menu -> "File" -> "Import" -> "AC3D (.ac) ...")<br />
(2) create new *empty* scene (menu -> arrow button left of "SCE:scene1" combobox -> "ADD NEW" -> "empty")<br />
(3) rename scene to yasim (not required)<br />
(4) link to scene1 (F10 -> "Output" tab -> arrow button left of text entry "No Set Scene" -> "scene1")<br />
(5) now load the YASim config file (menu -> "File" -> "Import" -> "YASim (.xml) ...")<br />
<br />
This is good enough for simple checks. But if you are working on the YASim configuration, then you need a<br />
quick and convenient way to reload the file. In that case, continue after (4):<br />
<br />
(5) switch the button area at the bottom of the blender screen to "Scripts Window" mode (green python snake icon)<br />
(6) load the YASim config file (menu -> "Scripts" -> "Import" -> "YASim (.xml) ...")<br />
(7) make the "Scripts Window" area as small as possible by dragging the area separator down<br />
(8) optionally split the "3D View" area and switch the right part to the "Outliner"<br />
(9) press the "Reload YASim" button in the script area to reload the file<br />
<br />
<br />
If the 3D model is displaced with respect to the FDM model, then the <offsets> values from the<br />
model animation XML file should be added as comment to the YASim config file, as a line all by<br />
itself, with no spaces surrounding the equal signs. Spaces elsewhere are allowed. For example:<br />
<br />
<offsets><br />
<x-m>3.45</x-m><br />
<z-m>-0.4</z-m><br />
<pitch-deg>5</pitch-deg><br />
</offsets><br />
<br />
becomes:<br />
<br />
<!-- offsets: x=3.45 z=-0.4 p=5 --><br />
<br />
Possible variables are:<br />
<br />
x ... <x-m><br />
y ... <y-m><br />
z ... <z-m><br />
h ... <heading-deg><br />
p ... <pitch-deg><br />
r ... <roll-deg><br />
<br />
Of course, absolute FDM coordinates can then no longer directly be read from Blender's 3D view.<br />
The cursor coordinates display in the script area, however, shows the coordinates in YASim space.<br />
Note that object names don't contain XML indices but element numbers. YASim_hstab#2 is the third<br />
hstab in the whole file, not necessarily in its parent XML group. A floating-point part in the<br />
object name (e.g. YASim_hstab#2.004) only means that the geometry has been reloaded that often.<br />
It's an unavoidable consequence of how Blender deals with meshes.<br />
<br />
<br />
Elements are displayed as follows:<br />
<br />
cockpit -> monkey head<br />
fuselage -> blue "tube" (with only 12 sides for less clutter); center at "a"<br />
vstab -> red with yellow flaps<br />
wing/mstab/hstab -> green with yellow flaps/spoilers/slats (always 20 cm deep);<br />
symmetric surfaces are only displayed on the left side<br />
thrusters (jet/propeller/thruster) -> dashed line from center to actionpt;<br />
arrow from actionpt along thrust vector (always 1 m long);<br />
propeller circle<br />
rotor -> radius and rel_len_blade_start circle, direction arrow,<br />
normal and forward vector, one blade at phi0<br />
gear -> contact point and compression vector (no arrow head)<br />
tank -> cube (10 cm side length)<br />
weight -> inverted cone<br />
ballast -> cylinder<br />
hitch -> circle (10 cm diameter)<br />
hook -> dashed line for up angle, T-line for down angle<br />
launchbar -> dashed line for up angles, T-line for down angles<br />
A note about step (0) for Windows users: the mentioned path is inside the folder where Blender lives, something like <code>C:\Program Files\Blender Foundation\Blender\.blender\scripts</code>.<br />
<br />
=== Visualize model in OpenSCAD or FreeCAD ===<br />
<br />
There exist a possibility to display the YASim XML elements in the OpenSCAD or FreeCAD tools. This could be extremely useful in the case of UAV aircraft development. <br />
<br />
* [https://github.com/ThunderFly-aerospace/YASim2SCAD YASim2SCAD] - This tool converts YASim XML to scad file which could be displayed as an overlay in OpenSCAD or FreeCAD project.<br />
* [https://gitlab.com/yasimtoscad/yasimtoscad yasimtoscad] - Another tool to convert YASim XML to scad file which could be displayed as an overlay in OpenSCAD.<br />
<br />
<br />
=== Visualization tools ===<br />
<br />
* [https://github.com/bitwisetech/ysimi YSIMI] Interactive Tuning Tools for FlightGear's YASIM Flight Dynamics Model<br />
* [https://github.com/bitwisetech/yasiVers yasiVers] is a tool for visualization of YASim calculations.<br />
<br />
== Export of YASim internals to property tree ==<br />
Ever wondered what is going on inside yasim? See the property tree under /fdm/yasim/<br />
<br />
Some information is static and shows what yasim has compiled from your XML. <br />
Other information is "run-time" like forces, speed, acceleration, c.g. <br />
<br />
If note noted otherwise:<br />
* expect metric unit (meter, kilogram, newton, ...)<br />
* expect minimum version 2017.2<br />
<br />
{| class="wikitable"<br />
|-<br />
! Path !! Description !! Information type !! min. version<br />
|-<br />
| accelerations/ || linear and rot. accelerations in aircraft coord. || run time ||<br />
|-<br />
| debug/ || misc internals, for now subject to change without notice || run time || 2018.1<br />
|-<br />
| forces/ || aerodynamic forces in N || run time ||<br />
|-<br />
| velocities/ || linear and rot. velocities in aircraft coord. || run time ||<br />
|-<br />
| model/cg-x-range-aft || desired CG range || compile time ||<br />
|-<br />
| model/cg-x-range-front || desired CG range || compile time ||<br />
|-<br />
| model/cg-x-max || CG hard limit from gear position || compile time ||<br />
|-<br />
| model/cg-x-min || CG hard limit from gear position || compile time ||<br />
|-<br />
| model/masses || shows the calculated mass points || compile time ||<br />
|-<br />
| model/wings || wing parameters || compile time ||<br />
|}<br />
<br />
<br />
== Command Line ==<br />
=== Windows ===<br />
By using the standard command line, we can see what the YASim solver is calculating. First, open up Command Prompt, enter in the location of yasim.exe, and then the location of the YASim XML file. For example, here's what you would type in for a standard Windows [[Changelog_2.12|FlightGear 2.12.0]] installation, and viewing the [[F-14_Tomcat|F-14B's]] YASim file.<br />
{{Note|You can copy & paste the examples into Command Prompt by right-clicking on the title and navigate to Edit > Paste. Then, click Enter to execute.}} <br />
<br />
<code>"C:\Program Files\FlightGear\bin\Win32\yasim.exe" "C:\Program Files\FlightGear\data\Aircraft\f-14b\f-14b-yasim.xml"</code><br />
<br />
The results will give many different values.<br />
<br />
* '''Drag Coefficient:''' The drag coefficient of the aircraft.<br />
* '''Lift Ratio:''' The lift ratio of the aircraft.<br />
* '''Cruise AoA:''' The cruise AoA, from conditions at [[YASim#cruise|<cruise>]] in the xml file.<br />
* '''Tail Incidence:''' The incidence angle of the tail, "solved" by YASim as a way to stabilize the aircraft.<br />
* '''Approach Elevator:''' The approach elevator, from conditions at [[YASim#approach|<approach>]] in the xml file.<br />
* '''CG:''' Center of gravity of the aircraft in coordinates. Unless it's supposed to be offset, it should always have a Y value of 0.<br />
<br />
The YASim standalone solver also has some command line flags that change it's behaviour.<br />
<br />
<code>"C:\Program Files\FlightGear\bin\Win32\yasim.exe" "C:\Program Files\FlightGear\data\Aircraft\f-14b\f-14b-yasim.xml" -g -a 1000 -s 490</code><br />
<br />
* '''-g:''' Instructs YASim to generate space-separated tabular data instead of the usual solver output. This can be redirected to a file and used in various plotting programs to visualize the actual lift, drag, L/D curves. The columns of the output from left to right are: AoA, Lift, Drag, L/D. (aoa in degrees, lift and drag in G's).<br />
* '''-a <altitude in meter:>''' Run the solver at the given altitude in meter.<br />
* '''-s <speed in knots>:''' Also run at the given airspeed in knots.<br />
<br />
{{Note|The values generated by this method are for the aircraft taken as a whole, as solved by YASim, so they differ from the values of the wing airfoil.}}<br />
<br />
To get the tabular output for the example above at 1000 m and 150 knots, and to redirect this to a file, one would issue:<br />
<br />
<code>"C:\Program Files\FlightGear\bin\Win32\yasim.exe" "C:\Program Files\FlightGear\data\Aircraft\f-14b\f-14b-yasim.xml" -g -a 1000 -s 150 > "C:\Program Files\FlightGear\yasim.txt"</code><br />
<br />
== New features and bugfixes in version 2017.2 ==<br />
<br />
=== XML parser ===<br />
==== support for metric and imperial units ====<br />
To make life easier for aircraft developers, the parser supports new additional attributes with a unit suffix, e.g. speed-kt for knots and speed-kmh for kilometers per hour.<br />
* <code><airplane {mass, mass-lbs, mass-kg}="12345" ></code><br />
* <code><approach {speed, speed-kt, speed-kmh}="123" ></code><br />
* <code><cruise {speed, speed-kt, speed-kmh}="123" ></code><br />
* <code><solve-weight {weight, weight-lbs, weight-kg}="123" ></code><br />
* <code><jet {mass, mass-lbs, mass-kg}="1234" ></code><br />
* <code><tank {capacity, capacity-lbs, capacity-kg}="12345" ></code><br />
* <code><ballast {mass, mass-lbs, mass-kg}="1234" ></code><br />
<br />
{{Note|Aircraft using this new attributes will not run on older versions of FlightGear, so it is probably wise to publish those only after a reasonable number of users switched version 2017.2 or newer.}}<br />
<br />
==== CG tuning help ====<br />
{{Note| The feature described in this section is not fully implemented yet, however, it may be of some help already.<br />
It is currently implemented for the yasim CLI tool only. It does not affect the airplane behaviour while running FlightGear. }}<br />
<br />
New attributes have been added to <airplane> to assist tuning the center of gravity (CG).<br />
The CG position is often expressed relative to the [https://en.wikipedia.org/wiki/Chord_(aeronautics)#Mean_aerodynamic_chord MAC] of the wing in percent. You can specify a desired range for CG in % relative to MAC, it will show up in the output of the yasim CLI tool (see example below):<br />
<br />
* cg-min: default 25% (just a guess, better numbers are welcome)<br />
* cg-max: default 30% (just a guess, better numbers are welcome)<br />
<br />
{{Note| By convention 0% is leading edge, 100% is trailing edge, however the absolute values on x-axis are the other way round, e.g. nose is +x, tail is -x }}<br />
{{warning|The MAC calculation in version 2017.2 works only on the <wing> element. Numbers will be wrong, if your model uses a combination of <wing> and <mstab> to build a wing with two or more sections.<br />
Section support will be added in version 2018.1}}<br />
YASim will print the leading edge coordinates of the MAC (x,y) and its length.<br />
<br />
'''Example output'''<br />
<pre><br />
$ yasim Citation-II-yasim.xml <br />
This aircraft uses yasim version '2017.2' <br />
========================== <br />
= YASim solution results = <br />
========================== <br />
Iterations: 2210 <br />
Drag Coefficient: 12.304669 <br />
Lift Ratio: 85.317558 <br />
Cruise AoA: 4.016746 deg <br />
Tail Incidence: -3.053278 deg <br />
Approach Elevator: -0.377542 <br />
<br />
CG: x:-6.543, y:-0.000, z:0.044 <br />
Wing MAC (*1): x:-6.00, y:3.83, length:2.0 <br />
CG-x rel. MAC: 0.272 <br />
CG-x desired: -6.599 < -6.543 < -6.198 <br />
<br />
Inertia tensor [kg*m^2], origo at CG: <br />
<br />
18009.289, -0.000, 7120.470 <br />
-0.000, 42459.316, 0.000 <br />
7120.470, 0.000, 56980.656 <br />
<br />
(*1) MAC calculation works on <wing> only! Numbers will be wrong for segmented wings, e.g. <wing>+<mstab>.<br />
</pre><br />
<br />
=== Aircraft developer helpers ===<br />
The command line utility got some new options. For some strange reason, the -a parameter expects altitude in meters instead of ft. This is now visible in the usage message but left unchanged for compatibility.<br />
<syntaxhighlight>Usage:<br />
yasim <aircraft.xml> [-g [-a meters] [-s kts] [-approach | -cruise] ]<br />
yasim <aircraft.xml> [-d [-a meters] [-approach | -cruise] ]<br />
yasim <aircraft.xml> [-m]<br />
-g print lift/drag table: aoa, lift, drag, lift/drag <br />
-d print drag over TAS: kts, drag<br />
-a set altitude in meters!<br />
-s set speed in knots<br />
-m print mass distribution table: id, x, y, z, mass</syntaxhighlight><br />
<br />
=== Bugfixes ===<br />
The following bugfixes require <airplane version="2017.2"> for backward compatibility <br />
* Ground effect: corrected the calculation of the height where g.e. ends<br />
* Stall parameters were set wrong for wings with camber=0<br />
<br />
== New features and bugfixes in version 2018.1 ==<br />
The following is under development and hopefully finds its way into FG version 2018.1<br />
<br />
=== Wing Section Support ===<br />
Many airliners have wings with a geometry that is just a little more complex than what YASim supported initially (tapered wing with some angles like sweep, dihedral, ...), e.g. they have an inboard section and an outboard section that can be described with YASim wing syntax. You can use a wing + a mstab XML element to describe this geometry but it is easier if YASim can just append more wing sections by simply adding more wing XML elements. This is now (Version 2018.1) possible, yasim will simply append sections if it finds more than one wing or hstab in the XML.<br />
You should use '''&lt;wing append="1" ... &gt;''' for all but the first wing/hstab declaration. <br />
{{Note|YASim will ignore the root point (x,y,z), the chord length and the incidence attributes, if you add "append" and calculate those from the previous wing section. }}<br />
MAC calculation works for the whole wing.<br />
<br />
{{warning|Aircrafts using this feature will not work with older versions of flightgear. }}<br />
To keep the aircraft backward compatible for a while, it is recommended to create a copy of its yasim XML file for development. <br />
Once you are happy with the CG and wing parameters you can use the output of the YASim CLI tool to modifiy the original XML. <br />
The tool will output the needed x,y,z etc per wing section to create a XML in old format with (only one) <wing> + <mstab>.<br />
<br />
=== More information from CLI tools ===<br />
You should configure the maximum take of weight (MTOW) in your XML file by adding either ''mtow-lbs'' or ''mtow-kg'' attribute to the airplane:<br />
<br />
<code> &lt;airplane mass="7500" version="2018.1" mtow-lbs="12500"&gt; </code><br />
<br />
'''Example output'''<br />
<pre><br />
yasim CRJ700.xml <br />
==========================<br />
= YASim solution results =<br />
==========================<br />
Iterations : 1024<br />
Drag Coefficient : 17.707<br />
Lift Ratio : 145.841<br />
Cruise AoA : -0.11 deg<br />
Tail Incidence : 3.47 deg<br />
Approach Elevator : -0.792<br />
<br />
CG : x:-0.046, y:0.000, z:-1.222<br />
Wing MAC : (x:0.79, y:4.99), length:3.4 <br />
hard limit CG-x : 14.232 m<br />
soft limit CG-x : -0.058 m<br />
CG-x : -0.046 m<br />
CG-x rel. MAC : 25%<br />
soft limit CG-x : -0.228 m<br />
hard limit CG-x : -0.986 m<br />
<br />
wing lever : -0.012 m<br />
tail lever : -13.997 m<br />
<br />
max thrust : 157.18 kN<br />
thrust/empty : 0.81<br />
thrust/mtow : 0.49<br />
<br />
wing span : 22.64 m<br />
sweep lead. edge : 30.2 .. 30.6 deg<br />
wing area : 58.70 m^2<br />
wing load empty : 336.15 kg/m^2 (Empty 19731 kg)<br />
wing load MTOW : 562.18 kg/m^2 (MTOW 32999 kg)<br />
<br />
tail span : 8.533 m<br />
tail area : 14.838 m^2<br />
<br />
#wing sections: 2<br />
Section 0 base point (0.450, 1.226, -2.034), chord 5.085, incidence at section root 5.0deg<br />
Section 1 base point (-0.663, 4.754, -1.942), chord 3.204, incidence at section root 3.0deg<br />
<br />
Inertia tensor [kg*m^2], origo at CG:<br />
<br />
195646, 0, 122265<br />
0, 1757279, 0<br />
122265, 0, 1904528<br />
</pre><br />
<br />
=== Variable tail incidence / elevator trim ===<br />
Small GA aircrafts usually trim with a trim tab on the elevator. For efficiency, airliners normally do not trim the elevator ("flap") <br />
but rotate the whole stabilizer (=tail) wing, e.g. they change the incidence for this wing. While this feature was somehow foreseen, <br />
it was not implemented yet, most likely because the "tail incidence" is one of the free variables used by the YASim solver. <br />
However, it is possible now to use the control="INCIDENCE" within the &lt;hstab&gt; to implement an alternative trim '''while maintaining full elevator authority'''.<br />
<pre><br />
<hstab ... incidence-min-deg="-13.0" incidence-max-deg="2.0"><br />
...<br />
<control-input axis="/controls/flight/hstab-trim" control="INCIDENCE" /><br />
<control-speed control="INCIDENCE" transition-time="20.0" /><br />
<control-output control="INCIDENCE" prop="/surface-positions/hstab-rad" /> <br />
</hstab><br />
</pre><br />
{{Note|The control output of INCIDENCE is the angle in radians, not in degree, as that is the unit internally used by YASim.}}<br />
{{warning|The OPTIONAL incidence-min-deg and incidence-max-deg set the limits for the solver. You must make sure to select a sufficiently large range or solver will fail. }}<br />
First experiments with this feature were successful in that the aircraft pitch could be changed as expected but fine tuning will be necessary.<br />
<br />
<br />
== Related content ==<br />
* [[Howto:Make a helicopter#XML Elements]] &ndash; Rotor and rotorgear YASim elements<br />
* [[Towing]]<br />
* [[YASim Development Tools]]<br />
<br />
== External links ==<br />
* {{cite web<br />
| url = http://www.buckarooshangar.com/flightgear/yasimtut.html<br />
| title = Guide to YASim<br />
| first = Gary R. "Buckaroo"<br />
| last = Neely<br />
| authorlink = http://www.buckarooshangar.com/flightgear/<br />
| date = 2013<br />
| accessdate = April 16, 2020<br />
}} - A very helpful guide<br />
* {{cite web<br />
| url = https://sourceforge.net/projects/dacpei/<br />
| title = DACPEI<br />
| author = pytoche<br />
| date = February 2012<br />
| publisher = SourceForge<br />
| accessdate = April 16, 2020<br />
}} - A fixed wing light aircraft WYSIWUG concept design suite that can export an YASim FDM to FlightGear.<br />
<br />
{{FDM}}<br />
<br />
[[Category:Flight Dynamics Model]]<br />
<br />
[[fr:YASim]]</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=YASim&diff=134807YASim2022-03-20T00:24:47Z<p>Cgdae: /* gear */ Describe new support for torus tyre surface on next.</p>
<hr />
<div>[[File:yasimlogo.png|thumb]] <br />
<br />
'''YASim''' is one of two [[flight dynamics model]]s commonly used in [[FlightGear]]. The flight dynamics model (FDM) determines how the [[aircraft]] moves and flies.<br />
<br />
Gary Neely wrote in his [http://www.buckarooshangar.com/flightgear/ introduction to YASim]:<br />
<br />
:''The FDM is the mathematical model that controls the physics of flight within the simulator. The physical 3D aircraft model has nothing to do with flight dynamics-- in essence it's just a picture to look at. It's the FDM that dictates how the model flies.''<br />
<br />
:''Why YASim? YASim uses the geometry of the aircraft to generate the base flight characteristics. While this suggests a 'realistic' or out-of-the-box approach, it is a only rough approximation that will require much tweaking before you get a result that approaches realism. If you have solid flight data for your aircraft such as wind-tunnel data or you are looking to eventually generate a hyper-realistic simulation, JSBSim is probably a better approach. If you lack such data but know the geometry of the aircraft and have access to the same flight characteristics and limits as a real pilot would, then YASim can provide a solution that is more than sufficient for most simulation needs.''<br />
<br />
== Coordinate system notes ==<br />
All positions specified are in metres (which is weird, since all other units in the file are English). The X axis points forward, Y is left, and Z is up. Take your right hand, and hold it like a gun. Your first and second fingers are the X and Y axes, and your upwards-pointing thumb is the Z. This is slightly different from the coordinate system used by [[JSBSim]]. Sorry. The origin can be placed anywhere, so long as you are consistent. I use the nose of the aircraft.<br />
<br />
(In the [[JSBSim_Aerodynamics#Frames|JSBSim coordinate system]], X and Z are the same as in YASim, but Y points to the right instead of left.)<br />
<br />
=== Checking alignment with Blender ===<br />
<br />
Blender can display a '''.ac''' model and a yasim model at the same time, allowing one to check whether the wings, gear contact points etc are aligned correctly. But it seems that Blender ignores any top-level <code>loc <x> <y> <z></code> specification in the '''.ac''' file, which makes it non-trivial to check alignment if such a specification is used.<br />
<br />
== YASim design notes ==<br />
Andy Ross's original design notes for YASim can be found in [https://pdfhost.io/v/~iYsLl7xS_alldvi.pdf this PDF file]. These provide some useful background for how YASim works.<br />
<br />
== XML Elements ==<br />
<!-- To future editors: The all lowercase headings are XML tags and should ''probably'' be left that way --><br />
=== airplane ===<br />
The top-level element for the file. It contains the following attributes: <br />
* '''mass:''' The empty (no fuel) weight, in pounds. It does include the weight of the engine(s), so when you add the engine weight in its tag, it acts just like a ballast.<br />
* '''version:''' The version attribute is used to maintain compatibility when updating yasim (e.g. bugfixes). If this attribute i not given, the original version will be used. Several bugfixes to YASim were implemented in FlightGear 3.2 (see [[FlightGear Newsletter April 2014]]), some more are fixed in FlightGear 2017.2. <br />
Available versions are:<br />
* <code>YASIM_VERSION_ORIGINAL</code> explicitly use the old buggy calculations (same as no version attribute at all)<br />
* <code>YASIM_VERSION_32</code> enable bugfixes up to version 3.2<br />
* <code>2017.2</code> enable bugfixes up to version 2017.2<br />
* <code>2018.1</code> (FIXME) no bugfixes by now. Use this version if your aircraft makes use of new features in YASim 2018.1 so it will cause at least a warning with older FG versions. <br />
* <code>YASIM_VERSION_CURRENT</code> use latest version compiled into the users FlightGear. <br />
{{Warning| Using YASIM_VERSION_CURRENT might make the aircraft unusable in case of future changes to YASim without updating the aircraft accordingly.}}<br />
<br />
'''New in 2018.1'''<br />
* '''mtow-lbs''' and '''mtow-kg:''' use one of them to specify max. takeoff weight. Does not affect the FDM, but is used by CLI tool to calculate some numbers.<br />
<br />
=== approach ===<br />
The approach parameters for the aircraft. The solver will generate an aircraft that matches these settings (by adjusting the parameters of the surface like drag and lift). It is extremely important to give parameters which could be really achieved by defined aircraft geometry, otherwise, it gives an unstable or not flyable result. The element can (and should) contain <control> elements indicating pilot input settings, such as flaps and throttle, for the approach.<br />
<br />
* '''speed:''' The approach airspeed, in knots TAS.<br />
* '''aoa:''' The approach angle of attack, in degrees<br />
* '''fuel:''' Fraction (0-1) of fuel in the tanks. Default is 0.2.<br />
<br />
=== cruise ===<br />
The cruise speed and altitude for the solver to match. As above, this should contain <control> elements indicating aircraft configuration. Especially, make sure the engines are generating enough thrust at cruise!<br />
* '''speed:''' The cruise speed, in knots TAS.<br />
* '''alt:''' The cruise altitude, in feet MSL.<br />
* '''fuel:''' Fraction (0-1) of fuel in the tanks. Default is 0.2.<br />
=== cockpit ===<br />
The location of the cockpit (pilot eyepoint).<br />
* '''x,y,z:''' eyepoint location (see coordinates note)<br />
<br />
=== fuselage ===<br />
This defines a tubelike structure. It will be given an even mass and aerodynamic force distribution by the solver. You can have as many as you like, in any orientation you please.<br />
* '''ax,ay,az:''' One end of the tube (typically the front)<br />
* '''bx,by,bz:''' The other ("back") end.<br />
* '''width:''' The width of the tube, in metres.<br />
* '''taper:''' The approximate radius at the "tips" of the fuselage expressed as a fraction (0-1) of the width value.<br />
* '''midpoint:''' The location of the widest part of the fuselage, expressed as a fraction of the distance between A and B.<br />
* '''idrag:''' Multiplier for the "induced drag" generated by this object. Default is one. With idrag=0 the fuselage generates only drag.<br />
* '''cx,cy,cz:''' Factors for the generated drag in the fuselages "local coordinate system" with x pointing from end to front, z perpendicular to x with y=0 in the aircraft coordinate system. E.g. for a fuselage of a height of 2 times the width you can define cy=2 and (due to the doubled front surface) cx=2.<br />
<br />
=== Surfaces ===<br />
==== wing ====<br />
This defines the main wing of the aircraft. You can have only one (but see below about using vstab objects for extra lifting surfaces). The wing should have a <stall> subelement to indicate stall behavior, control surface subelements (flap0, flap1, spoiler, slat) to indicate what and where the control surfaces are, and <control> subelements to map user input properties to the control surfaces.<br />
* '''x,y,z:''' The "base" of the wing, specified as the location of the mid-chord (not leading edge, trailing edge, or aerodynamic center) point at the root of the LEFT (!) wing.<br />
* '''length:''' The length from the midchord point of the base of the wing to the midchord point at the tip. Note that this is not the same thing as span.<br />
* '''chord:''' The chord of the wing at its base, along the X axis (not normal to the leading edge, as it is sometimes defined).<br />
* '''incidence:''' The incidence angle at the wing root, in degrees. Zero is level with the fuselage (as in an aerobatic plane), positive means that the leading edge is higher than the trailing edge (as in a trainer).<br />
* '''twist:''' The difference between the incidence angle at the wing root and the incidence angle at the wing tip. Typically, this is a negative number so that the wing tips have a lower angle of attack and stall after the wing root (washout).<br />
* '''taper:''' The taper fraction, expressed as the tip chord divided by the root chord. A taper of one is a hershey bar wing, and zero would be a wing ending at a point. Defaults to one.<br />
* '''sweep:''' The sweep angle of the wing, in degrees. Zero is no sweep, positive angles are swept back. Defaults to zero. [This looks to be the sweep of the mid-chord of the wing, not the sweep of the leading edge.]<br />
* '''dihedral:''' The dihedral angle of the wing. Positive angles are upward dihedral. Defaults to zero.<br />
* '''idrag:''' Multiplier for the "induced drag" generated by this surface. In general, low aspect wings will generate less induced drag per-AoA than high aspect (glider) wings. This value isn't constrained well by the solution process, and may require tuning to get throttle settings correct in high AoA (approach) situations.<br />
* '''effectiveness:''' Multiplier for the "normal" drag generated by the wing. Defaults to 1. Arbitrary, dimensionless factor. <br />
* '''camber:''' The lift produced by the wing at zero angle of attack, expressed as a fraction of the maximum lift produced at the stall AoA.<br />
* '''flow:''' The flow regime for the wing. Valid values are "SUBSONIC" (default) and "TRANSONIC". Setting surface to transonic adds more lift above mach number 0.6 by applying a Prandl/Glauert correction term to each surface-element. The effect is a more balanced lift/drag distribution reported by the solver. Use for anything that flies faster than mach 0.6 or has supercritical airfoils.<br />
* '''mcrit:''' The critical mach number for the wing. This point defines the begin of exponential drag rise due to mach speed. Default "0.6", only available if flow="TRANSONIC".<br />
<br />
'''Wing section support (since 2018.1):'''<br />
<br />
Wing section support to define variable geometry (geometry parameters per section)<br />
* More than one <wing>-element is allowed now. <br />
* x, y, z, chord and incidence attribute shall be specifed only for the first <wing> in the XML file. They will be overridden for subsequent <wing>-elements.<br />
* Use '''append="1"''' for additional '''wing''' elements to skip x, y, z, chord and incidence attribute as the will be calculated from previous '''wing''' element tip chord. This workaround is currently needed due to limitations in the XML parser.<br />
<br />
==== hstab ====<br />
These define the horizontal stabilizer of the aircraft. Internally, it is just a wing object and therefore works the same in XML. <br />
You are allowed only one hstab object; the solver needs to know which wing's incidence to play with to get the aircraft trimmed correctly.<br />
<br />
'''New in 2018.1:'''<br />
* '''hstab''' supports sections in the same way '''wing''' does, but it is still considered as /the/ (only) hstab used by the solver.<br />
* '''incidence-min-deg''' and '''incidence-max-deg''': optional attributes to limit valid result range fore the solver. Use with care or you won't get a solution.<br />
<br />
==== vstab ====<br />
A "vertical" stabilizer. Like hstab, this is just another wing, with a few special properties. The surface is not "mirrored" as are wing and hstab objects. If you define a left wing only, you'll only get a left wing. The default dihedral, if unspecified, is 90 degrees instead of zero. But all parameters are equally settable, so there's no requirement that this object be "vertical" at all. You can use it for anything you like, such as extra wings for biplanes. Most importantly, these surfaces are not involved with the solver computation, so you can have none, or as many as you like.<br />
<br />
==== mstab ====<br />
A mirrored horizontal stabilizer. Exactly the same as wing, but not involved with the solver computation, so you can have none, or as many as you like.<br />
<br />
==== stall ====<br />
A subelement of a wing (or hstab/vstab/mstab) that specifies the stall behavior.<br />
* '''aoa:''' The stall angle (maximum lift) in degrees. Note that this is relative to the wing, not the fuselage (since the wing may have a non-zero incidence angle).<br />
* '''width:''' The "width" of the stall, in degrees. A high value indicates a gentle stall. Low values are viscious for a non-twisted wing, but are acceptable for a twisted one (since the whole wing will not stall at the same time).<br />
* '''peak:''' The height of the lift peak, relative to the post-stall secondary lift peak at 45 degrees. Defaults to 1.5. This one is deep voodoo, and probably doesn't need to change much. Bug me for an explanation if you're curious.<br />
<br />
==== flap0, flap1, slat, spoiler ====<br />
These are subelements of wing/hstab/vstab objects, and specify the location and effectiveness of the control surfaces.<br />
* '''start:''' The position along the wing where the control surface begins.Zero is the root, one is the tip.<br />
* '''end:''' The position where the surface ends, as above.<br />
* '''lift:''' The lift multiplier for a flap or slat at full extension. One is a no-op, a typical aileron might be 1.2 or so, a giant jetliner flap 2.0, and a spoiler 0.0. For spoilers, the interpretation is a little different -- they spoil only "prestall" lift. Lift due purely to "flat plate" effects isn't affected. For typical wings that stall at low AoA's essentially all lift is pre-stall and you don't have to care. Jet fighters tend not to have wing spoilers, for exactly this reason. This value is not applicable to slats, which affect stall AoA only.<br />
* '''drag:''' The drag multiplier, as above. Typically should be higher than the lift multiplier for flaps.<br />
* '''aoa:''' Applicable only to slats. This indicates the angle by which the stall AoA is translated by the slat extension.<br />
<br />
=== Rotor and rotorgear ===<br />
YASim has also possibility to simulate rotorcraft blades. The number properties of rotor elements are large therefore are spitted to the separate page [[Howto:Make a helicopter#XML%20Elements|howto make a helicopter in YASim]].<br />
<br />
=== Engine ===<br />
==== Thruster ====<br />
A very simple "thrust only" engine object. Useful for things like thrust vectoring nozzles. All it does is map its THROTTLE input axis to its output thrust rating. Does not consume fuel, etc...<br />
* '''thrust:''' Maximum thrust in pounds<br />
* '''x,y,z:''' The point on the airframe where thrust will be applied.<br />
* '''vx,vy,vy:''' The direction of the thrust in airframe coordinates. The vector will be normalized automatically, so any non-zero vector will work fine.<br />
<br />
Example: <br />
<br />
<syntaxhighlight lang="xml" line><br />
<thruster x="0" y="0" z="0.03" vx="1" vy="0" vz="0" thrust="6.61"><br />
<control-input axis="/controls/engines/engine[0]/throttle" control="THROTTLE" src0="-1" src1="1" dst0="-1" dst1="1"/><br />
</thruster><br />
</syntaxhighlight><br />
<br />
==== Jet ====<br />
A turbojet/fan engine. It accepts a <control> subelement to map a property to its throttle setting, and an <actionpt> subelement to place the action point of the thrust at a different position than the mass of the engine.<br />
* '''x,y,z:''' The location of the engine, as a point mass. If no actionpt is specified, this will also be the point of application of thrust.<br />
* '''mass:''' The mass of the engine, in pounds.<br />
* '''thrust:''' The maximum sea-level thrust, in pounds.<br />
* '''afterburner:''' Maximum total thrust with afterburner/reheat, in pounds [defaults to "no additional thrust"].<br />
* '''rotate:''' Vector angle of the thrust in degrees about the Y axis [0].<br />
* '''n1-idle:''' Idling low pressure core / fan speed [55]. <br />
* '''n1-max:''' Maximum low pressure core / fan speed [102].<br />
* '''n2-idle:''' Idling high pressure core speed [73].<br />
* '''n2-max:''' Maximum high pressure core speed [103].<br />
* '''tsfc:''' Thrust-specific fuel consumption [0.8]. This should be considerably lower for modern turbofans.<br />
* '''atsfc:''' (version >= 2016.3.1) Thrust specific fuel consumption with afterburner on. When set to zero defaults to older behaviour where it is calculated from dry fuel consumption [0].<br />
* '''egt:''' Exhaust gas temperature at takeoff in K [1050].<br />
* '''epr:''' Engine pressure ratio at takeoff [3.0].<br />
* '''exhaust-speed:''' The maximum exhaust speed in knots [~1555].<br />
* '''spool-time:''' Time, in seconds, for the engine to respond to 90% of a commanded powersetting.<br />
<br />
==== Propeller ====<br />
A propeller. This element requires an engine subtag. Currently <piston-engine> and <turbine-engine> are supported.<br />
* '''x,y,z:''' The position of the mass (!) of the engine/propeller combination. If the point of force application is different (and it will be) it should be set with an <actionpt> subelement.<br />
* '''mass:''' The mass of the engine/propeller, in pounds.<br />
* '''moment:''' The moment, in kg-metres^2. This has to be hand calculated and guessed at for now. A more automated system will be forthcoming. Use a negative moment value for counter-rotating ("European" -- CCW as seen from behind the prop) propellers. A good guess for this value is the radius of the prop (in meters) squared times the mass (kg) divided by three; that is the moment of a plain "stick" bolted to the prop shaft.<br />
* '''radius:''' The radius, in meters, or the propeller.<br />
* '''cruise-speed:''' The max efficiency cruise speed of the propeller. Generally not the same as the aircraft's cruise speed.<br />
* '''cruise-rpm:''' The RPM of the propeller at max-eff. cruise.<br />
* '''cruise-power:''' The power sunk by the prop at cruise, in horsepower.<br />
* '''cruise-alt:''' The reference cruise altitude in feet.<br />
* '''takeoff-power:''' The takeoff power required by the propeller...<br />
* '''takeoff-rpm:''' ...at the given takeoff RPM.<br />
* '''gear-ratio:''' The factor by which the engine RPM is multiplied to produce the propeller RPM. Optional (defaults to 1.0).<br />
* '''contra:''' When set (contra="1"), this indicates that the propeller is a contra-rotating pair. It will not contribute to the aircraft's net gyroscopic moment, nor will it produce asymmetric torque on the aircraft body. Asymmetric slipstream effects, when implemented, will also be zero when this is set.<br />
<br />
<br />
YASim assumes a fixed-pitch propeller by default. If your engine is using a constant-speed propeller, you'll also need to provide these attributes:<br />
<br />
* '''min-rpm:''' The minimum operational RPM for a constant speed propeller. This is the speed to which the prop governor will seek when the blue lever is at a minimum. The coarse-stop attribute limits how far the governor can go into trying to reach this RPM.<br />
* '''max-rpm:''' The maximum operational RPM for a constant speed propeller. See above. The fine-stop attribute limits how far the governor can go in trying to reach this RPM.<br />
* '''fine-stop:''' The minimum pitch of the propeller (high RPM) as a ratio of ideal cruise pitch. This is set to 0.25 by default -- a higher value will result in a lower RPM at low power settings (e.g. idle, taxi, and approach).<br />
* '''coarse-stop:''' The maximum pitch of the propeller (low RPM) as a ratio of ideal cruise pitch. This is set to 4.0 by default -- a lower value may result in a higher RPM at high power settings.<br />
<br />
<br />
===== piston-engine =====<br />
<br />
A piston engine definition. This must be a subelement of an enclosing <propeller> tag.<br />
<br />
* '''eng-power:''' Maximum BHP of the engine at sea level.<br />
* '''eng-rpm:''' The engine RPM at which eng-power is developed<br />
* '''displacement:''' The engine displacement in cubic inches.<br />
* '''compression:''' The engine compression ratio.<br />
<br />
<syntaxhighlight lang="xml" line><br />
<piston-engine eng-power="2" eng-rpm="3800" displacement="20" ><br />
<control-input axis="/controls/engines/engine[0]/throttle" control="THROTTLE"/><br />
<control-input axis="/controls/engines/engine[0]/starter" control="STARTER"/><br />
<control-input axis="/controls/engines/engine[0]/magnetos" control="MAGNETOS"/><br />
<control-input axis="/controls/engines/engine[0]/mixture" control="MIXTURE"/><br />
</piston-engine><br />
</syntaxhighlight><br />
<br />
===== electric-engine =====<br />
<br />
A simplified electric DC engine model. The model is available since the end of April 2020, therefore it is currently available in daily build FlightGear snapshots. This definition must be a subelement of an enclosing <propeller> tag.<br />
<br />
* '''Kv''' electric engine constant in revolutions per minute to volt. <br />
* '''voltage''' The voltage applied to the motor e.g. Nominal battery voltage in Volts. <br />
* '''Rm''' The engine winding resistance in Ohms.<br />
<br />
<br />
Example:<br />
<br />
<syntaxhighlight lang="xml" line><br />
<propeller x="0.02" y="0" z="0.03"<br />
mass="0.05"<br />
moment="0.0006"<br />
radius="0.203"<br />
cruise-speed="26"<br />
cruise-rpm="7000"<br />
cruise-power="0.5"<br />
cruise-alt="2000"<br />
takeoff-power="0.70"<br />
takeoff-rpm="9200"<br />
contra="1"><br />
<actionpt x="0" y="0" z="0.03"/><br />
<electric-engine Kv="750" voltage="15" Rm="0.02" ><br />
<control-input axis="/controls/engines/engine[0]/throttle" control="THROTTLE"/><br />
</electric-engine><br />
</propeller><br />
</syntaxhighlight><br />
<br />
=== Landing gear ===<br />
==== gear ====<br />
Defines a landing gear. Accepts <control> subelements to map properties to steering and braking. Can also be used to simulate floats. Although the coefficients are still called ..fric, it is calculated in fluids as a drag (proportional to the square of the speed). In fluids gears are not considered to detect crashes (as on ground). <br />
* '''x,y,z:''' The location of the fully-extended gear tip.<br />
* '''compression:''' The distance in metres along the "up" axis that the gear will compress.<br />
* '''initial-load:''' The initial load of the spring in multiples of compression. Defaults to 0. (With this parameter a lower spring-constants will be used for the gear-> can reduce numerical problems (jitter)) '''Note:''' the spring-constant is varied from 0% compression to 20% compression to get continuous behavior around 0 compression. (could be physically explained by wheel deformation)<br />
* '''upx/upy/upz:''' The direction of compression, defaults to vertical (0,0,1) if unspecified. These are used only for a direction -- the vector need not be normalized, as the length is specified by "compression".<br />
* '''sfric:''' Static (non-skidding) coefficient of friction. Defaults to 0.8.<br />
* '''dfric:''' Dynamic friction. Defaults to 0.7.<br />
* '''stiction:''' Stiction to ground. Defaults to 0. stiction = "1" ensures the gear isn't sliding unintentionally (Note: please correct docu here for more detailed facts, developers didn't document this extension here and this is based on trial and guessing only)<br />
* '''spring:''' A dimensionless multiplier for the automatically generated spring constant. Increase to make the gear stiffer, decrease to make it squishier.<br />
* '''damp:''' A dimensionless multiplier for the automatically generated damping coefficient. Decrease to make the gear "bouncier", increase to make it "slower". Beware of increasing this too far: very high damping forces can make the numerics unstable. If you can't make the gear stop bouncing with this number, try increasing the compression length instead.<br />
* '''on-water:''' if this is set to "0" the gear will be ignored if on water. Defaults to "0"<br />
* '''on-solid:''' if this set to "0" the gear will be ignored if not on water. Defaults to "1"<br />
* '''speed-planing:'''<br />
* '''spring-factor-not-planing:''' At zero speed the spring factor is multiplied by spring-factor-not-planing. Above speed-planing this factor is equal to 1. The idea is, to use this for floats simulating the transition from swimming to planing. speed-planing defaults to 0, spring-factor-not-planing defaults to 1.<br />
* '''reduce-friction-by-extension:''' at full extension the friction is reduced by this relative value. 0.7 means 30% friction at full extension. If you specify a value greater than one, the friction will be zero before reaching full extension. Defaults to "0"<br />
* '''ignored-by-solver:''' with the on-water/on-solid tags you can have more than one set of gears in one aircraft, If the solver (who automatically generates the spring constants) would take all gears into account, the result would be wrong. E. G. set this tag to "1" for all gears, which are not active on runways. Defaults to "0". You can not exclude all gears in the solving process.<br />
<br />
Will define two properties associated with compression of landing gear:<br />
<br />
* '''compression-norm''' - range from 0..1, 0 means gear fully extended, 1 means fully compressed.<br />
* '''compression-m''' - vertical distance in metres that the wheel has moved in order to be on top of ground; this will usually be different from the animation distance.<br />
<br />
<syntaxhighlight lang="xml" line><br />
<!-- front gear --><br />
<br />
<gear x="0.0" y="0.0" z="-0.205"<br />
spring="0.9"<br />
damp="0.8"<br />
dfric="0.9"<br />
sfric="1.1"<br />
compression="0.051"><br />
<control-input axis="/controls/flight/rudder" control="STEER" square="true" src0="-1.0" src1="1.0" dst0="-0.3" dst1="0.3"/><br />
<control-input axis="/controls/gear/brake-right" control="BRAKE" split="true"/><br />
<control-input axis="/controls/gear/brake-parking" control="BRAKE" split="true"/><br />
</gear><br />
<br />
<!-- two rear gears --><br />
<br />
<gear x="-0.4" y="0.25" z="-0.205"<br />
spring="0.9"<br />
damp="0.8"<br />
dfric="0.9"<br />
sfric="1.1"<br />
compression="0.051"><br />
<control-input axis="/controls/gear/brake-right" control="BRAKE" split="true"/><br />
<control-input axis="/controls/gear/brake-parking" control="BRAKE" split="true"/><br />
</gear><br />
<br />
<gear x="-0.4" y="-0.25" z="-0.205"<br />
spring="0.9"<br />
damp="0.8"<br />
dfric="0.9"<br />
sfric="1.1"<br />
compression="0.051"><br />
<control-input axis="/controls/gear/brake-left" control="BRAKE" split="true"/><br />
<control-input axis="/controls/gear/brake-parking" control="BRAKE" split="true"/><br />
</gear><br />
</syntaxhighlight><br />
<br />
===== Torus-shaped contact surface on next =====<br />
<br />
On next as of 2022-3-19 one can specify a torus-shaped tyre contact surface using these new parameters:<br />
<br />
* '''wheel-radius''' (default 0)<br />
* '''tyre-radius''' (default 0)<br />
* '''wheel-axle-x'''<br />
* '''wheel-axle-y'''<br />
* '''wheel-axle-z'''<br />
<br />
The contact point will be the lowest point on a torus with radius '''tyre-radius''' wrapped around a wheel with radius '''wheel-radius''' centred on point '''(x, y, z)''' with orientation defined by '''wheel-axle'''. This contact point will depend on the aircraft's orientation relative to the ground.<br />
<br />
If not specified, '''wheel-axle''' defaults to (0, 1, 0), giving a conventional vertical wheel in line with the aircraft. Other values may allow modelling of, for example, a Bf109's non-vertical undercarriage.<br />
<br />
Default values of zero for wheel-radius and tyre-radius give a fixed contact point at (x, y, z) as before.<br />
<br />
==== Launchbar ====<br />
Defines a catapult launchbar or strop.<br />
* '''x,y,z:''' The location of the mount point of the launch bar or strop on the aircraft.<br />
* '''length:''' The length of the launch bar from mount point to tip<br />
* '''down-angle:''' The max angle below the horizontal the launchbar can achieve.<br />
* '''up-angle:''' The max angle above the horizontal the launchbar can achieve.<br />
* '''holdback-{x,y,z}:''' The location of the holdback mount point on the aircraft.<br />
* '''holdback-length:''' The length of the holdback from mount point to tip. Note: holdback up-angle and down-angle are the same as those defined for the launchbar and are not specified in the configuration.<br />
<br />
=== Fuel ===<br />
==== tank ====<br />
A fuel tank. Tanks in the aircraft are identified numerically (starting from zero), in the order they are defined in the file. If the left tank is first, "tank[0]" will be the left tank. <br />
* '''x,y,z:''' The location of the tank.<br />
* '''capacity:''' The maximum contents of the tank, in pounds. Not gallons -- YASim supports fuels of varying densities.<br />
* '''jet:''' A boolean. If present, this causes the fuel density to be treated as Jet-A. Otherwise, gasoline density is used. A more elaborate density setting (in pounds per gallon, for example) would be easy to implement. Bug me.<br />
<br />
=== Center of Gravity ===<br />
==== Ballast ====<br />
This is a mechanism for modifying the mass distribution of the aircraft. A ballast setting specifies that a particular amount of the empty weight of the aircraft must be placed at a given location. The remaining non-ballast weight will be distributed "intelligently" across the fuselage and wing objects. Note again: this does NOT change the empty weight of the aircraft. <br />
* '''x,y,z:''' The location of the ballast.<br />
* '''mass:''' How much mass, in pounds, to put there. Note that this value can be negative. I find that I often need to "lighten" the tail of the aircraft.<br />
<br />
<br />
<syntaxhighlight lang="xml" line><br />
<ballast x="-0.24" y="0.0" z="0.33" mass-kg="0.5"/><br />
</syntaxhighlight><br />
<br />
==== Weight ====<br />
This is an added weight, something not part of the empty weight of the aircraft, like passengers, cargo, or external stores. The actual value of the mass is not specified here, instead, a mapping to a property is used. This allows external code, such as the panel, to control the weight (loading a given cargo configuration from preference files, dropping bombs at runtime, etc...)<br />
* '''x,y,z:''' The location of the weight.<br />
* '''mass-prop:''' The name of the fgfs property containing the mass, in pounds, of this weight.<br />
* '''size:''' The aerodynamic "size", in metres, of the object. This is important for external stores, which will cause drag. For reasonably aerodynamic stuff like bombs, the size should be roughly the width of the object. For other stuff, you're on your own. The default is zero, which results in no aerodynamic force (internal cargo).<br />
* '''solve-weight:''' Subtag of approach and cruise parameters. Used to specify a non-zero setting for a <weight> tag during solution. The default is to assume all weights are zero at the given performance numbers.<br />
* '''idx:''' Index of the weight in the file (starting with zero).<br />
* '''weight:''' Weight setting in pounds.<br />
<br />
<syntaxhighlight lang="xml" line><br />
<weight x="-0.06471" y="0.225" z="-0.2" mass-prop="/sim/weight[0]/weight-kg"/><br />
</syntaxhighlight><br />
<br />
=== Controls ===<br />
==== control-input ====<br />
This element manages a mapping from fgfs properties (user input) to settable values on the aircraft's objects. Note that the value to be set MUST (!) be valid on the given object type. This is not checked for by the parser, and will cause a runtime crash if you try it. Wing's don't have throttle controls, etc... Note that multiple axes may be set on the same value. They are summed before setting.<br />
* '''axis:''' The name of the double-valued fgfs property "axis" to use as input, such as "/controls/flight/aileron".<br />
* '''control:''' Which control axis to set on the objects. It can have the following values:<br />
** THROTTLE - The throttle on a jet or propeller. <br />
** MIXTURE - The mixture on a propeller.<br />
** REHEAT - The afterburner on a jet<br />
** PROP - The propeller advance<br />
** BRAKE - The brake on a gear.<br />
** STEER - The steering angle on a gear. <br />
** INCIDENCE - The incidence angle of a wing.<br />
** FLAP0 - The flap0 deflection of a wing. <br />
** FLAP1 - The flap1 deflection of a wing. <br />
** SLAT - The slat extension of a wing. <br />
** SPOILER - The spoiler extension for a wing. <br />
** CYCLICAIL - The "aileron" cyclic input of a rotor <br />
** CYCLICELE - The "elevator" cyclic input of a rotor <br />
** COLLECTIVE - The collective input of a rotor<br />
** ROTORENGINEON - If not equal zero the rotor is rotating <br />
** WINCHRELSPEED - The relative winch speed <br />
** {... and many more, see [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/FDM/YASim/ControlMap.cpp#l25 ControlMap.cpp] ...}<br />
* '''invert:''' Negate the value of the property before settling on the object.<br />
* '''split:''' Applicable to wing control surfaces. Sets the normal value on the left-wing, and a negated value on the right-wing.<br />
* '''square:''' Squares the value before setting. Useful for controls like a steering that needs a wide range, yet lots of sensitivity in the center. Obviously only applicable to values that have a range of [-1:1] or [0:1]. <br />
* '''src0/src1/dst0/dst1:''' If present, these define a linear mapping from the source to the output value. Input values in the range src0-src1 are mapped linearly to dst0-dst1, with clamping for input values that lie outside the range.<br />
<br />
==== control-output ====<br />
This can be used to pass the value of a YASim control axis (after all mapping and summing is applied) back to the property tree.<br />
* '''control:''' Name of the control axis. See above.<br />
* '''prop:''' Property node to receive the value.<br />
* '''side:''' Optional, for split controls. Either "right" or "left" <br />
* '''min/max:''' Clamping applied to output value.<br />
<br />
==== control-speed ====<br />
Some controls (most notably flaps and hydraulics) have maximum slew rates and cannot respond instantly to pilot input. This can be implemented with a control-speed tag, which defines a "transition time" required to slew through the full input range. Note that this tag is semi-deprecated, complicated control input filtering can be done much more robustly from a Nasal script.<br />
* '''control:''' Name of the control axis. See above.<br />
* '''transition-time:''' Time in seconds to slew through input range.<br />
<br />
==== control-setting ====<br />
This tag is used to define a particular setting for a control axis inside the <cruise> or <approach> tags, where obviously property input is not available. It can be used, for example, to inform the solver that the approach performance values assume full flaps, etc...<br />
* '''axis:''' Name of the control input (i.e. a property name)<br />
* '''value:''' Value of the control axis.<br />
<br />
=== Winch and Aerotow ===<br />
==== hitch ====<br />
A hitch, can be used for winch-start (in gliders) or aerotow (in gliders and motor aircraft) or for external cargo with helicopter. You can do aerotow over the net via multiplayer (see j3 and bocian as an example).<br />
* '''name:''' the name of the hitch. must be aerotow if you want to do aerotow via multiplayer. You will find many properties at /sim/hitches/name. Most of them are directly tied to the internal variables, you can modify them as you like. You can add a listener to the property "broken", e. g. for playing a sound.<br />
* '''x,y,z:''' The position of the hitch<br />
* '''force-is-calculated-by-other:''' if you want to simulate aerotowing over the internet, set this value to "1" in the motor aircraft. Don't specify or set this to zero in gliders. In a LAN the time lag might be small enough to set it on both aircraft to "0". It's intended, that this is done automatically in the future.<br />
==== tow ====<br />
The tow used for aerotow or winch. This must be a subelement of an enclosing <hitch> tag.<br />
* '''length:''' upstretched length in metres<br />
* '''weight-per-meter:''' in kg/metre<br />
* '''elastic-constant:''' lower values give higher elasticity<br />
* '''break-force:''' in N<br />
* '''mp-auto-connect-period:''' the every x seconds a towed multiplayer aircraft is searched. If found, this tow is connected automatically, parameters are copied from the other aircraft. Should be set only in the motor aircraft, not in the glider<br />
==== winch ====<br />
The tow used for aerotow or winch. This must be a subelement of an enclosing <hitch> tag.<br />
* '''max-tow-length:''' in m<br />
* '''min-tow-length''': in m<br />
* '''initial-tow-length:''' in m. The initial tow length also defines the length/search radius used for the mp-autoconnect feature<br />
* '''max-winch-speed:''' in m/s<br />
* '''power:''' in kW<br />
* '''max-force:''' in N<br />
<br />
<br />
<syntaxhighlight lang="xml" line><br />
<hitch name="winch" x="0.0" y="0.0" z="0.0"><br />
<tow length="50" weight-per-meter="0.0035" elastic-constant="40000" break-force="10000"/><br />
<!-- 3mm paracord--><br />
<winch max-tow-length="1000" min-tow-length="1" initial-tow-length="1000" max-winch-speed="20" power="2" max-force="80"/><br />
<control-input axis="/controls/winch/place" control="PLACEWINCH"/><br />
</hitch><br />
<hitch name="aerotow" x="0.0" y="0.0" z="0.0" force-is-calculated-by-other="0"><br />
<tow length="60" weight-per-meter="0.0035" elastic-constant="9000" break-force="100" mp-auto-connect-period="0.0"/><br />
<winch max-tow-length="1000" min-tow-length="60" initial-tow-length="60"/><br />
<control-input axis="/controls/aerotow/find-aircraft" control="FINDAITOW"/><br />
</hitch><br />
</syntaxhighlight><br />
<br />
== Visualization ==<br />
<br />
=== Blender visualization tool ===<br />
<br />
[[File:Yasim_visualisation_dc6.png|thumb|dc6 FDM in Blender]]To make the programmed aircraft visible it is possible to load and compare it with the 3D model within [[Blender]]. They applaud for this ''very'' useful script goes to M. Franz, thank you very much!<br />
<br />
For Blender versions <= 2.4 the script is located in FlightGears source code {{flightgear file|utils/Modeller/yasim_import.py}}.<br />
<br />
For Blender versions newer than 2.4, please see [[Blender YASim import]].<br />
<br />
The howto, taken from inside the script:<br />
<br />
yasim_import.py loads and visualizes a YASim FDM geometry<br />
=========================================================<br />
<br />
It is recommended to load the model superimposed over a greyed out and immutable copy of the aircraft model:<br />
<br />
(0) put this script into ~/.blender/scripts/<br />
(1) load or import aircraft model (menu -> "File" -> "Import" -> "AC3D (.ac) ...")<br />
(2) create new *empty* scene (menu -> arrow button left of "SCE:scene1" combobox -> "ADD NEW" -> "empty")<br />
(3) rename scene to yasim (not required)<br />
(4) link to scene1 (F10 -> "Output" tab -> arrow button left of text entry "No Set Scene" -> "scene1")<br />
(5) now load the YASim config file (menu -> "File" -> "Import" -> "YASim (.xml) ...")<br />
<br />
This is good enough for simple checks. But if you are working on the YASim configuration, then you need a<br />
quick and convenient way to reload the file. In that case, continue after (4):<br />
<br />
(5) switch the button area at the bottom of the blender screen to "Scripts Window" mode (green python snake icon)<br />
(6) load the YASim config file (menu -> "Scripts" -> "Import" -> "YASim (.xml) ...")<br />
(7) make the "Scripts Window" area as small as possible by dragging the area separator down<br />
(8) optionally split the "3D View" area and switch the right part to the "Outliner"<br />
(9) press the "Reload YASim" button in the script area to reload the file<br />
<br />
<br />
If the 3D model is displaced with respect to the FDM model, then the <offsets> values from the<br />
model animation XML file should be added as comment to the YASim config file, as a line all by<br />
itself, with no spaces surrounding the equal signs. Spaces elsewhere are allowed. For example:<br />
<br />
<offsets><br />
<x-m>3.45</x-m><br />
<z-m>-0.4</z-m><br />
<pitch-deg>5</pitch-deg><br />
</offsets><br />
<br />
becomes:<br />
<br />
<!-- offsets: x=3.45 z=-0.4 p=5 --><br />
<br />
Possible variables are:<br />
<br />
x ... <x-m><br />
y ... <y-m><br />
z ... <z-m><br />
h ... <heading-deg><br />
p ... <pitch-deg><br />
r ... <roll-deg><br />
<br />
Of course, absolute FDM coordinates can then no longer directly be read from Blender's 3D view.<br />
The cursor coordinates display in the script area, however, shows the coordinates in YASim space.<br />
Note that object names don't contain XML indices but element numbers. YASim_hstab#2 is the third<br />
hstab in the whole file, not necessarily in its parent XML group. A floating-point part in the<br />
object name (e.g. YASim_hstab#2.004) only means that the geometry has been reloaded that often.<br />
It's an unavoidable consequence of how Blender deals with meshes.<br />
<br />
<br />
Elements are displayed as follows:<br />
<br />
cockpit -> monkey head<br />
fuselage -> blue "tube" (with only 12 sides for less clutter); center at "a"<br />
vstab -> red with yellow flaps<br />
wing/mstab/hstab -> green with yellow flaps/spoilers/slats (always 20 cm deep);<br />
symmetric surfaces are only displayed on the left side<br />
thrusters (jet/propeller/thruster) -> dashed line from center to actionpt;<br />
arrow from actionpt along thrust vector (always 1 m long);<br />
propeller circle<br />
rotor -> radius and rel_len_blade_start circle, direction arrow,<br />
normal and forward vector, one blade at phi0<br />
gear -> contact point and compression vector (no arrow head)<br />
tank -> cube (10 cm side length)<br />
weight -> inverted cone<br />
ballast -> cylinder<br />
hitch -> circle (10 cm diameter)<br />
hook -> dashed line for up angle, T-line for down angle<br />
launchbar -> dashed line for up angles, T-line for down angles<br />
A note about step (0) for Windows users: the mentioned path is inside the folder where Blender lives, something like <code>C:\Program Files\Blender Foundation\Blender\.blender\scripts</code>.<br />
<br />
=== Visualize model in OpenSCAD or FreeCAD ===<br />
<br />
There exist a possibility to display the YASim XML elements in the OpenSCAD or FreeCAD tools. This could be extremely useful in the case of UAV aircraft development. <br />
<br />
* [https://github.com/ThunderFly-aerospace/YASim2SCAD YASim2SCAD] - This tool converts YASim XML to scad file which could be displayed as an overlay in OpenSCAD or FreeCAD project.<br />
* [https://gitlab.com/yasimtoscad/yasimtoscad yasimtoscad] - Another tool to convert YASim XML to scad file which could be displayed as an overlay in OpenSCAD.<br />
<br />
<br />
=== Visualization tools ===<br />
<br />
* [https://github.com/bitwisetech/ysimi YSIMI] Interactive Tuning Tools for FlightGear's YASIM Flight Dynamics Model<br />
* [https://github.com/bitwisetech/yasiVers yasiVers] is a tool for visualization of YASim calculations.<br />
<br />
== Export of YASim internals to property tree ==<br />
Ever wondered what is going on inside yasim? See the property tree under /fdm/yasim/<br />
<br />
Some information is static and shows what yasim has compiled from your XML. <br />
Other information is "run-time" like forces, speed, acceleration, c.g. <br />
<br />
If note noted otherwise:<br />
* expect metric unit (meter, kilogram, newton, ...)<br />
* expect minimum version 2017.2<br />
<br />
{| class="wikitable"<br />
|-<br />
! Path !! Description !! Information type !! min. version<br />
|-<br />
| accelerations/ || linear and rot. accelerations in aircraft coord. || run time ||<br />
|-<br />
| debug/ || misc internals, for now subject to change without notice || run time || 2018.1<br />
|-<br />
| forces/ || aerodynamic forces in N || run time ||<br />
|-<br />
| velocities/ || linear and rot. velocities in aircraft coord. || run time ||<br />
|-<br />
| model/cg-x-range-aft || desired CG range || compile time ||<br />
|-<br />
| model/cg-x-range-front || desired CG range || compile time ||<br />
|-<br />
| model/cg-x-max || CG hard limit from gear position || compile time ||<br />
|-<br />
| model/cg-x-min || CG hard limit from gear position || compile time ||<br />
|-<br />
| model/masses || shows the calculated mass points || compile time ||<br />
|-<br />
| model/wings || wing parameters || compile time ||<br />
|}<br />
<br />
<br />
== Command Line ==<br />
=== Windows ===<br />
By using the standard command line, we can see what the YASim solver is calculating. First, open up Command Prompt, enter in the location of yasim.exe, and then the location of the YASim XML file. For example, here's what you would type in for a standard Windows [[Changelog_2.12|FlightGear 2.12.0]] installation, and viewing the [[F-14_Tomcat|F-14B's]] YASim file.<br />
{{Note|You can copy & paste the examples into Command Prompt by right-clicking on the title and navigate to Edit > Paste. Then, click Enter to execute.}} <br />
<br />
<code>"C:\Program Files\FlightGear\bin\Win32\yasim.exe" "C:\Program Files\FlightGear\data\Aircraft\f-14b\f-14b-yasim.xml"</code><br />
<br />
The results will give many different values.<br />
<br />
* '''Drag Coefficient:''' The drag coefficient of the aircraft.<br />
* '''Lift Ratio:''' The lift ratio of the aircraft.<br />
* '''Cruise AoA:''' The cruise AoA, from conditions at [[YASim#cruise|<cruise>]] in the xml file.<br />
* '''Tail Incidence:''' The incidence angle of the tail, "solved" by YASim as a way to stabilize the aircraft.<br />
* '''Approach Elevator:''' The approach elevator, from conditions at [[YASim#approach|<approach>]] in the xml file.<br />
* '''CG:''' Center of gravity of the aircraft in coordinates. Unless it's supposed to be offset, it should always have a Y value of 0.<br />
<br />
The YASim standalone solver also has some command line flags that change it's behaviour.<br />
<br />
<code>"C:\Program Files\FlightGear\bin\Win32\yasim.exe" "C:\Program Files\FlightGear\data\Aircraft\f-14b\f-14b-yasim.xml" -g -a 1000 -s 490</code><br />
<br />
* '''-g:''' Instructs YASim to generate space-separated tabular data instead of the usual solver output. This can be redirected to a file and used in various plotting programs to visualize the actual lift, drag, L/D curves. The columns of the output from left to right are: AoA, Lift, Drag, L/D. (aoa in degrees, lift and drag in G's).<br />
* '''-a <altitude in meter:>''' Run the solver at the given altitude in meter.<br />
* '''-s <speed in knots>:''' Also run at the given airspeed in knots.<br />
<br />
{{Note|The values generated by this method are for the aircraft taken as a whole, as solved by YASim, so they differ from the values of the wing airfoil.}}<br />
<br />
To get the tabular output for the example above at 1000 m and 150 knots, and to redirect this to a file, one would issue:<br />
<br />
<code>"C:\Program Files\FlightGear\bin\Win32\yasim.exe" "C:\Program Files\FlightGear\data\Aircraft\f-14b\f-14b-yasim.xml" -g -a 1000 -s 150 > "C:\Program Files\FlightGear\yasim.txt"</code><br />
<br />
== New features and bugfixes in version 2017.2 ==<br />
<br />
=== XML parser ===<br />
==== support for metric and imperial units ====<br />
To make life easier for aircraft developers, the parser supports new additional attributes with a unit suffix, e.g. speed-kt for knots and speed-kmh for kilometers per hour.<br />
* <code><airplane {mass, mass-lbs, mass-kg}="12345" ></code><br />
* <code><approach {speed, speed-kt, speed-kmh}="123" ></code><br />
* <code><cruise {speed, speed-kt, speed-kmh}="123" ></code><br />
* <code><solve-weight {weight, weight-lbs, weight-kg}="123" ></code><br />
* <code><jet {mass, mass-lbs, mass-kg}="1234" ></code><br />
* <code><tank {capacity, capacity-lbs, capacity-kg}="12345" ></code><br />
* <code><ballast {mass, mass-lbs, mass-kg}="1234" ></code><br />
<br />
{{Note|Aircraft using this new attributes will not run on older versions of FlightGear, so it is probably wise to publish those only after a reasonable number of users switched version 2017.2 or newer.}}<br />
<br />
==== CG tuning help ====<br />
{{Note| The feature described in this section is not fully implemented yet, however, it may be of some help already.<br />
It is currently implemented for the yasim CLI tool only. It does not affect the airplane behaviour while running FlightGear. }}<br />
<br />
New attributes have been added to <airplane> to assist tuning the center of gravity (CG).<br />
The CG position is often expressed relative to the [https://en.wikipedia.org/wiki/Chord_(aeronautics)#Mean_aerodynamic_chord MAC] of the wing in percent. You can specify a desired range for CG in % relative to MAC, it will show up in the output of the yasim CLI tool (see example below):<br />
<br />
* cg-min: default 25% (just a guess, better numbers are welcome)<br />
* cg-max: default 30% (just a guess, better numbers are welcome)<br />
<br />
{{Note| By convention 0% is leading edge, 100% is trailing edge, however the absolute values on x-axis are the other way round, e.g. nose is +x, tail is -x }}<br />
{{warning|The MAC calculation in version 2017.2 works only on the <wing> element. Numbers will be wrong, if your model uses a combination of <wing> and <mstab> to build a wing with two or more sections.<br />
Section support will be added in version 2018.1}}<br />
YASim will print the leading edge coordinates of the MAC (x,y) and its length.<br />
<br />
'''Example output'''<br />
<pre><br />
$ yasim Citation-II-yasim.xml <br />
This aircraft uses yasim version '2017.2' <br />
========================== <br />
= YASim solution results = <br />
========================== <br />
Iterations: 2210 <br />
Drag Coefficient: 12.304669 <br />
Lift Ratio: 85.317558 <br />
Cruise AoA: 4.016746 deg <br />
Tail Incidence: -3.053278 deg <br />
Approach Elevator: -0.377542 <br />
<br />
CG: x:-6.543, y:-0.000, z:0.044 <br />
Wing MAC (*1): x:-6.00, y:3.83, length:2.0 <br />
CG-x rel. MAC: 0.272 <br />
CG-x desired: -6.599 < -6.543 < -6.198 <br />
<br />
Inertia tensor [kg*m^2], origo at CG: <br />
<br />
18009.289, -0.000, 7120.470 <br />
-0.000, 42459.316, 0.000 <br />
7120.470, 0.000, 56980.656 <br />
<br />
(*1) MAC calculation works on <wing> only! Numbers will be wrong for segmented wings, e.g. <wing>+<mstab>.<br />
</pre><br />
<br />
=== Aircraft developer helpers ===<br />
The command line utility got some new options. For some strange reason, the -a parameter expects altitude in meters instead of ft. This is now visible in the usage message but left unchanged for compatibility.<br />
<syntaxhighlight>Usage:<br />
yasim <aircraft.xml> [-g [-a meters] [-s kts] [-approach | -cruise] ]<br />
yasim <aircraft.xml> [-d [-a meters] [-approach | -cruise] ]<br />
yasim <aircraft.xml> [-m]<br />
-g print lift/drag table: aoa, lift, drag, lift/drag <br />
-d print drag over TAS: kts, drag<br />
-a set altitude in meters!<br />
-s set speed in knots<br />
-m print mass distribution table: id, x, y, z, mass</syntaxhighlight><br />
<br />
=== Bugfixes ===<br />
The following bugfixes require <airplane version="2017.2"> for backward compatibility <br />
* Ground effect: corrected the calculation of the height where g.e. ends<br />
* Stall parameters were set wrong for wings with camber=0<br />
<br />
== New features and bugfixes in version 2018.1 ==<br />
The following is under development and hopefully finds its way into FG version 2018.1<br />
<br />
=== Wing Section Support ===<br />
Many airliners have wings with a geometry that is just a little more complex than what YASim supported initially (tapered wing with some angles like sweep, dihedral, ...), e.g. they have an inboard section and an outboard section that can be described with YASim wing syntax. You can use a wing + a mstab XML element to describe this geometry but it is easier if YASim can just append more wing sections by simply adding more wing XML elements. This is now (Version 2018.1) possible, yasim will simply append sections if it finds more than one wing or hstab in the XML.<br />
You should use '''&lt;wing append="1" ... &gt;''' for all but the first wing/hstab declaration. <br />
{{Note|YASim will ignore the root point (x,y,z), the chord length and the incidence attributes, if you add "append" and calculate those from the previous wing section. }}<br />
MAC calculation works for the whole wing.<br />
<br />
{{warning|Aircrafts using this feature will not work with older versions of flightgear. }}<br />
To keep the aircraft backward compatible for a while, it is recommended to create a copy of its yasim XML file for development. <br />
Once you are happy with the CG and wing parameters you can use the output of the YASim CLI tool to modifiy the original XML. <br />
The tool will output the needed x,y,z etc per wing section to create a XML in old format with (only one) <wing> + <mstab>.<br />
<br />
=== More information from CLI tools ===<br />
You should configure the maximum take of weight (MTOW) in your XML file by adding either ''mtow-lbs'' or ''mtow-kg'' attribute to the airplane:<br />
<br />
<code> &lt;airplane mass="7500" version="2018.1" mtow-lbs="12500"&gt; </code><br />
<br />
'''Example output'''<br />
<pre><br />
yasim CRJ700.xml <br />
==========================<br />
= YASim solution results =<br />
==========================<br />
Iterations : 1024<br />
Drag Coefficient : 17.707<br />
Lift Ratio : 145.841<br />
Cruise AoA : -0.11 deg<br />
Tail Incidence : 3.47 deg<br />
Approach Elevator : -0.792<br />
<br />
CG : x:-0.046, y:0.000, z:-1.222<br />
Wing MAC : (x:0.79, y:4.99), length:3.4 <br />
hard limit CG-x : 14.232 m<br />
soft limit CG-x : -0.058 m<br />
CG-x : -0.046 m<br />
CG-x rel. MAC : 25%<br />
soft limit CG-x : -0.228 m<br />
hard limit CG-x : -0.986 m<br />
<br />
wing lever : -0.012 m<br />
tail lever : -13.997 m<br />
<br />
max thrust : 157.18 kN<br />
thrust/empty : 0.81<br />
thrust/mtow : 0.49<br />
<br />
wing span : 22.64 m<br />
sweep lead. edge : 30.2 .. 30.6 deg<br />
wing area : 58.70 m^2<br />
wing load empty : 336.15 kg/m^2 (Empty 19731 kg)<br />
wing load MTOW : 562.18 kg/m^2 (MTOW 32999 kg)<br />
<br />
tail span : 8.533 m<br />
tail area : 14.838 m^2<br />
<br />
#wing sections: 2<br />
Section 0 base point (0.450, 1.226, -2.034), chord 5.085, incidence at section root 5.0deg<br />
Section 1 base point (-0.663, 4.754, -1.942), chord 3.204, incidence at section root 3.0deg<br />
<br />
Inertia tensor [kg*m^2], origo at CG:<br />
<br />
195646, 0, 122265<br />
0, 1757279, 0<br />
122265, 0, 1904528<br />
</pre><br />
<br />
=== Variable tail incidence / elevator trim ===<br />
Small GA aircrafts usually trim with a trim tab on the elevator. For efficiency, airliners normally do not trim the elevator ("flap") <br />
but rotate the whole stabilizer (=tail) wing, e.g. they change the incidence for this wing. While this feature was somehow foreseen, <br />
it was not implemented yet, most likely because the "tail incidence" is one of the free variables used by the YASim solver. <br />
However, it is possible now to use the control="INCIDENCE" within the &lt;hstab&gt; to implement an alternative trim '''while maintaining full elevator authority'''.<br />
<pre><br />
<hstab ... incidence-min-deg="-13.0" incidence-max-deg="2.0"><br />
...<br />
<control-input axis="/controls/flight/hstab-trim" control="INCIDENCE" /><br />
<control-speed control="INCIDENCE" transition-time="20.0" /><br />
<control-output control="INCIDENCE" prop="/surface-positions/hstab-rad" /> <br />
</hstab><br />
</pre><br />
{{Note|The control output of INCIDENCE is the angle in radians, not in degree, as that is the unit internally used by YASim.}}<br />
{{warning|The OPTIONAL incidence-min-deg and incidence-max-deg set the limits for the solver. You must make sure to select a sufficiently large range or solver will fail. }}<br />
First experiments with this feature were successful in that the aircraft pitch could be changed as expected but fine tuning will be necessary.<br />
<br />
<br />
== Related content ==<br />
* [[Howto:Make a helicopter#XML Elements]] &ndash; Rotor and rotorgear YASim elements<br />
* [[Towing]]<br />
* [[YASim Development Tools]]<br />
<br />
== External links ==<br />
* {{cite web<br />
| url = http://www.buckarooshangar.com/flightgear/yasimtut.html<br />
| title = Guide to YASim<br />
| first = Gary R. "Buckaroo"<br />
| last = Neely<br />
| authorlink = http://www.buckarooshangar.com/flightgear/<br />
| date = 2013<br />
| accessdate = April 16, 2020<br />
}} - A very helpful guide<br />
* {{cite web<br />
| url = https://sourceforge.net/projects/dacpei/<br />
| title = DACPEI<br />
| author = pytoche<br />
| date = February 2012<br />
| publisher = SourceForge<br />
| accessdate = April 16, 2020<br />
}} - A fixed wing light aircraft WYSIWUG concept design suite that can export an YASim FDM to FlightGear.<br />
<br />
{{FDM}}<br />
<br />
[[Category:Flight Dynamics Model]]<br />
<br />
[[fr:YASim]]</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=YASim&diff=134798YASim2022-03-17T00:06:18Z<p>Cgdae: /* Landing gear */ describe compression-norm and compression-m properties.</p>
<hr />
<div>[[File:yasimlogo.png|thumb]] <br />
<br />
'''YASim''' is one of two [[flight dynamics model]]s commonly used in [[FlightGear]]. The flight dynamics model (FDM) determines how the [[aircraft]] moves and flies.<br />
<br />
Gary Neely wrote in his [http://www.buckarooshangar.com/flightgear/ introduction to YASim]:<br />
<br />
:''The FDM is the mathematical model that controls the physics of flight within the simulator. The physical 3D aircraft model has nothing to do with flight dynamics-- in essence it's just a picture to look at. It's the FDM that dictates how the model flies.''<br />
<br />
:''Why YASim? YASim uses the geometry of the aircraft to generate the base flight characteristics. While this suggests a 'realistic' or out-of-the-box approach, it is a only rough approximation that will require much tweaking before you get a result that approaches realism. If you have solid flight data for your aircraft such as wind-tunnel data or you are looking to eventually generate a hyper-realistic simulation, JSBSim is probably a better approach. If you lack such data but know the geometry of the aircraft and have access to the same flight characteristics and limits as a real pilot would, then YASim can provide a solution that is more than sufficient for most simulation needs.''<br />
<br />
== Coordinate system notes ==<br />
All positions specified are in metres (which is weird, since all other units in the file are English). The X axis points forward, Y is left, and Z is up. Take your right hand, and hold it like a gun. Your first and second fingers are the X and Y axes, and your upwards-pointing thumb is the Z. This is slightly different from the coordinate system used by [[JSBSim]]. Sorry. The origin can be placed anywhere, so long as you are consistent. I use the nose of the aircraft.<br />
<br />
(In the [[JSBSim_Aerodynamics#Frames|JSBSim coordinate system]], X and Z are the same as in YASim, but Y points to the right instead of left.)<br />
<br />
=== Checking alignment with Blender ===<br />
<br />
Blender can display a '''.ac''' model and a yasim model at the same time, allowing one to check whether the wings, gear contact points etc are aligned correctly. But it seems that Blender ignores any top-level <code>loc <x> <y> <z></code> specification in the '''.ac''' file, which makes it non-trivial to check alignment if such a specification is used.<br />
<br />
== YASim design notes ==<br />
Andy Ross's original design notes for YASim can be found in [https://pdfhost.io/v/~iYsLl7xS_alldvi.pdf this PDF file]. These provide some useful background for how YASim works.<br />
<br />
== XML Elements ==<br />
<!-- To future editors: The all lowercase headings are XML tags and should ''probably'' be left that way --><br />
=== airplane ===<br />
The top-level element for the file. It contains the following attributes: <br />
* '''mass:''' The empty (no fuel) weight, in pounds. It does include the weight of the engine(s), so when you add the engine weight in its tag, it acts just like a ballast.<br />
* '''version:''' The version attribute is used to maintain compatibility when updating yasim (e.g. bugfixes). If this attribute i not given, the original version will be used. Several bugfixes to YASim were implemented in FlightGear 3.2 (see [[FlightGear Newsletter April 2014]]), some more are fixed in FlightGear 2017.2. <br />
Available versions are:<br />
* <code>YASIM_VERSION_ORIGINAL</code> explicitly use the old buggy calculations (same as no version attribute at all)<br />
* <code>YASIM_VERSION_32</code> enable bugfixes up to version 3.2<br />
* <code>2017.2</code> enable bugfixes up to version 2017.2<br />
* <code>2018.1</code> (FIXME) no bugfixes by now. Use this version if your aircraft makes use of new features in YASim 2018.1 so it will cause at least a warning with older FG versions. <br />
* <code>YASIM_VERSION_CURRENT</code> use latest version compiled into the users FlightGear. <br />
{{Warning| Using YASIM_VERSION_CURRENT might make the aircraft unusable in case of future changes to YASim without updating the aircraft accordingly.}}<br />
<br />
'''New in 2018.1'''<br />
* '''mtow-lbs''' and '''mtow-kg:''' use one of them to specify max. takeoff weight. Does not affect the FDM, but is used by CLI tool to calculate some numbers.<br />
<br />
=== approach ===<br />
The approach parameters for the aircraft. The solver will generate an aircraft that matches these settings (by adjusting the parameters of the surface like drag and lift). It is extremely important to give parameters which could be really achieved by defined aircraft geometry, otherwise, it gives an unstable or not flyable result. The element can (and should) contain <control> elements indicating pilot input settings, such as flaps and throttle, for the approach.<br />
<br />
* '''speed:''' The approach airspeed, in knots TAS.<br />
* '''aoa:''' The approach angle of attack, in degrees<br />
* '''fuel:''' Fraction (0-1) of fuel in the tanks. Default is 0.2.<br />
<br />
=== cruise ===<br />
The cruise speed and altitude for the solver to match. As above, this should contain <control> elements indicating aircraft configuration. Especially, make sure the engines are generating enough thrust at cruise!<br />
* '''speed:''' The cruise speed, in knots TAS.<br />
* '''alt:''' The cruise altitude, in feet MSL.<br />
* '''fuel:''' Fraction (0-1) of fuel in the tanks. Default is 0.2.<br />
=== cockpit ===<br />
The location of the cockpit (pilot eyepoint).<br />
* '''x,y,z:''' eyepoint location (see coordinates note)<br />
<br />
=== fuselage ===<br />
This defines a tubelike structure. It will be given an even mass and aerodynamic force distribution by the solver. You can have as many as you like, in any orientation you please.<br />
* '''ax,ay,az:''' One end of the tube (typically the front)<br />
* '''bx,by,bz:''' The other ("back") end.<br />
* '''width:''' The width of the tube, in metres.<br />
* '''taper:''' The approximate radius at the "tips" of the fuselage expressed as a fraction (0-1) of the width value.<br />
* '''midpoint:''' The location of the widest part of the fuselage, expressed as a fraction of the distance between A and B.<br />
* '''idrag:''' Multiplier for the "induced drag" generated by this object. Default is one. With idrag=0 the fuselage generates only drag.<br />
* '''cx,cy,cz:''' Factors for the generated drag in the fuselages "local coordinate system" with x pointing from end to front, z perpendicular to x with y=0 in the aircraft coordinate system. E.g. for a fuselage of a height of 2 times the width you can define cy=2 and (due to the doubled front surface) cx=2.<br />
<br />
=== Surfaces ===<br />
==== wing ====<br />
This defines the main wing of the aircraft. You can have only one (but see below about using vstab objects for extra lifting surfaces). The wing should have a <stall> subelement to indicate stall behavior, control surface subelements (flap0, flap1, spoiler, slat) to indicate what and where the control surfaces are, and <control> subelements to map user input properties to the control surfaces.<br />
* '''x,y,z:''' The "base" of the wing, specified as the location of the mid-chord (not leading edge, trailing edge, or aerodynamic center) point at the root of the LEFT (!) wing.<br />
* '''length:''' The length from the midchord point of the base of the wing to the midchord point at the tip. Note that this is not the same thing as span.<br />
* '''chord:''' The chord of the wing at its base, along the X axis (not normal to the leading edge, as it is sometimes defined).<br />
* '''incidence:''' The incidence angle at the wing root, in degrees. Zero is level with the fuselage (as in an aerobatic plane), positive means that the leading edge is higher than the trailing edge (as in a trainer).<br />
* '''twist:''' The difference between the incidence angle at the wing root and the incidence angle at the wing tip. Typically, this is a negative number so that the wing tips have a lower angle of attack and stall after the wing root (washout).<br />
* '''taper:''' The taper fraction, expressed as the tip chord divided by the root chord. A taper of one is a hershey bar wing, and zero would be a wing ending at a point. Defaults to one.<br />
* '''sweep:''' The sweep angle of the wing, in degrees. Zero is no sweep, positive angles are swept back. Defaults to zero. [This looks to be the sweep of the mid-chord of the wing, not the sweep of the leading edge.]<br />
* '''dihedral:''' The dihedral angle of the wing. Positive angles are upward dihedral. Defaults to zero.<br />
* '''idrag:''' Multiplier for the "induced drag" generated by this surface. In general, low aspect wings will generate less induced drag per-AoA than high aspect (glider) wings. This value isn't constrained well by the solution process, and may require tuning to get throttle settings correct in high AoA (approach) situations.<br />
* '''effectiveness:''' Multiplier for the "normal" drag generated by the wing. Defaults to 1. Arbitrary, dimensionless factor. <br />
* '''camber:''' The lift produced by the wing at zero angle of attack, expressed as a fraction of the maximum lift produced at the stall AoA.<br />
* '''flow:''' The flow regime for the wing. Valid values are "SUBSONIC" (default) and "TRANSONIC". Setting surface to transonic adds more lift above mach number 0.6 by applying a Prandl/Glauert correction term to each surface-element. The effect is a more balanced lift/drag distribution reported by the solver. Use for anything that flies faster than mach 0.6 or has supercritical airfoils.<br />
* '''mcrit:''' The critical mach number for the wing. This point defines the begin of exponential drag rise due to mach speed. Default "0.6", only available if flow="TRANSONIC".<br />
<br />
'''Wing section support (since 2018.1):'''<br />
<br />
Wing section support to define variable geometry (geometry parameters per section)<br />
* More than one <wing>-element is allowed now. <br />
* x, y, z, chord and incidence attribute shall be specifed only for the first <wing> in the XML file. They will be overridden for subsequent <wing>-elements.<br />
* Use '''append="1"''' for additional '''wing''' elements to skip x, y, z, chord and incidence attribute as the will be calculated from previous '''wing''' element tip chord. This workaround is currently needed due to limitations in the XML parser.<br />
<br />
==== hstab ====<br />
These define the horizontal stabilizer of the aircraft. Internally, it is just a wing object and therefore works the same in XML. <br />
You are allowed only one hstab object; the solver needs to know which wing's incidence to play with to get the aircraft trimmed correctly.<br />
<br />
'''New in 2018.1:'''<br />
* '''hstab''' supports sections in the same way '''wing''' does, but it is still considered as /the/ (only) hstab used by the solver.<br />
* '''incidence-min-deg''' and '''incidence-max-deg''': optional attributes to limit valid result range fore the solver. Use with care or you won't get a solution.<br />
<br />
==== vstab ====<br />
A "vertical" stabilizer. Like hstab, this is just another wing, with a few special properties. The surface is not "mirrored" as are wing and hstab objects. If you define a left wing only, you'll only get a left wing. The default dihedral, if unspecified, is 90 degrees instead of zero. But all parameters are equally settable, so there's no requirement that this object be "vertical" at all. You can use it for anything you like, such as extra wings for biplanes. Most importantly, these surfaces are not involved with the solver computation, so you can have none, or as many as you like.<br />
<br />
==== mstab ====<br />
A mirrored horizontal stabilizer. Exactly the same as wing, but not involved with the solver computation, so you can have none, or as many as you like.<br />
<br />
==== stall ====<br />
A subelement of a wing (or hstab/vstab/mstab) that specifies the stall behavior.<br />
* '''aoa:''' The stall angle (maximum lift) in degrees. Note that this is relative to the wing, not the fuselage (since the wing may have a non-zero incidence angle).<br />
* '''width:''' The "width" of the stall, in degrees. A high value indicates a gentle stall. Low values are viscious for a non-twisted wing, but are acceptable for a twisted one (since the whole wing will not stall at the same time).<br />
* '''peak:''' The height of the lift peak, relative to the post-stall secondary lift peak at 45 degrees. Defaults to 1.5. This one is deep voodoo, and probably doesn't need to change much. Bug me for an explanation if you're curious.<br />
<br />
==== flap0, flap1, slat, spoiler ====<br />
These are subelements of wing/hstab/vstab objects, and specify the location and effectiveness of the control surfaces.<br />
* '''start:''' The position along the wing where the control surface begins.Zero is the root, one is the tip.<br />
* '''end:''' The position where the surface ends, as above.<br />
* '''lift:''' The lift multiplier for a flap or slat at full extension. One is a no-op, a typical aileron might be 1.2 or so, a giant jetliner flap 2.0, and a spoiler 0.0. For spoilers, the interpretation is a little different -- they spoil only "prestall" lift. Lift due purely to "flat plate" effects isn't affected. For typical wings that stall at low AoA's essentially all lift is pre-stall and you don't have to care. Jet fighters tend not to have wing spoilers, for exactly this reason. This value is not applicable to slats, which affect stall AoA only.<br />
* '''drag:''' The drag multiplier, as above. Typically should be higher than the lift multiplier for flaps.<br />
* '''aoa:''' Applicable only to slats. This indicates the angle by which the stall AoA is translated by the slat extension.<br />
<br />
=== Rotor and rotorgear ===<br />
YASim has also possibility to simulate rotorcraft blades. The number properties of rotor elements are large therefore are spitted to the separate page [[Howto:Make a helicopter#XML%20Elements|howto make a helicopter in YASim]].<br />
<br />
=== Engine ===<br />
==== Thruster ====<br />
A very simple "thrust only" engine object. Useful for things like thrust vectoring nozzles. All it does is map its THROTTLE input axis to its output thrust rating. Does not consume fuel, etc...<br />
* '''thrust:''' Maximum thrust in pounds<br />
* '''x,y,z:''' The point on the airframe where thrust will be applied.<br />
* '''vx,vy,vy:''' The direction of the thrust in airframe coordinates. The vector will be normalized automatically, so any non-zero vector will work fine.<br />
<br />
Example: <br />
<br />
<syntaxhighlight lang="xml" line><br />
<thruster x="0" y="0" z="0.03" vx="1" vy="0" vz="0" thrust="6.61"><br />
<control-input axis="/controls/engines/engine[0]/throttle" control="THROTTLE" src0="-1" src1="1" dst0="-1" dst1="1"/><br />
</thruster><br />
</syntaxhighlight><br />
<br />
==== Jet ====<br />
A turbojet/fan engine. It accepts a <control> subelement to map a property to its throttle setting, and an <actionpt> subelement to place the action point of the thrust at a different position than the mass of the engine.<br />
* '''x,y,z:''' The location of the engine, as a point mass. If no actionpt is specified, this will also be the point of application of thrust.<br />
* '''mass:''' The mass of the engine, in pounds.<br />
* '''thrust:''' The maximum sea-level thrust, in pounds.<br />
* '''afterburner:''' Maximum total thrust with afterburner/reheat, in pounds [defaults to "no additional thrust"].<br />
* '''rotate:''' Vector angle of the thrust in degrees about the Y axis [0].<br />
* '''n1-idle:''' Idling low pressure core / fan speed [55]. <br />
* '''n1-max:''' Maximum low pressure core / fan speed [102].<br />
* '''n2-idle:''' Idling high pressure core speed [73].<br />
* '''n2-max:''' Maximum high pressure core speed [103].<br />
* '''tsfc:''' Thrust-specific fuel consumption [0.8]. This should be considerably lower for modern turbofans.<br />
* '''atsfc:''' (version >= 2016.3.1) Thrust specific fuel consumption with afterburner on. When set to zero defaults to older behaviour where it is calculated from dry fuel consumption [0].<br />
* '''egt:''' Exhaust gas temperature at takeoff in K [1050].<br />
* '''epr:''' Engine pressure ratio at takeoff [3.0].<br />
* '''exhaust-speed:''' The maximum exhaust speed in knots [~1555].<br />
* '''spool-time:''' Time, in seconds, for the engine to respond to 90% of a commanded powersetting.<br />
<br />
==== Propeller ====<br />
A propeller. This element requires an engine subtag. Currently <piston-engine> and <turbine-engine> are supported.<br />
* '''x,y,z:''' The position of the mass (!) of the engine/propeller combination. If the point of force application is different (and it will be) it should be set with an <actionpt> subelement.<br />
* '''mass:''' The mass of the engine/propeller, in pounds.<br />
* '''moment:''' The moment, in kg-metres^2. This has to be hand calculated and guessed at for now. A more automated system will be forthcoming. Use a negative moment value for counter-rotating ("European" -- CCW as seen from behind the prop) propellers. A good guess for this value is the radius of the prop (in meters) squared times the mass (kg) divided by three; that is the moment of a plain "stick" bolted to the prop shaft.<br />
* '''radius:''' The radius, in meters, or the propeller.<br />
* '''cruise-speed:''' The max efficiency cruise speed of the propeller. Generally not the same as the aircraft's cruise speed.<br />
* '''cruise-rpm:''' The RPM of the propeller at max-eff. cruise.<br />
* '''cruise-power:''' The power sunk by the prop at cruise, in horsepower.<br />
* '''cruise-alt:''' The reference cruise altitude in feet.<br />
* '''takeoff-power:''' The takeoff power required by the propeller...<br />
* '''takeoff-rpm:''' ...at the given takeoff RPM.<br />
* '''gear-ratio:''' The factor by which the engine RPM is multiplied to produce the propeller RPM. Optional (defaults to 1.0).<br />
* '''contra:''' When set (contra="1"), this indicates that the propeller is a contra-rotating pair. It will not contribute to the aircraft's net gyroscopic moment, nor will it produce asymmetric torque on the aircraft body. Asymmetric slipstream effects, when implemented, will also be zero when this is set.<br />
<br />
<br />
YASim assumes a fixed-pitch propeller by default. If your engine is using a constant-speed propeller, you'll also need to provide these attributes:<br />
<br />
* '''min-rpm:''' The minimum operational RPM for a constant speed propeller. This is the speed to which the prop governor will seek when the blue lever is at a minimum. The coarse-stop attribute limits how far the governor can go into trying to reach this RPM.<br />
* '''max-rpm:''' The maximum operational RPM for a constant speed propeller. See above. The fine-stop attribute limits how far the governor can go in trying to reach this RPM.<br />
* '''fine-stop:''' The minimum pitch of the propeller (high RPM) as a ratio of ideal cruise pitch. This is set to 0.25 by default -- a higher value will result in a lower RPM at low power settings (e.g. idle, taxi, and approach).<br />
* '''coarse-stop:''' The maximum pitch of the propeller (low RPM) as a ratio of ideal cruise pitch. This is set to 4.0 by default -- a lower value may result in a higher RPM at high power settings.<br />
<br />
<br />
===== piston-engine =====<br />
<br />
A piston engine definition. This must be a subelement of an enclosing <propeller> tag.<br />
<br />
* '''eng-power:''' Maximum BHP of the engine at sea level.<br />
* '''eng-rpm:''' The engine RPM at which eng-power is developed<br />
* '''displacement:''' The engine displacement in cubic inches.<br />
* '''compression:''' The engine compression ratio.<br />
<br />
<syntaxhighlight lang="xml" line><br />
<piston-engine eng-power="2" eng-rpm="3800" displacement="20" ><br />
<control-input axis="/controls/engines/engine[0]/throttle" control="THROTTLE"/><br />
<control-input axis="/controls/engines/engine[0]/starter" control="STARTER"/><br />
<control-input axis="/controls/engines/engine[0]/magnetos" control="MAGNETOS"/><br />
<control-input axis="/controls/engines/engine[0]/mixture" control="MIXTURE"/><br />
</piston-engine><br />
</syntaxhighlight><br />
<br />
===== electric-engine =====<br />
<br />
A simplified electric DC engine model. The model is available since the end of April 2020, therefore it is currently available in daily build FlightGear snapshots. This definition must be a subelement of an enclosing <propeller> tag.<br />
<br />
* '''Kv''' electric engine constant in revolutions per minute to volt. <br />
* '''voltage''' The voltage applied to the motor e.g. Nominal battery voltage in Volts. <br />
* '''Rm''' The engine winding resistance in Ohms.<br />
<br />
<br />
Example:<br />
<br />
<syntaxhighlight lang="xml" line><br />
<propeller x="0.02" y="0" z="0.03"<br />
mass="0.05"<br />
moment="0.0006"<br />
radius="0.203"<br />
cruise-speed="26"<br />
cruise-rpm="7000"<br />
cruise-power="0.5"<br />
cruise-alt="2000"<br />
takeoff-power="0.70"<br />
takeoff-rpm="9200"<br />
contra="1"><br />
<actionpt x="0" y="0" z="0.03"/><br />
<electric-engine Kv="750" voltage="15" Rm="0.02" ><br />
<control-input axis="/controls/engines/engine[0]/throttle" control="THROTTLE"/><br />
</electric-engine><br />
</propeller><br />
</syntaxhighlight><br />
<br />
=== Landing gear ===<br />
==== gear ====<br />
Defines a landing gear. Accepts <control> subelements to map properties to steering and braking. Can also be used to simulate floats. Although the coefficients are still called ..fric, it is calculated in fluids as a drag (proportional to the square of the speed). In fluids gears are not considered to detect crashes (as on ground). <br />
* '''x,y,z:''' The location of the fully-extended gear tip.<br />
* '''compression:''' The distance in metres along the "up" axis that the gear will compress.<br />
* '''initial-load:''' The initial load of the spring in multiples of compression. Defaults to 0. (With this parameter a lower spring-constants will be used for the gear-> can reduce numerical problems (jitter)) '''Note:''' the spring-constant is varied from 0% compression to 20% compression to get continuous behavior around 0 compression. (could be physically explained by wheel deformation)<br />
* '''upx/upy/upz:''' The direction of compression, defaults to vertical (0,0,1) if unspecified. These are used only for a direction -- the vector need not be normalized, as the length is specified by "compression".<br />
* '''sfric:''' Static (non-skidding) coefficient of friction. Defaults to 0.8.<br />
* '''dfric:''' Dynamic friction. Defaults to 0.7.<br />
* '''stiction:''' Stiction to ground. Defaults to 0. stiction = "1" ensures the gear isn't sliding unintentionally (Note: please correct docu here for more detailed facts, developers didn't document this extension here and this is based on trial and guessing only)<br />
* '''spring:''' A dimensionless multiplier for the automatically generated spring constant. Increase to make the gear stiffer, decrease to make it squishier.<br />
* '''damp:''' A dimensionless multiplier for the automatically generated damping coefficient. Decrease to make the gear "bouncier", increase to make it "slower". Beware of increasing this too far: very high damping forces can make the numerics unstable. If you can't make the gear stop bouncing with this number, try increasing the compression length instead.<br />
* '''on-water:''' if this is set to "0" the gear will be ignored if on water. Defaults to "0"<br />
* '''on-solid:''' if this set to "0" the gear will be ignored if not on water. Defaults to "1"<br />
* '''speed-planing:'''<br />
* '''spring-factor-not-planing:''' At zero speed the spring factor is multiplied by spring-factor-not-planing. Above speed-planing this factor is equal to 1. The idea is, to use this for floats simulating the transition from swimming to planing. speed-planing defaults to 0, spring-factor-not-planing defaults to 1.<br />
* '''reduce-friction-by-extension:''' at full extension the friction is reduced by this relative value. 0.7 means 30% friction at full extension. If you specify a value greater than one, the friction will be zero before reaching full extension. Defaults to "0"<br />
* '''ignored-by-solver:''' with the on-water/on-solid tags you can have more than one set of gears in one aircraft, If the solver (who automatically generates the spring constants) would take all gears into account, the result would be wrong. E. G. set this tag to "1" for all gears, which are not active on runways. Defaults to "0". You can not exclude all gears in the solving process.<br />
<br />
Will define two properties associated with compression of landing gear:<br />
<br />
* '''compression-norm''' - range from 0..1, 0 means gear fully extended, 1 means fully compressed.<br />
* '''compression-m''' - vertical distance in metres that the wheel has moved in order to be on top of ground; this will usually be different from the animation distance.<br />
<br />
<syntaxhighlight lang="xml" line><br />
<!-- front gear --><br />
<br />
<gear x="0.0" y="0.0" z="-0.205"<br />
spring="0.9"<br />
damp="0.8"<br />
dfric="0.9"<br />
sfric="1.1"<br />
compression="0.051"><br />
<control-input axis="/controls/flight/rudder" control="STEER" square="true" src0="-1.0" src1="1.0" dst0="-0.3" dst1="0.3"/><br />
<control-input axis="/controls/gear/brake-right" control="BRAKE" split="true"/><br />
<control-input axis="/controls/gear/brake-parking" control="BRAKE" split="true"/><br />
</gear><br />
<br />
<!-- two rear gears --><br />
<br />
<gear x="-0.4" y="0.25" z="-0.205"<br />
spring="0.9"<br />
damp="0.8"<br />
dfric="0.9"<br />
sfric="1.1"<br />
compression="0.051"><br />
<control-input axis="/controls/gear/brake-right" control="BRAKE" split="true"/><br />
<control-input axis="/controls/gear/brake-parking" control="BRAKE" split="true"/><br />
</gear><br />
<br />
<gear x="-0.4" y="-0.25" z="-0.205"<br />
spring="0.9"<br />
damp="0.8"<br />
dfric="0.9"<br />
sfric="1.1"<br />
compression="0.051"><br />
<control-input axis="/controls/gear/brake-left" control="BRAKE" split="true"/><br />
<control-input axis="/controls/gear/brake-parking" control="BRAKE" split="true"/><br />
</gear><br />
</syntaxhighlight><br />
<br />
==== Launchbar ====<br />
Defines a catapult launchbar or strop.<br />
* '''x,y,z:''' The location of the mount point of the launch bar or strop on the aircraft.<br />
* '''length:''' The length of the launch bar from mount point to tip<br />
* '''down-angle:''' The max angle below the horizontal the launchbar can achieve.<br />
* '''up-angle:''' The max angle above the horizontal the launchbar can achieve.<br />
* '''holdback-{x,y,z}:''' The location of the holdback mount point on the aircraft.<br />
* '''holdback-length:''' The length of the holdback from mount point to tip. Note: holdback up-angle and down-angle are the same as those defined for the launchbar and are not specified in the configuration.<br />
<br />
=== Fuel ===<br />
==== tank ====<br />
A fuel tank. Tanks in the aircraft are identified numerically (starting from zero), in the order they are defined in the file. If the left tank is first, "tank[0]" will be the left tank. <br />
* '''x,y,z:''' The location of the tank.<br />
* '''capacity:''' The maximum contents of the tank, in pounds. Not gallons -- YASim supports fuels of varying densities.<br />
* '''jet:''' A boolean. If present, this causes the fuel density to be treated as Jet-A. Otherwise, gasoline density is used. A more elaborate density setting (in pounds per gallon, for example) would be easy to implement. Bug me.<br />
<br />
=== Center of Gravity ===<br />
==== Ballast ====<br />
This is a mechanism for modifying the mass distribution of the aircraft. A ballast setting specifies that a particular amount of the empty weight of the aircraft must be placed at a given location. The remaining non-ballast weight will be distributed "intelligently" across the fuselage and wing objects. Note again: this does NOT change the empty weight of the aircraft. <br />
* '''x,y,z:''' The location of the ballast.<br />
* '''mass:''' How much mass, in pounds, to put there. Note that this value can be negative. I find that I often need to "lighten" the tail of the aircraft.<br />
<br />
<br />
<syntaxhighlight lang="xml" line><br />
<ballast x="-0.24" y="0.0" z="0.33" mass-kg="0.5"/><br />
</syntaxhighlight><br />
<br />
==== Weight ====<br />
This is an added weight, something not part of the empty weight of the aircraft, like passengers, cargo, or external stores. The actual value of the mass is not specified here, instead, a mapping to a property is used. This allows external code, such as the panel, to control the weight (loading a given cargo configuration from preference files, dropping bombs at runtime, etc...)<br />
* '''x,y,z:''' The location of the weight.<br />
* '''mass-prop:''' The name of the fgfs property containing the mass, in pounds, of this weight.<br />
* '''size:''' The aerodynamic "size", in metres, of the object. This is important for external stores, which will cause drag. For reasonably aerodynamic stuff like bombs, the size should be roughly the width of the object. For other stuff, you're on your own. The default is zero, which results in no aerodynamic force (internal cargo).<br />
* '''solve-weight:''' Subtag of approach and cruise parameters. Used to specify a non-zero setting for a <weight> tag during solution. The default is to assume all weights are zero at the given performance numbers.<br />
* '''idx:''' Index of the weight in the file (starting with zero).<br />
* '''weight:''' Weight setting in pounds.<br />
<br />
<syntaxhighlight lang="xml" line><br />
<weight x="-0.06471" y="0.225" z="-0.2" mass-prop="/sim/weight[0]/weight-kg"/><br />
</syntaxhighlight><br />
<br />
=== Controls ===<br />
==== control-input ====<br />
This element manages a mapping from fgfs properties (user input) to settable values on the aircraft's objects. Note that the value to be set MUST (!) be valid on the given object type. This is not checked for by the parser, and will cause a runtime crash if you try it. Wing's don't have throttle controls, etc... Note that multiple axes may be set on the same value. They are summed before setting.<br />
* '''axis:''' The name of the double-valued fgfs property "axis" to use as input, such as "/controls/flight/aileron".<br />
* '''control:''' Which control axis to set on the objects. It can have the following values:<br />
** THROTTLE - The throttle on a jet or propeller. <br />
** MIXTURE - The mixture on a propeller.<br />
** REHEAT - The afterburner on a jet<br />
** PROP - The propeller advance<br />
** BRAKE - The brake on a gear.<br />
** STEER - The steering angle on a gear. <br />
** INCIDENCE - The incidence angle of a wing.<br />
** FLAP0 - The flap0 deflection of a wing. <br />
** FLAP1 - The flap1 deflection of a wing. <br />
** SLAT - The slat extension of a wing. <br />
** SPOILER - The spoiler extension for a wing. <br />
** CYCLICAIL - The "aileron" cyclic input of a rotor <br />
** CYCLICELE - The "elevator" cyclic input of a rotor <br />
** COLLECTIVE - The collective input of a rotor<br />
** ROTORENGINEON - If not equal zero the rotor is rotating <br />
** WINCHRELSPEED - The relative winch speed <br />
** {... and many more, see [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/FDM/YASim/ControlMap.cpp#l25 ControlMap.cpp] ...}<br />
* '''invert:''' Negate the value of the property before settling on the object.<br />
* '''split:''' Applicable to wing control surfaces. Sets the normal value on the left-wing, and a negated value on the right-wing.<br />
* '''square:''' Squares the value before setting. Useful for controls like a steering that needs a wide range, yet lots of sensitivity in the center. Obviously only applicable to values that have a range of [-1:1] or [0:1]. <br />
* '''src0/src1/dst0/dst1:''' If present, these define a linear mapping from the source to the output value. Input values in the range src0-src1 are mapped linearly to dst0-dst1, with clamping for input values that lie outside the range.<br />
<br />
==== control-output ====<br />
This can be used to pass the value of a YASim control axis (after all mapping and summing is applied) back to the property tree.<br />
* '''control:''' Name of the control axis. See above.<br />
* '''prop:''' Property node to receive the value.<br />
* '''side:''' Optional, for split controls. Either "right" or "left" <br />
* '''min/max:''' Clamping applied to output value.<br />
<br />
==== control-speed ====<br />
Some controls (most notably flaps and hydraulics) have maximum slew rates and cannot respond instantly to pilot input. This can be implemented with a control-speed tag, which defines a "transition time" required to slew through the full input range. Note that this tag is semi-deprecated, complicated control input filtering can be done much more robustly from a Nasal script.<br />
* '''control:''' Name of the control axis. See above.<br />
* '''transition-time:''' Time in seconds to slew through input range.<br />
<br />
==== control-setting ====<br />
This tag is used to define a particular setting for a control axis inside the <cruise> or <approach> tags, where obviously property input is not available. It can be used, for example, to inform the solver that the approach performance values assume full flaps, etc...<br />
* '''axis:''' Name of the control input (i.e. a property name)<br />
* '''value:''' Value of the control axis.<br />
<br />
=== Winch and Aerotow ===<br />
==== hitch ====<br />
A hitch, can be used for winch-start (in gliders) or aerotow (in gliders and motor aircraft) or for external cargo with helicopter. You can do aerotow over the net via multiplayer (see j3 and bocian as an example).<br />
* '''name:''' the name of the hitch. must be aerotow if you want to do aerotow via multiplayer. You will find many properties at /sim/hitches/name. Most of them are directly tied to the internal variables, you can modify them as you like. You can add a listener to the property "broken", e. g. for playing a sound.<br />
* '''x,y,z:''' The position of the hitch<br />
* '''force-is-calculated-by-other:''' if you want to simulate aerotowing over the internet, set this value to "1" in the motor aircraft. Don't specify or set this to zero in gliders. In a LAN the time lag might be small enough to set it on both aircraft to "0". It's intended, that this is done automatically in the future.<br />
==== tow ====<br />
The tow used for aerotow or winch. This must be a subelement of an enclosing <hitch> tag.<br />
* '''length:''' upstretched length in metres<br />
* '''weight-per-meter:''' in kg/metre<br />
* '''elastic-constant:''' lower values give higher elasticity<br />
* '''break-force:''' in N<br />
* '''mp-auto-connect-period:''' the every x seconds a towed multiplayer aircraft is searched. If found, this tow is connected automatically, parameters are copied from the other aircraft. Should be set only in the motor aircraft, not in the glider<br />
==== winch ====<br />
The tow used for aerotow or winch. This must be a subelement of an enclosing <hitch> tag.<br />
* '''max-tow-length:''' in m<br />
* '''min-tow-length''': in m<br />
* '''initial-tow-length:''' in m. The initial tow length also defines the length/search radius used for the mp-autoconnect feature<br />
* '''max-winch-speed:''' in m/s<br />
* '''power:''' in kW<br />
* '''max-force:''' in N<br />
<br />
<br />
<syntaxhighlight lang="xml" line><br />
<hitch name="winch" x="0.0" y="0.0" z="0.0"><br />
<tow length="50" weight-per-meter="0.0035" elastic-constant="40000" break-force="10000"/><br />
<!-- 3mm paracord--><br />
<winch max-tow-length="1000" min-tow-length="1" initial-tow-length="1000" max-winch-speed="20" power="2" max-force="80"/><br />
<control-input axis="/controls/winch/place" control="PLACEWINCH"/><br />
</hitch><br />
<hitch name="aerotow" x="0.0" y="0.0" z="0.0" force-is-calculated-by-other="0"><br />
<tow length="60" weight-per-meter="0.0035" elastic-constant="9000" break-force="100" mp-auto-connect-period="0.0"/><br />
<winch max-tow-length="1000" min-tow-length="60" initial-tow-length="60"/><br />
<control-input axis="/controls/aerotow/find-aircraft" control="FINDAITOW"/><br />
</hitch><br />
</syntaxhighlight><br />
<br />
== Visualization ==<br />
<br />
=== Blender visualization tool ===<br />
<br />
[[File:Yasim_visualisation_dc6.png|thumb|dc6 FDM in Blender]]To make the programmed aircraft visible it is possible to load and compare it with the 3D model within [[Blender]]. They applaud for this ''very'' useful script goes to M. Franz, thank you very much!<br />
<br />
For Blender versions <= 2.4 the script is located in FlightGears source code {{flightgear file|utils/Modeller/yasim_import.py}}.<br />
<br />
For Blender versions newer than 2.4, please see [[Blender YASim import]].<br />
<br />
The howto, taken from inside the script:<br />
<br />
yasim_import.py loads and visualizes a YASim FDM geometry<br />
=========================================================<br />
<br />
It is recommended to load the model superimposed over a greyed out and immutable copy of the aircraft model:<br />
<br />
(0) put this script into ~/.blender/scripts/<br />
(1) load or import aircraft model (menu -> "File" -> "Import" -> "AC3D (.ac) ...")<br />
(2) create new *empty* scene (menu -> arrow button left of "SCE:scene1" combobox -> "ADD NEW" -> "empty")<br />
(3) rename scene to yasim (not required)<br />
(4) link to scene1 (F10 -> "Output" tab -> arrow button left of text entry "No Set Scene" -> "scene1")<br />
(5) now load the YASim config file (menu -> "File" -> "Import" -> "YASim (.xml) ...")<br />
<br />
This is good enough for simple checks. But if you are working on the YASim configuration, then you need a<br />
quick and convenient way to reload the file. In that case, continue after (4):<br />
<br />
(5) switch the button area at the bottom of the blender screen to "Scripts Window" mode (green python snake icon)<br />
(6) load the YASim config file (menu -> "Scripts" -> "Import" -> "YASim (.xml) ...")<br />
(7) make the "Scripts Window" area as small as possible by dragging the area separator down<br />
(8) optionally split the "3D View" area and switch the right part to the "Outliner"<br />
(9) press the "Reload YASim" button in the script area to reload the file<br />
<br />
<br />
If the 3D model is displaced with respect to the FDM model, then the <offsets> values from the<br />
model animation XML file should be added as comment to the YASim config file, as a line all by<br />
itself, with no spaces surrounding the equal signs. Spaces elsewhere are allowed. For example:<br />
<br />
<offsets><br />
<x-m>3.45</x-m><br />
<z-m>-0.4</z-m><br />
<pitch-deg>5</pitch-deg><br />
</offsets><br />
<br />
becomes:<br />
<br />
<!-- offsets: x=3.45 z=-0.4 p=5 --><br />
<br />
Possible variables are:<br />
<br />
x ... <x-m><br />
y ... <y-m><br />
z ... <z-m><br />
h ... <heading-deg><br />
p ... <pitch-deg><br />
r ... <roll-deg><br />
<br />
Of course, absolute FDM coordinates can then no longer directly be read from Blender's 3D view.<br />
The cursor coordinates display in the script area, however, shows the coordinates in YASim space.<br />
Note that object names don't contain XML indices but element numbers. YASim_hstab#2 is the third<br />
hstab in the whole file, not necessarily in its parent XML group. A floating-point part in the<br />
object name (e.g. YASim_hstab#2.004) only means that the geometry has been reloaded that often.<br />
It's an unavoidable consequence of how Blender deals with meshes.<br />
<br />
<br />
Elements are displayed as follows:<br />
<br />
cockpit -> monkey head<br />
fuselage -> blue "tube" (with only 12 sides for less clutter); center at "a"<br />
vstab -> red with yellow flaps<br />
wing/mstab/hstab -> green with yellow flaps/spoilers/slats (always 20 cm deep);<br />
symmetric surfaces are only displayed on the left side<br />
thrusters (jet/propeller/thruster) -> dashed line from center to actionpt;<br />
arrow from actionpt along thrust vector (always 1 m long);<br />
propeller circle<br />
rotor -> radius and rel_len_blade_start circle, direction arrow,<br />
normal and forward vector, one blade at phi0<br />
gear -> contact point and compression vector (no arrow head)<br />
tank -> cube (10 cm side length)<br />
weight -> inverted cone<br />
ballast -> cylinder<br />
hitch -> circle (10 cm diameter)<br />
hook -> dashed line for up angle, T-line for down angle<br />
launchbar -> dashed line for up angles, T-line for down angles<br />
A note about step (0) for Windows users: the mentioned path is inside the folder where Blender lives, something like <code>C:\Program Files\Blender Foundation\Blender\.blender\scripts</code>.<br />
<br />
=== Visualize model in OpenSCAD or FreeCAD ===<br />
<br />
There exist a possibility to display the YASim XML elements in the OpenSCAD or FreeCAD tools. This could be extremely useful in the case of UAV aircraft development. <br />
<br />
* [https://github.com/ThunderFly-aerospace/YASim2SCAD YASim2SCAD] - This tool converts YASim XML to scad file which could be displayed as an overlay in OpenSCAD or FreeCAD project.<br />
* [https://gitlab.com/yasimtoscad/yasimtoscad yasimtoscad] - Another tool to convert YASim XML to scad file which could be displayed as an overlay in OpenSCAD.<br />
<br />
<br />
=== Visualization tools ===<br />
<br />
* [https://github.com/bitwisetech/ysimi YSIMI] Interactive Tuning Tools for FlightGear's YASIM Flight Dynamics Model<br />
* [https://github.com/bitwisetech/yasiVers yasiVers] is a tool for visualization of YASim calculations.<br />
<br />
== Export of YASim internals to property tree ==<br />
Ever wondered what is going on inside yasim? See the property tree under /fdm/yasim/<br />
<br />
Some information is static and shows what yasim has compiled from your XML. <br />
Other information is "run-time" like forces, speed, acceleration, c.g. <br />
<br />
If note noted otherwise:<br />
* expect metric unit (meter, kilogram, newton, ...)<br />
* expect minimum version 2017.2<br />
<br />
{| class="wikitable"<br />
|-<br />
! Path !! Description !! Information type !! min. version<br />
|-<br />
| accelerations/ || linear and rot. accelerations in aircraft coord. || run time ||<br />
|-<br />
| debug/ || misc internals, for now subject to change without notice || run time || 2018.1<br />
|-<br />
| forces/ || aerodynamic forces in N || run time ||<br />
|-<br />
| velocities/ || linear and rot. velocities in aircraft coord. || run time ||<br />
|-<br />
| model/cg-x-range-aft || desired CG range || compile time ||<br />
|-<br />
| model/cg-x-range-front || desired CG range || compile time ||<br />
|-<br />
| model/cg-x-max || CG hard limit from gear position || compile time ||<br />
|-<br />
| model/cg-x-min || CG hard limit from gear position || compile time ||<br />
|-<br />
| model/masses || shows the calculated mass points || compile time ||<br />
|-<br />
| model/wings || wing parameters || compile time ||<br />
|}<br />
<br />
<br />
== Command Line ==<br />
=== Windows ===<br />
By using the standard command line, we can see what the YASim solver is calculating. First, open up Command Prompt, enter in the location of yasim.exe, and then the location of the YASim XML file. For example, here's what you would type in for a standard Windows [[Changelog_2.12|FlightGear 2.12.0]] installation, and viewing the [[F-14_Tomcat|F-14B's]] YASim file.<br />
{{Note|You can copy & paste the examples into Command Prompt by right-clicking on the title and navigate to Edit > Paste. Then, click Enter to execute.}} <br />
<br />
<code>"C:\Program Files\FlightGear\bin\Win32\yasim.exe" "C:\Program Files\FlightGear\data\Aircraft\f-14b\f-14b-yasim.xml"</code><br />
<br />
The results will give many different values.<br />
<br />
* '''Drag Coefficient:''' The drag coefficient of the aircraft.<br />
* '''Lift Ratio:''' The lift ratio of the aircraft.<br />
* '''Cruise AoA:''' The cruise AoA, from conditions at [[YASim#cruise|<cruise>]] in the xml file.<br />
* '''Tail Incidence:''' The incidence angle of the tail, "solved" by YASim as a way to stabilize the aircraft.<br />
* '''Approach Elevator:''' The approach elevator, from conditions at [[YASim#approach|<approach>]] in the xml file.<br />
* '''CG:''' Center of gravity of the aircraft in coordinates. Unless it's supposed to be offset, it should always have a Y value of 0.<br />
<br />
The YASim standalone solver also has some command line flags that change it's behaviour.<br />
<br />
<code>"C:\Program Files\FlightGear\bin\Win32\yasim.exe" "C:\Program Files\FlightGear\data\Aircraft\f-14b\f-14b-yasim.xml" -g -a 1000 -s 490</code><br />
<br />
* '''-g:''' Instructs YASim to generate space-separated tabular data instead of the usual solver output. This can be redirected to a file and used in various plotting programs to visualize the actual lift, drag, L/D curves. The columns of the output from left to right are: AoA, Lift, Drag, L/D. (aoa in degrees, lift and drag in G's).<br />
* '''-a <altitude in meter:>''' Run the solver at the given altitude in meter.<br />
* '''-s <speed in knots>:''' Also run at the given airspeed in knots.<br />
<br />
{{Note|The values generated by this method are for the aircraft taken as a whole, as solved by YASim, so they differ from the values of the wing airfoil.}}<br />
<br />
To get the tabular output for the example above at 1000 m and 150 knots, and to redirect this to a file, one would issue:<br />
<br />
<code>"C:\Program Files\FlightGear\bin\Win32\yasim.exe" "C:\Program Files\FlightGear\data\Aircraft\f-14b\f-14b-yasim.xml" -g -a 1000 -s 150 > "C:\Program Files\FlightGear\yasim.txt"</code><br />
<br />
== New features and bugfixes in version 2017.2 ==<br />
<br />
=== XML parser ===<br />
==== support for metric and imperial units ====<br />
To make life easier for aircraft developers, the parser supports new additional attributes with a unit suffix, e.g. speed-kt for knots and speed-kmh for kilometers per hour.<br />
* <code><airplane {mass, mass-lbs, mass-kg}="12345" ></code><br />
* <code><approach {speed, speed-kt, speed-kmh}="123" ></code><br />
* <code><cruise {speed, speed-kt, speed-kmh}="123" ></code><br />
* <code><solve-weight {weight, weight-lbs, weight-kg}="123" ></code><br />
* <code><jet {mass, mass-lbs, mass-kg}="1234" ></code><br />
* <code><tank {capacity, capacity-lbs, capacity-kg}="12345" ></code><br />
* <code><ballast {mass, mass-lbs, mass-kg}="1234" ></code><br />
<br />
{{Note|Aircraft using this new attributes will not run on older versions of FlightGear, so it is probably wise to publish those only after a reasonable number of users switched version 2017.2 or newer.}}<br />
<br />
==== CG tuning help ====<br />
{{Note| The feature described in this section is not fully implemented yet, however, it may be of some help already.<br />
It is currently implemented for the yasim CLI tool only. It does not affect the airplane behaviour while running FlightGear. }}<br />
<br />
New attributes have been added to <airplane> to assist tuning the center of gravity (CG).<br />
The CG position is often expressed relative to the [https://en.wikipedia.org/wiki/Chord_(aeronautics)#Mean_aerodynamic_chord MAC] of the wing in percent. You can specify a desired range for CG in % relative to MAC, it will show up in the output of the yasim CLI tool (see example below):<br />
<br />
* cg-min: default 25% (just a guess, better numbers are welcome)<br />
* cg-max: default 30% (just a guess, better numbers are welcome)<br />
<br />
{{Note| By convention 0% is leading edge, 100% is trailing edge, however the absolute values on x-axis are the other way round, e.g. nose is +x, tail is -x }}<br />
{{warning|The MAC calculation in version 2017.2 works only on the <wing> element. Numbers will be wrong, if your model uses a combination of <wing> and <mstab> to build a wing with two or more sections.<br />
Section support will be added in version 2018.1}}<br />
YASim will print the leading edge coordinates of the MAC (x,y) and its length.<br />
<br />
'''Example output'''<br />
<pre><br />
$ yasim Citation-II-yasim.xml <br />
This aircraft uses yasim version '2017.2' <br />
========================== <br />
= YASim solution results = <br />
========================== <br />
Iterations: 2210 <br />
Drag Coefficient: 12.304669 <br />
Lift Ratio: 85.317558 <br />
Cruise AoA: 4.016746 deg <br />
Tail Incidence: -3.053278 deg <br />
Approach Elevator: -0.377542 <br />
<br />
CG: x:-6.543, y:-0.000, z:0.044 <br />
Wing MAC (*1): x:-6.00, y:3.83, length:2.0 <br />
CG-x rel. MAC: 0.272 <br />
CG-x desired: -6.599 < -6.543 < -6.198 <br />
<br />
Inertia tensor [kg*m^2], origo at CG: <br />
<br />
18009.289, -0.000, 7120.470 <br />
-0.000, 42459.316, 0.000 <br />
7120.470, 0.000, 56980.656 <br />
<br />
(*1) MAC calculation works on <wing> only! Numbers will be wrong for segmented wings, e.g. <wing>+<mstab>.<br />
</pre><br />
<br />
=== Aircraft developer helpers ===<br />
The command line utility got some new options. For some strange reason, the -a parameter expects altitude in meters instead of ft. This is now visible in the usage message but left unchanged for compatibility.<br />
<syntaxhighlight>Usage:<br />
yasim <aircraft.xml> [-g [-a meters] [-s kts] [-approach | -cruise] ]<br />
yasim <aircraft.xml> [-d [-a meters] [-approach | -cruise] ]<br />
yasim <aircraft.xml> [-m]<br />
-g print lift/drag table: aoa, lift, drag, lift/drag <br />
-d print drag over TAS: kts, drag<br />
-a set altitude in meters!<br />
-s set speed in knots<br />
-m print mass distribution table: id, x, y, z, mass</syntaxhighlight><br />
<br />
=== Bugfixes ===<br />
The following bugfixes require <airplane version="2017.2"> for backward compatibility <br />
* Ground effect: corrected the calculation of the height where g.e. ends<br />
* Stall parameters were set wrong for wings with camber=0<br />
<br />
== New features and bugfixes in version 2018.1 ==<br />
The following is under development and hopefully finds its way into FG version 2018.1<br />
<br />
=== Wing Section Support ===<br />
Many airliners have wings with a geometry that is just a little more complex than what YASim supported initially (tapered wing with some angles like sweep, dihedral, ...), e.g. they have an inboard section and an outboard section that can be described with YASim wing syntax. You can use a wing + a mstab XML element to describe this geometry but it is easier if YASim can just append more wing sections by simply adding more wing XML elements. This is now (Version 2018.1) possible, yasim will simply append sections if it finds more than one wing or hstab in the XML.<br />
You should use '''&lt;wing append="1" ... &gt;''' for all but the first wing/hstab declaration. <br />
{{Note|YASim will ignore the root point (x,y,z), the chord length and the incidence attributes, if you add "append" and calculate those from the previous wing section. }}<br />
MAC calculation works for the whole wing.<br />
<br />
{{warning|Aircrafts using this feature will not work with older versions of flightgear. }}<br />
To keep the aircraft backward compatible for a while, it is recommended to create a copy of its yasim XML file for development. <br />
Once you are happy with the CG and wing parameters you can use the output of the YASim CLI tool to modifiy the original XML. <br />
The tool will output the needed x,y,z etc per wing section to create a XML in old format with (only one) <wing> + <mstab>.<br />
<br />
=== More information from CLI tools ===<br />
You should configure the maximum take of weight (MTOW) in your XML file by adding either ''mtow-lbs'' or ''mtow-kg'' attribute to the airplane:<br />
<br />
<code> &lt;airplane mass="7500" version="2018.1" mtow-lbs="12500"&gt; </code><br />
<br />
'''Example output'''<br />
<pre><br />
yasim CRJ700.xml <br />
==========================<br />
= YASim solution results =<br />
==========================<br />
Iterations : 1024<br />
Drag Coefficient : 17.707<br />
Lift Ratio : 145.841<br />
Cruise AoA : -0.11 deg<br />
Tail Incidence : 3.47 deg<br />
Approach Elevator : -0.792<br />
<br />
CG : x:-0.046, y:0.000, z:-1.222<br />
Wing MAC : (x:0.79, y:4.99), length:3.4 <br />
hard limit CG-x : 14.232 m<br />
soft limit CG-x : -0.058 m<br />
CG-x : -0.046 m<br />
CG-x rel. MAC : 25%<br />
soft limit CG-x : -0.228 m<br />
hard limit CG-x : -0.986 m<br />
<br />
wing lever : -0.012 m<br />
tail lever : -13.997 m<br />
<br />
max thrust : 157.18 kN<br />
thrust/empty : 0.81<br />
thrust/mtow : 0.49<br />
<br />
wing span : 22.64 m<br />
sweep lead. edge : 30.2 .. 30.6 deg<br />
wing area : 58.70 m^2<br />
wing load empty : 336.15 kg/m^2 (Empty 19731 kg)<br />
wing load MTOW : 562.18 kg/m^2 (MTOW 32999 kg)<br />
<br />
tail span : 8.533 m<br />
tail area : 14.838 m^2<br />
<br />
#wing sections: 2<br />
Section 0 base point (0.450, 1.226, -2.034), chord 5.085, incidence at section root 5.0deg<br />
Section 1 base point (-0.663, 4.754, -1.942), chord 3.204, incidence at section root 3.0deg<br />
<br />
Inertia tensor [kg*m^2], origo at CG:<br />
<br />
195646, 0, 122265<br />
0, 1757279, 0<br />
122265, 0, 1904528<br />
</pre><br />
<br />
=== Variable tail incidence / elevator trim ===<br />
Small GA aircrafts usually trim with a trim tab on the elevator. For efficiency, airliners normally do not trim the elevator ("flap") <br />
but rotate the whole stabilizer (=tail) wing, e.g. they change the incidence for this wing. While this feature was somehow foreseen, <br />
it was not implemented yet, most likely because the "tail incidence" is one of the free variables used by the YASim solver. <br />
However, it is possible now to use the control="INCIDENCE" within the &lt;hstab&gt; to implement an alternative trim '''while maintaining full elevator authority'''.<br />
<pre><br />
<hstab ... incidence-min-deg="-13.0" incidence-max-deg="2.0"><br />
...<br />
<control-input axis="/controls/flight/hstab-trim" control="INCIDENCE" /><br />
<control-speed control="INCIDENCE" transition-time="20.0" /><br />
<control-output control="INCIDENCE" prop="/surface-positions/hstab-rad" /> <br />
</hstab><br />
</pre><br />
{{Note|The control output of INCIDENCE is the angle in radians, not in degree, as that is the unit internally used by YASim.}}<br />
{{warning|The OPTIONAL incidence-min-deg and incidence-max-deg set the limits for the solver. You must make sure to select a sufficiently large range or solver will fail. }}<br />
First experiments with this feature were successful in that the aircraft pitch could be changed as expected but fine tuning will be necessary.<br />
<br />
<br />
== Related content ==<br />
* [[Howto:Make a helicopter#XML Elements]] &ndash; Rotor and rotorgear YASim elements<br />
* [[Towing]]<br />
* [[YASim Development Tools]]<br />
<br />
== External links ==<br />
* {{cite web<br />
| url = http://www.buckarooshangar.com/flightgear/yasimtut.html<br />
| title = Guide to YASim<br />
| first = Gary R. "Buckaroo"<br />
| last = Neely<br />
| authorlink = http://www.buckarooshangar.com/flightgear/<br />
| date = 2013<br />
| accessdate = April 16, 2020<br />
}} - A very helpful guide<br />
* {{cite web<br />
| url = https://sourceforge.net/projects/dacpei/<br />
| title = DACPEI<br />
| author = pytoche<br />
| date = February 2012<br />
| publisher = SourceForge<br />
| accessdate = April 16, 2020<br />
}} - A fixed wing light aircraft WYSIWUG concept design suite that can export an YASim FDM to FlightGear.<br />
<br />
{{FDM}}<br />
<br />
[[Category:Flight Dynamics Model]]<br />
<br />
[[fr:YASim]]</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=Instant_Replay&diff=134785Instant Replay2022-03-14T12:17:08Z<p>Cgdae: Mention localfile is in /sim/replay/tape-directory when replaying from url.</p>
<hr />
<div>== Normal recording ==<br />
<br />
Flightgear maintains an in-memory recording of the current session. To avoid running our of memory, only the last minute or so is recorded in full detail, and older data is gradually pruned.<br />
<br />
The in-memory recording can be saved to a file.<br />
<br />
=== Starting and Controlling Replay of Normal recording ===<br />
<br />
* Press '''Ctrl-r''' or select '''Instant Replay''' from the '''View''' menu to start the replay. Replay starts immediately.<br />
* Press '''p''' or click '''pause''' to pause/resume the replay.<br />
* Use the '''left/right''' arrow keys, or the '''&lt;&lt;''', '''&gt;&gt;''' buttons to skip. You can also use the mouse and drag the time slider.<br />
* Use the '''up/down''' arrow keys, or the '''+''', '''-''' buttons to change replay speed. You can replay at slow-motion, real-time or fast-forward speed.<br />
* Enable the '''Loop''' checkbox to continuously repeat the playback. When you configure a duration (in seconds) then only the last few seconds are continuously replayed.<br />
<br />
[[File:FG-instant-replay-new.png|thumb|500px|The instant replay dialog.]]<br />
<br />
=== Stopping Replay ===<br />
<br />
* Press '''Escape''' or the '''End Replay''' button to stop replay and return to the position prior to starting replay.<br />
* Alternatively, click the '''My Controls!''' button to take over control at any point. With this feature you can use the replay system to go back in time, regain control and then continue the flight from a past position. This is useful to train particular flight phases, such as flying the same approach again and again, maybe using different weather/wind conditions.<br />
<br />
== Record/replay on next ==<br />
<br />
There are various additions to record/replay on next:<br />
<br />
* Extended '''File/Flight Recorder Control''' dialogue.<br />
[[File:Flight-recorder-control.png|thumb]]<br />
* Periodic generation of a recovery snapshot, allowing resumption after a flightgear crash.<br />
* Continuous recording system:<br />
** Continuous recording to file without any loss of detail.<br />
** Optionally record/replay extra information:<br />
*** Multiplayer aircraft.<br />
*** Main window size.<br />
*** Main window position.<br />
*** Main window view.<br />
* Aircraft override:<br />
** When loading a Continuous recording at startup, we override the aircraft and starting airport to match what is in the recording.<br />
* Replay of Continuous recordings from URL:<br />
** Extends the '''--load-tape command-line''' option, for example: '''--load-tape=<nowiki>http://foo.com/bar.fgtape</nowiki>'''<br />
<br />
=== Details ===<br />
<br />
* A recovery snapshot is actually a single-frame continuous recording, and will be called '''<aircraft-type>-recovery.fgtape'''.<br />
** Load on the command line with '''--load-tape=<aircraft-type>-recovery'''.<br />
** Then do '''Ctrl-R''' to see the replay dialogue.<br />
** And click on '''My Controls'''.<br />
** Notes:<br />
*** Some aircraft do not support '''My Controls'''.<br />
*** Loading a recovery file from within Flightgear via the '''Flight Recorder Control''' dialogue is usually not useful because the recovery file will have been overwritten by the current Flightgear session.<br />
* Continuous recording to file uncompressed is e.g. 100MB for an hour's recording near EDDF.<br />
* Support for compression of Continuous recordings was pushed to next on 2021-7-31 ({{flightgear commit|7d414886e00e}}).<br />
* Replay of Continuous recordings from URL:<br />
** Downloads to local file in the background while replaying.<br />
** Reuses local file if present, appending to it in the background if it was a partial download.<br />
** Local file is in directory specified by property '''/sim/replay/tape-directory'''.<br />
<br />
For details on recording file formats, see: {{flightgear file|docs-mini/README-recordings.md}}<br />
<br />
----<br />
<br />
== FG 2.6.0 and later ==<br />
{{Move|Flight Recorder}}<br />
the <br />
flight recorder tapes are only 1 or 2 hours max... at one time i wanted to do <br />
one for a cross-country flight but when i saved it i only got the last hour or <br />
two<br />
{{Note|<br />
{{FGCquote<br />
|the "my controls" button is currently intentionally disabled for JSBSim and for YASim helicopters. Only works with YASim aircraft so far.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/30084554/<br />
|title=<nowiki>Re: [Flightgear-devel] flight recorder / replay system</nowiki><br />
|author=<nowiki>ThorstenB</nowiki><br />
|date=<nowiki>2012-11-11</nowiki><br />
}}<br />
}}<br />
}}<br />
FG 2.6.0 introduced a new replay system which can be adapted to individual aircraft and provides better recordings/playbacks. It also introduces a new GUI as well as a dedicated file format for serializing flights to disk: [[Fgtape]].<br />
[[File:FG-instant-replay-new.png|thumb|500px|The instant replay dialog.]]<br />
<br />
== FG 2.4.0 and earlier ==<br />
[[File:FG-instant-replay.gif|thumb|220px|The instant replay dialog for FG2.4.0 and earlier.]]<br />
For FG 2.4.0 and earlier, a simple dialog box is presented with a couple of options (duration of replay and view type). <br />
* A value of 0 for duration will replay the entire flight. The default value is 90 seconds (similar to MSFS). If you want something different, just type the number of seconds desired in the text box. <br />
* The view option is a drop-down box with three options corresponding to Cockpit, Chase and Tower views. No matter what this is initially set to, the view type can be changed as normal with v/V and ctrl-v to cycle forwards or backwards through all the available views or return to default Cockpit view.<br />
<br />
To return to normal flight, press 'p' twice (pause/unpause). This returns you to the point where you selected Instant Replay. You cannot back up 30 seconds or so and try that landing again. Also, it is currently not possible to save the replay buffer to a file to load and replay a flight later on.<br />
<br />
'''Note:''' only data directly related to your aircraft is saved and played back, AI objects, multiplayer aircraft or any random features will not be replayed.<br />
<br />
{{FGCquote<br />
|The replay system uses three buffer levels: short term memory records 60 <br/><br />
seconds at full frame rate, mid term buffer records another 10 minutes <br/><br />
at 2fps, and the long term buffer holds 1 hour at 1/5fps. As I stated <br/><br />
earlier, I'm not changing the buffering scheme itself. However, the <br/><br />
buffer durations and rates are exposed by properties now. So, if you had <br/><br />
enough memory, you could increase the buffer sizes or change their rates.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28045468/<br />
|title=<nowiki>Re: [Flightgear-devel] flight recorder / replay system</nowiki><br />
|author=<nowiki>ThorstenB</nowiki><br />
|date=<nowiki>2011-09-05</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= You should be able to extend the recording limit by changing the /sim/reply/duration property (e.g. by clicking on View -> Instant Replay and changing the duration in the textbox next to the "Loop" checkbox). <br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/34868828/<br />
| title = <nowiki>Re: [Flightgear-devel] flight recorder time limit</nowiki><br />
| author = <nowiki>Alessandro Menti</nowiki><br />
| date = Feb 20th, 2016<br />
| added = Feb 20th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
<br />
== Feature Requests ==<br />
{{FGCquote<br />
|1= If the F/R data was written to disk immediately, so it doesn't have to take up valueable RAM, would make it possible to record nearly indefinitely (depending on disk space). And delete this data like a tmp-file on shutdown, if it isn't stored somewhere else...<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/34868775/<br />
| title = <nowiki>[Flightgear-devel] flight recorder time limit</nowiki><br />
| author = <nowiki>chris</nowiki><br />
| date = Feb 20th, 2016<br />
| added = Feb 20th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
{{FGCquote<br />
|1= This should be quite doable, the FlightRecorder code is quite self-contained. Also it uses thining of the history buckets so actually I think for multi-hour data, maybe it just needs a coarser (maybe one sample per 5 seconds?) bucket of larger sie. If you want to look at the code I’m happy provide guidance on enhancing it.<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/34869713/<br />
| title = <nowiki>Re: [Flightgear-devel] flight recorder time limit</nowiki><br />
| author = <nowiki>James Turner</nowiki><br />
| date = Feb 21st, 2016<br />
| added = Feb 21st, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
[Something similar to this is on next - see above.]<br />
<br />
* [[Howto:Record, analyze and replay multiplayer flights with network tools]]<br />
* [[Redesigning the Replay System]]<br />
<br />
=== Forum topics ===<br />
* {{forum link|p=373973|title=Re: How to start an A320 on approach with engines running?}} - Starting FlightGear with the <code>--load-tape</code> option, for example for approach training.<br />
<br />
=== Readme file ===<br />
* {{flightgear source |path=docs-mini/README-recordings.md}} (Description of Normal and Continuous recordings, up to date as of 2021-10-10.)<br />
* {{readme file|flightrecorder}} (Detailed description of Normal recordings, last modified 2013-06-20.)<br />
<br />
=== Source code ===<br />
* {{fgdata source|path=Aircraft/Generic/flightrecorder/}} - Generic flight recorder configuration files.<br />
<br />
* {{flightgear source|path=src/Aircraft/replay.hxx}}<br />
* {{flightgear source|path=src/Aircraft/replay.cxx}}<br />
<br />
[[Category:FlightGear feature]]<br />
[[Category:Menubar]]</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=YASim&diff=134780YASim2022-03-13T12:59:33Z<p>Cgdae: Added note about alignment checking with Blender and top-level 'loc <x> <y> <z>' specification.</p>
<hr />
<div>[[File:yasimlogo.png|thumb]] <br />
<br />
'''YASim''' is one of two [[flight dynamics model]]s commonly used in [[FlightGear]]. The flight dynamics model (FDM) determines how the [[aircraft]] moves and flies.<br />
<br />
Gary Neely wrote in his [http://www.buckarooshangar.com/flightgear/ introduction to YASim]:<br />
<br />
:''The FDM is the mathematical model that controls the physics of flight within the simulator. The physical 3D aircraft model has nothing to do with flight dynamics-- in essence it's just a picture to look at. It's the FDM that dictates how the model flies.''<br />
<br />
:''Why YASim? YASim uses the geometry of the aircraft to generate the base flight characteristics. While this suggests a 'realistic' or out-of-the-box approach, it is a only rough approximation that will require much tweaking before you get a result that approaches realism. If you have solid flight data for your aircraft such as wind-tunnel data or you are looking to eventually generate a hyper-realistic simulation, JSBSim is probably a better approach. If you lack such data but know the geometry of the aircraft and have access to the same flight characteristics and limits as a real pilot would, then YASim can provide a solution that is more than sufficient for most simulation needs.''<br />
<br />
== Coordinate system notes ==<br />
All positions specified are in metres (which is weird, since all other units in the file are English). The X axis points forward, Y is left, and Z is up. Take your right hand, and hold it like a gun. Your first and second fingers are the X and Y axes, and your upwards-pointing thumb is the Z. This is slightly different from the coordinate system used by [[JSBSim]]. Sorry. The origin can be placed anywhere, so long as you are consistent. I use the nose of the aircraft.<br />
<br />
(In the [[JSBSim_Aerodynamics#Frames|JSBSim coordinate system]], X and Z are the same as in YASim, but Y points to the right instead of left.)<br />
<br />
=== Checking alignment with Blender ===<br />
<br />
Blender can display a '''.ac''' model and a yasim model at the same time, allowing one to check whether the wings, gear contact points etc are aligned correctly. But it seems that Blender ignores any top-level <code>loc <x> <y> <z></code> specification in the '''.ac''' file, which makes it non-trivial to check alignment if such a specification is used.<br />
<br />
== YASim design notes ==<br />
Andy Ross's original design notes for YASim can be found in [https://pdfhost.io/v/~iYsLl7xS_alldvi.pdf this PDF file]. These provide some useful background for how YASim works.<br />
<br />
== XML Elements ==<br />
<!-- To future editors: The all lowercase headings are XML tags and should ''probably'' be left that way --><br />
=== airplane ===<br />
The top-level element for the file. It contains the following attributes: <br />
* '''mass:''' The empty (no fuel) weight, in pounds. It does include the weight of the engine(s), so when you add the engine weight in its tag, it acts just like a ballast.<br />
* '''version:''' The version attribute is used to maintain compatibility when updating yasim (e.g. bugfixes). If this attribute i not given, the original version will be used. Several bugfixes to YASim were implemented in FlightGear 3.2 (see [[FlightGear Newsletter April 2014]]), some more are fixed in FlightGear 2017.2. <br />
Available versions are:<br />
* <code>YASIM_VERSION_ORIGINAL</code> explicitly use the old buggy calculations (same as no version attribute at all)<br />
* <code>YASIM_VERSION_32</code> enable bugfixes up to version 3.2<br />
* <code>2017.2</code> enable bugfixes up to version 2017.2<br />
* <code>2018.1</code> (FIXME) no bugfixes by now. Use this version if your aircraft makes use of new features in YASim 2018.1 so it will cause at least a warning with older FG versions. <br />
* <code>YASIM_VERSION_CURRENT</code> use latest version compiled into the users FlightGear. <br />
{{Warning| Using YASIM_VERSION_CURRENT might make the aircraft unusable in case of future changes to YASim without updating the aircraft accordingly.}}<br />
<br />
'''New in 2018.1'''<br />
* '''mtow-lbs''' and '''mtow-kg:''' use one of them to specify max. takeoff weight. Does not affect the FDM, but is used by CLI tool to calculate some numbers.<br />
<br />
=== approach ===<br />
The approach parameters for the aircraft. The solver will generate an aircraft that matches these settings (by adjusting the parameters of the surface like drag and lift). It is extremely important to give parameters which could be really achieved by defined aircraft geometry, otherwise, it gives an unstable or not flyable result. The element can (and should) contain <control> elements indicating pilot input settings, such as flaps and throttle, for the approach.<br />
<br />
* '''speed:''' The approach airspeed, in knots TAS.<br />
* '''aoa:''' The approach angle of attack, in degrees<br />
* '''fuel:''' Fraction (0-1) of fuel in the tanks. Default is 0.2.<br />
<br />
=== cruise ===<br />
The cruise speed and altitude for the solver to match. As above, this should contain <control> elements indicating aircraft configuration. Especially, make sure the engines are generating enough thrust at cruise!<br />
* '''speed:''' The cruise speed, in knots TAS.<br />
* '''alt:''' The cruise altitude, in feet MSL.<br />
* '''fuel:''' Fraction (0-1) of fuel in the tanks. Default is 0.2.<br />
=== cockpit ===<br />
The location of the cockpit (pilot eyepoint).<br />
* '''x,y,z:''' eyepoint location (see coordinates note)<br />
<br />
=== fuselage ===<br />
This defines a tubelike structure. It will be given an even mass and aerodynamic force distribution by the solver. You can have as many as you like, in any orientation you please.<br />
* '''ax,ay,az:''' One end of the tube (typically the front)<br />
* '''bx,by,bz:''' The other ("back") end.<br />
* '''width:''' The width of the tube, in metres.<br />
* '''taper:''' The approximate radius at the "tips" of the fuselage expressed as a fraction (0-1) of the width value.<br />
* '''midpoint:''' The location of the widest part of the fuselage, expressed as a fraction of the distance between A and B.<br />
* '''idrag:''' Multiplier for the "induced drag" generated by this object. Default is one. With idrag=0 the fuselage generates only drag.<br />
* '''cx,cy,cz:''' Factors for the generated drag in the fuselages "local coordinate system" with x pointing from end to front, z perpendicular to x with y=0 in the aircraft coordinate system. E.g. for a fuselage of a height of 2 times the width you can define cy=2 and (due to the doubled front surface) cx=2.<br />
<br />
=== Surfaces ===<br />
==== wing ====<br />
This defines the main wing of the aircraft. You can have only one (but see below about using vstab objects for extra lifting surfaces). The wing should have a <stall> subelement to indicate stall behavior, control surface subelements (flap0, flap1, spoiler, slat) to indicate what and where the control surfaces are, and <control> subelements to map user input properties to the control surfaces.<br />
* '''x,y,z:''' The "base" of the wing, specified as the location of the mid-chord (not leading edge, trailing edge, or aerodynamic center) point at the root of the LEFT (!) wing.<br />
* '''length:''' The length from the midchord point of the base of the wing to the midchord point at the tip. Note that this is not the same thing as span.<br />
* '''chord:''' The chord of the wing at its base, along the X axis (not normal to the leading edge, as it is sometimes defined).<br />
* '''incidence:''' The incidence angle at the wing root, in degrees. Zero is level with the fuselage (as in an aerobatic plane), positive means that the leading edge is higher than the trailing edge (as in a trainer).<br />
* '''twist:''' The difference between the incidence angle at the wing root and the incidence angle at the wing tip. Typically, this is a negative number so that the wing tips have a lower angle of attack and stall after the wing root (washout).<br />
* '''taper:''' The taper fraction, expressed as the tip chord divided by the root chord. A taper of one is a hershey bar wing, and zero would be a wing ending at a point. Defaults to one.<br />
* '''sweep:''' The sweep angle of the wing, in degrees. Zero is no sweep, positive angles are swept back. Defaults to zero. [This looks to be the sweep of the mid-chord of the wing, not the sweep of the leading edge.]<br />
* '''dihedral:''' The dihedral angle of the wing. Positive angles are upward dihedral. Defaults to zero.<br />
* '''idrag:''' Multiplier for the "induced drag" generated by this surface. In general, low aspect wings will generate less induced drag per-AoA than high aspect (glider) wings. This value isn't constrained well by the solution process, and may require tuning to get throttle settings correct in high AoA (approach) situations.<br />
* '''effectiveness:''' Multiplier for the "normal" drag generated by the wing. Defaults to 1. Arbitrary, dimensionless factor. <br />
* '''camber:''' The lift produced by the wing at zero angle of attack, expressed as a fraction of the maximum lift produced at the stall AoA.<br />
* '''flow:''' The flow regime for the wing. Valid values are "SUBSONIC" (default) and "TRANSONIC". Setting surface to transonic adds more lift above mach number 0.6 by applying a Prandl/Glauert correction term to each surface-element. The effect is a more balanced lift/drag distribution reported by the solver. Use for anything that flies faster than mach 0.6 or has supercritical airfoils.<br />
* '''mcrit:''' The critical mach number for the wing. This point defines the begin of exponential drag rise due to mach speed. Default "0.6", only available if flow="TRANSONIC".<br />
<br />
'''Wing section support (since 2018.1):'''<br />
<br />
Wing section support to define variable geometry (geometry parameters per section)<br />
* More than one <wing>-element is allowed now. <br />
* x, y, z, chord and incidence attribute shall be specifed only for the first <wing> in the XML file. They will be overridden for subsequent <wing>-elements.<br />
* Use '''append="1"''' for additional '''wing''' elements to skip x, y, z, chord and incidence attribute as the will be calculated from previous '''wing''' element tip chord. This workaround is currently needed due to limitations in the XML parser.<br />
<br />
==== hstab ====<br />
These define the horizontal stabilizer of the aircraft. Internally, it is just a wing object and therefore works the same in XML. <br />
You are allowed only one hstab object; the solver needs to know which wing's incidence to play with to get the aircraft trimmed correctly.<br />
<br />
'''New in 2018.1:'''<br />
* '''hstab''' supports sections in the same way '''wing''' does, but it is still considered as /the/ (only) hstab used by the solver.<br />
* '''incidence-min-deg''' and '''incidence-max-deg''': optional attributes to limit valid result range fore the solver. Use with care or you won't get a solution.<br />
<br />
==== vstab ====<br />
A "vertical" stabilizer. Like hstab, this is just another wing, with a few special properties. The surface is not "mirrored" as are wing and hstab objects. If you define a left wing only, you'll only get a left wing. The default dihedral, if unspecified, is 90 degrees instead of zero. But all parameters are equally settable, so there's no requirement that this object be "vertical" at all. You can use it for anything you like, such as extra wings for biplanes. Most importantly, these surfaces are not involved with the solver computation, so you can have none, or as many as you like.<br />
<br />
==== mstab ====<br />
A mirrored horizontal stabilizer. Exactly the same as wing, but not involved with the solver computation, so you can have none, or as many as you like.<br />
<br />
==== stall ====<br />
A subelement of a wing (or hstab/vstab/mstab) that specifies the stall behavior.<br />
* '''aoa:''' The stall angle (maximum lift) in degrees. Note that this is relative to the wing, not the fuselage (since the wing may have a non-zero incidence angle).<br />
* '''width:''' The "width" of the stall, in degrees. A high value indicates a gentle stall. Low values are viscious for a non-twisted wing, but are acceptable for a twisted one (since the whole wing will not stall at the same time).<br />
* '''peak:''' The height of the lift peak, relative to the post-stall secondary lift peak at 45 degrees. Defaults to 1.5. This one is deep voodoo, and probably doesn't need to change much. Bug me for an explanation if you're curious.<br />
<br />
==== flap0, flap1, slat, spoiler ====<br />
These are subelements of wing/hstab/vstab objects, and specify the location and effectiveness of the control surfaces.<br />
* '''start:''' The position along the wing where the control surface begins.Zero is the root, one is the tip.<br />
* '''end:''' The position where the surface ends, as above.<br />
* '''lift:''' The lift multiplier for a flap or slat at full extension. One is a no-op, a typical aileron might be 1.2 or so, a giant jetliner flap 2.0, and a spoiler 0.0. For spoilers, the interpretation is a little different -- they spoil only "prestall" lift. Lift due purely to "flat plate" effects isn't affected. For typical wings that stall at low AoA's essentially all lift is pre-stall and you don't have to care. Jet fighters tend not to have wing spoilers, for exactly this reason. This value is not applicable to slats, which affect stall AoA only.<br />
* '''drag:''' The drag multiplier, as above. Typically should be higher than the lift multiplier for flaps.<br />
* '''aoa:''' Applicable only to slats. This indicates the angle by which the stall AoA is translated by the slat extension.<br />
<br />
=== Rotor and rotorgear ===<br />
YASim has also possibility to simulate rotorcraft blades. The number properties of rotor elements are large therefore are spitted to the separate page [[Howto:Make a helicopter#XML%20Elements|howto make a helicopter in YASim]].<br />
<br />
=== Engine ===<br />
==== Thruster ====<br />
A very simple "thrust only" engine object. Useful for things like thrust vectoring nozzles. All it does is map its THROTTLE input axis to its output thrust rating. Does not consume fuel, etc...<br />
* '''thrust:''' Maximum thrust in pounds<br />
* '''x,y,z:''' The point on the airframe where thrust will be applied.<br />
* '''vx,vy,vy:''' The direction of the thrust in airframe coordinates. The vector will be normalized automatically, so any non-zero vector will work fine.<br />
<br />
Example: <br />
<br />
<syntaxhighlight lang="xml" line><br />
<thruster x="0" y="0" z="0.03" vx="1" vy="0" vz="0" thrust="6.61"><br />
<control-input axis="/controls/engines/engine[0]/throttle" control="THROTTLE" src0="-1" src1="1" dst0="-1" dst1="1"/><br />
</thruster><br />
</syntaxhighlight><br />
<br />
==== Jet ====<br />
A turbojet/fan engine. It accepts a <control> subelement to map a property to its throttle setting, and an <actionpt> subelement to place the action point of the thrust at a different position than the mass of the engine.<br />
* '''x,y,z:''' The location of the engine, as a point mass. If no actionpt is specified, this will also be the point of application of thrust.<br />
* '''mass:''' The mass of the engine, in pounds.<br />
* '''thrust:''' The maximum sea-level thrust, in pounds.<br />
* '''afterburner:''' Maximum total thrust with afterburner/reheat, in pounds [defaults to "no additional thrust"].<br />
* '''rotate:''' Vector angle of the thrust in degrees about the Y axis [0].<br />
* '''n1-idle:''' Idling low pressure core / fan speed [55]. <br />
* '''n1-max:''' Maximum low pressure core / fan speed [102].<br />
* '''n2-idle:''' Idling high pressure core speed [73].<br />
* '''n2-max:''' Maximum high pressure core speed [103].<br />
* '''tsfc:''' Thrust-specific fuel consumption [0.8]. This should be considerably lower for modern turbofans.<br />
* '''atsfc:''' (version >= 2016.3.1) Thrust specific fuel consumption with afterburner on. When set to zero defaults to older behaviour where it is calculated from dry fuel consumption [0].<br />
* '''egt:''' Exhaust gas temperature at takeoff in K [1050].<br />
* '''epr:''' Engine pressure ratio at takeoff [3.0].<br />
* '''exhaust-speed:''' The maximum exhaust speed in knots [~1555].<br />
* '''spool-time:''' Time, in seconds, for the engine to respond to 90% of a commanded powersetting.<br />
<br />
==== Propeller ====<br />
A propeller. This element requires an engine subtag. Currently <piston-engine> and <turbine-engine> are supported.<br />
* '''x,y,z:''' The position of the mass (!) of the engine/propeller combination. If the point of force application is different (and it will be) it should be set with an <actionpt> subelement.<br />
* '''mass:''' The mass of the engine/propeller, in pounds.<br />
* '''moment:''' The moment, in kg-metres^2. This has to be hand calculated and guessed at for now. A more automated system will be forthcoming. Use a negative moment value for counter-rotating ("European" -- CCW as seen from behind the prop) propellers. A good guess for this value is the radius of the prop (in meters) squared times the mass (kg) divided by three; that is the moment of a plain "stick" bolted to the prop shaft.<br />
* '''radius:''' The radius, in meters, or the propeller.<br />
* '''cruise-speed:''' The max efficiency cruise speed of the propeller. Generally not the same as the aircraft's cruise speed.<br />
* '''cruise-rpm:''' The RPM of the propeller at max-eff. cruise.<br />
* '''cruise-power:''' The power sunk by the prop at cruise, in horsepower.<br />
* '''cruise-alt:''' The reference cruise altitude in feet.<br />
* '''takeoff-power:''' The takeoff power required by the propeller...<br />
* '''takeoff-rpm:''' ...at the given takeoff RPM.<br />
* '''gear-ratio:''' The factor by which the engine RPM is multiplied to produce the propeller RPM. Optional (defaults to 1.0).<br />
* '''contra:''' When set (contra="1"), this indicates that the propeller is a contra-rotating pair. It will not contribute to the aircraft's net gyroscopic moment, nor will it produce asymmetric torque on the aircraft body. Asymmetric slipstream effects, when implemented, will also be zero when this is set.<br />
<br />
<br />
YASim assumes a fixed-pitch propeller by default. If your engine is using a constant-speed propeller, you'll also need to provide these attributes:<br />
<br />
* '''min-rpm:''' The minimum operational RPM for a constant speed propeller. This is the speed to which the prop governor will seek when the blue lever is at a minimum. The coarse-stop attribute limits how far the governor can go into trying to reach this RPM.<br />
* '''max-rpm:''' The maximum operational RPM for a constant speed propeller. See above. The fine-stop attribute limits how far the governor can go in trying to reach this RPM.<br />
* '''fine-stop:''' The minimum pitch of the propeller (high RPM) as a ratio of ideal cruise pitch. This is set to 0.25 by default -- a higher value will result in a lower RPM at low power settings (e.g. idle, taxi, and approach).<br />
* '''coarse-stop:''' The maximum pitch of the propeller (low RPM) as a ratio of ideal cruise pitch. This is set to 4.0 by default -- a lower value may result in a higher RPM at high power settings.<br />
<br />
<br />
===== piston-engine =====<br />
<br />
A piston engine definition. This must be a subelement of an enclosing <propeller> tag.<br />
<br />
* '''eng-power:''' Maximum BHP of the engine at sea level.<br />
* '''eng-rpm:''' The engine RPM at which eng-power is developed<br />
* '''displacement:''' The engine displacement in cubic inches.<br />
* '''compression:''' The engine compression ratio.<br />
<br />
<syntaxhighlight lang="xml" line><br />
<piston-engine eng-power="2" eng-rpm="3800" displacement="20" ><br />
<control-input axis="/controls/engines/engine[0]/throttle" control="THROTTLE"/><br />
<control-input axis="/controls/engines/engine[0]/starter" control="STARTER"/><br />
<control-input axis="/controls/engines/engine[0]/magnetos" control="MAGNETOS"/><br />
<control-input axis="/controls/engines/engine[0]/mixture" control="MIXTURE"/><br />
</piston-engine><br />
</syntaxhighlight><br />
<br />
===== electric-engine =====<br />
<br />
A simplified electric DC engine model. The model is available since the end of April 2020, therefore it is currently available in daily build FlightGear snapshots. This definition must be a subelement of an enclosing <propeller> tag.<br />
<br />
* '''Kv''' electric engine constant in revolutions per minute to volt. <br />
* '''voltage''' The voltage applied to the motor e.g. Nominal battery voltage in Volts. <br />
* '''Rm''' The engine winding resistance in Ohms.<br />
<br />
<br />
Example:<br />
<br />
<syntaxhighlight lang="xml" line><br />
<propeller x="0.02" y="0" z="0.03"<br />
mass="0.05"<br />
moment="0.0006"<br />
radius="0.203"<br />
cruise-speed="26"<br />
cruise-rpm="7000"<br />
cruise-power="0.5"<br />
cruise-alt="2000"<br />
takeoff-power="0.70"<br />
takeoff-rpm="9200"<br />
contra="1"><br />
<actionpt x="0" y="0" z="0.03"/><br />
<electric-engine Kv="750" voltage="15" Rm="0.02" ><br />
<control-input axis="/controls/engines/engine[0]/throttle" control="THROTTLE"/><br />
</electric-engine><br />
</propeller><br />
</syntaxhighlight><br />
<br />
=== Landing gear ===<br />
==== gear ====<br />
Defines a landing gear. Accepts <control> subelements to map properties to steering and braking. Can also be used to simulate floats. Although the coefficients are still called ..fric, it is calculated in fluids as a drag (proportional to the square of the speed). In fluids gears are not considered to detect crashes (as on ground). <br />
* '''x,y,z:''' The location of the fully-extended gear tip.<br />
* '''compression:''' The distance in metres along the "up" axis that the gear will compress.<br />
* '''initial-load:''' The initial load of the spring in multiples of compression. Defaults to 0. (With this parameter a lower spring-constants will be used for the gear-> can reduce numerical problems (jitter)) '''Note:''' the spring-constant is varied from 0% compression to 20% compression to get continuous behavior around 0 compression. (could be physically explained by wheel deformation)<br />
* '''upx/upy/upz:''' The direction of compression, defaults to vertical (0,0,1) if unspecified. These are used only for a direction -- the vector need not be normalized, as the length is specified by "compression".<br />
* '''sfric:''' Static (non-skidding) coefficient of friction. Defaults to 0.8.<br />
* '''dfric:''' Dynamic friction. Defaults to 0.7.<br />
* '''stiction:''' Stiction to ground. Defaults to 0. stiction = "1" ensures the gear isn't sliding unintentionally (Note: please correct docu here for more detailed facts, developers didn't document this extension here and this is based on trial and guessing only)<br />
* '''spring:''' A dimensionless multiplier for the automatically generated spring constant. Increase to make the gear stiffer, decrease to make it squishier.<br />
* '''damp:''' A dimensionless multiplier for the automatically generated damping coefficient. Decrease to make the gear "bouncier", increase to make it "slower". Beware of increasing this too far: very high damping forces can make the numerics unstable. If you can't make the gear stop bouncing with this number, try increasing the compression length instead.<br />
* '''on-water:''' if this is set to "0" the gear will be ignored if on water. Defaults to "0"<br />
* '''on-solid:''' if this set to "0" the gear will be ignored if not on water. Defaults to "1"<br />
* '''speed-planing:'''<br />
* '''spring-factor-not-planing:''' At zero speed the spring factor is multiplied by spring-factor-not-planing. Above speed-planing this factor is equal to 1. The idea is, to use this for floats simulating the transition from swimming to planing. speed-planing defaults to 0, spring-factor-not-planing defaults to 1.<br />
* '''reduce-friction-by-extension:''' at full extension the friction is reduced by this relative value. 0.7 means 30% friction at full extension. If you specify a value greater than one, the friction will be zero before reaching full extension. Defaults to "0"<br />
* '''ignored-by-solver:''' with the on-water/on-solid tags you can have more than one set of gears in one aircraft, If the solver (who automatically generates the spring constants) would take all gears into account, the result would be wrong. E. G. set this tag to "1" for all gears, which are not active on runways. Defaults to "0". You can not exclude all gears in the solving process.<br />
<br />
<br />
<syntaxhighlight lang="xml" line><br />
<!-- front gear --><br />
<br />
<gear x="0.0" y="0.0" z="-0.205"<br />
spring="0.9"<br />
damp="0.8"<br />
dfric="0.9"<br />
sfric="1.1"<br />
compression="0.051"><br />
<control-input axis="/controls/flight/rudder" control="STEER" square="true" src0="-1.0" src1="1.0" dst0="-0.3" dst1="0.3"/><br />
<control-input axis="/controls/gear/brake-right" control="BRAKE" split="true"/><br />
<control-input axis="/controls/gear/brake-parking" control="BRAKE" split="true"/><br />
</gear><br />
<br />
<!-- two rear gears --><br />
<br />
<gear x="-0.4" y="0.25" z="-0.205"<br />
spring="0.9"<br />
damp="0.8"<br />
dfric="0.9"<br />
sfric="1.1"<br />
compression="0.051"><br />
<control-input axis="/controls/gear/brake-right" control="BRAKE" split="true"/><br />
<control-input axis="/controls/gear/brake-parking" control="BRAKE" split="true"/><br />
</gear><br />
<br />
<gear x="-0.4" y="-0.25" z="-0.205"<br />
spring="0.9"<br />
damp="0.8"<br />
dfric="0.9"<br />
sfric="1.1"<br />
compression="0.051"><br />
<control-input axis="/controls/gear/brake-left" control="BRAKE" split="true"/><br />
<control-input axis="/controls/gear/brake-parking" control="BRAKE" split="true"/><br />
</gear><br />
</syntaxhighlight><br />
<br />
==== Launchbar ====<br />
Defines a catapult launchbar or strop.<br />
* '''x,y,z:''' The location of the mount point of the launch bar or strop on the aircraft.<br />
* '''length:''' The length of the launch bar from mount point to tip<br />
* '''down-angle:''' The max angle below the horizontal the launchbar can achieve.<br />
* '''up-angle:''' The max angle above the horizontal the launchbar can achieve.<br />
* '''holdback-{x,y,z}:''' The location of the holdback mount point on the aircraft.<br />
* '''holdback-length:''' The length of the holdback from mount point to tip. Note: holdback up-angle and down-angle are the same as those defined for the launchbar and are not specified in the configuration.<br />
<br />
=== Fuel ===<br />
==== tank ====<br />
A fuel tank. Tanks in the aircraft are identified numerically (starting from zero), in the order they are defined in the file. If the left tank is first, "tank[0]" will be the left tank. <br />
* '''x,y,z:''' The location of the tank.<br />
* '''capacity:''' The maximum contents of the tank, in pounds. Not gallons -- YASim supports fuels of varying densities.<br />
* '''jet:''' A boolean. If present, this causes the fuel density to be treated as Jet-A. Otherwise, gasoline density is used. A more elaborate density setting (in pounds per gallon, for example) would be easy to implement. Bug me.<br />
<br />
=== Center of Gravity ===<br />
==== Ballast ====<br />
This is a mechanism for modifying the mass distribution of the aircraft. A ballast setting specifies that a particular amount of the empty weight of the aircraft must be placed at a given location. The remaining non-ballast weight will be distributed "intelligently" across the fuselage and wing objects. Note again: this does NOT change the empty weight of the aircraft. <br />
* '''x,y,z:''' The location of the ballast.<br />
* '''mass:''' How much mass, in pounds, to put there. Note that this value can be negative. I find that I often need to "lighten" the tail of the aircraft.<br />
<br />
<br />
<syntaxhighlight lang="xml" line><br />
<ballast x="-0.24" y="0.0" z="0.33" mass-kg="0.5"/><br />
</syntaxhighlight><br />
<br />
==== Weight ====<br />
This is an added weight, something not part of the empty weight of the aircraft, like passengers, cargo, or external stores. The actual value of the mass is not specified here, instead, a mapping to a property is used. This allows external code, such as the panel, to control the weight (loading a given cargo configuration from preference files, dropping bombs at runtime, etc...)<br />
* '''x,y,z:''' The location of the weight.<br />
* '''mass-prop:''' The name of the fgfs property containing the mass, in pounds, of this weight.<br />
* '''size:''' The aerodynamic "size", in metres, of the object. This is important for external stores, which will cause drag. For reasonably aerodynamic stuff like bombs, the size should be roughly the width of the object. For other stuff, you're on your own. The default is zero, which results in no aerodynamic force (internal cargo).<br />
* '''solve-weight:''' Subtag of approach and cruise parameters. Used to specify a non-zero setting for a <weight> tag during solution. The default is to assume all weights are zero at the given performance numbers.<br />
* '''idx:''' Index of the weight in the file (starting with zero).<br />
* '''weight:''' Weight setting in pounds.<br />
<br />
<syntaxhighlight lang="xml" line><br />
<weight x="-0.06471" y="0.225" z="-0.2" mass-prop="/sim/weight[0]/weight-kg"/><br />
</syntaxhighlight><br />
<br />
=== Controls ===<br />
==== control-input ====<br />
This element manages a mapping from fgfs properties (user input) to settable values on the aircraft's objects. Note that the value to be set MUST (!) be valid on the given object type. This is not checked for by the parser, and will cause a runtime crash if you try it. Wing's don't have throttle controls, etc... Note that multiple axes may be set on the same value. They are summed before setting.<br />
* '''axis:''' The name of the double-valued fgfs property "axis" to use as input, such as "/controls/flight/aileron".<br />
* '''control:''' Which control axis to set on the objects. It can have the following values:<br />
** THROTTLE - The throttle on a jet or propeller. <br />
** MIXTURE - The mixture on a propeller.<br />
** REHEAT - The afterburner on a jet<br />
** PROP - The propeller advance<br />
** BRAKE - The brake on a gear.<br />
** STEER - The steering angle on a gear. <br />
** INCIDENCE - The incidence angle of a wing.<br />
** FLAP0 - The flap0 deflection of a wing. <br />
** FLAP1 - The flap1 deflection of a wing. <br />
** SLAT - The slat extension of a wing. <br />
** SPOILER - The spoiler extension for a wing. <br />
** CYCLICAIL - The "aileron" cyclic input of a rotor <br />
** CYCLICELE - The "elevator" cyclic input of a rotor <br />
** COLLECTIVE - The collective input of a rotor<br />
** ROTORENGINEON - If not equal zero the rotor is rotating <br />
** WINCHRELSPEED - The relative winch speed <br />
** {... and many more, see [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/FDM/YASim/ControlMap.cpp#l25 ControlMap.cpp] ...}<br />
* '''invert:''' Negate the value of the property before settling on the object.<br />
* '''split:''' Applicable to wing control surfaces. Sets the normal value on the left-wing, and a negated value on the right-wing.<br />
* '''square:''' Squares the value before setting. Useful for controls like a steering that needs a wide range, yet lots of sensitivity in the center. Obviously only applicable to values that have a range of [-1:1] or [0:1]. <br />
* '''src0/src1/dst0/dst1:''' If present, these define a linear mapping from the source to the output value. Input values in the range src0-src1 are mapped linearly to dst0-dst1, with clamping for input values that lie outside the range.<br />
<br />
==== control-output ====<br />
This can be used to pass the value of a YASim control axis (after all mapping and summing is applied) back to the property tree.<br />
* '''control:''' Name of the control axis. See above.<br />
* '''prop:''' Property node to receive the value.<br />
* '''side:''' Optional, for split controls. Either "right" or "left" <br />
* '''min/max:''' Clamping applied to output value.<br />
<br />
==== control-speed ====<br />
Some controls (most notably flaps and hydraulics) have maximum slew rates and cannot respond instantly to pilot input. This can be implemented with a control-speed tag, which defines a "transition time" required to slew through the full input range. Note that this tag is semi-deprecated, complicated control input filtering can be done much more robustly from a Nasal script.<br />
* '''control:''' Name of the control axis. See above.<br />
* '''transition-time:''' Time in seconds to slew through input range.<br />
<br />
==== control-setting ====<br />
This tag is used to define a particular setting for a control axis inside the <cruise> or <approach> tags, where obviously property input is not available. It can be used, for example, to inform the solver that the approach performance values assume full flaps, etc...<br />
* '''axis:''' Name of the control input (i.e. a property name)<br />
* '''value:''' Value of the control axis.<br />
<br />
=== Winch and Aerotow ===<br />
==== hitch ====<br />
A hitch, can be used for winch-start (in gliders) or aerotow (in gliders and motor aircraft) or for external cargo with helicopter. You can do aerotow over the net via multiplayer (see j3 and bocian as an example).<br />
* '''name:''' the name of the hitch. must be aerotow if you want to do aerotow via multiplayer. You will find many properties at /sim/hitches/name. Most of them are directly tied to the internal variables, you can modify them as you like. You can add a listener to the property "broken", e. g. for playing a sound.<br />
* '''x,y,z:''' The position of the hitch<br />
* '''force-is-calculated-by-other:''' if you want to simulate aerotowing over the internet, set this value to "1" in the motor aircraft. Don't specify or set this to zero in gliders. In a LAN the time lag might be small enough to set it on both aircraft to "0". It's intended, that this is done automatically in the future.<br />
==== tow ====<br />
The tow used for aerotow or winch. This must be a subelement of an enclosing <hitch> tag.<br />
* '''length:''' upstretched length in metres<br />
* '''weight-per-meter:''' in kg/metre<br />
* '''elastic-constant:''' lower values give higher elasticity<br />
* '''break-force:''' in N<br />
* '''mp-auto-connect-period:''' the every x seconds a towed multiplayer aircraft is searched. If found, this tow is connected automatically, parameters are copied from the other aircraft. Should be set only in the motor aircraft, not in the glider<br />
==== winch ====<br />
The tow used for aerotow or winch. This must be a subelement of an enclosing <hitch> tag.<br />
* '''max-tow-length:''' in m<br />
* '''min-tow-length''': in m<br />
* '''initial-tow-length:''' in m. The initial tow length also defines the length/search radius used for the mp-autoconnect feature<br />
* '''max-winch-speed:''' in m/s<br />
* '''power:''' in kW<br />
* '''max-force:''' in N<br />
<br />
<br />
<syntaxhighlight lang="xml" line><br />
<hitch name="winch" x="0.0" y="0.0" z="0.0"><br />
<tow length="50" weight-per-meter="0.0035" elastic-constant="40000" break-force="10000"/><br />
<!-- 3mm paracord--><br />
<winch max-tow-length="1000" min-tow-length="1" initial-tow-length="1000" max-winch-speed="20" power="2" max-force="80"/><br />
<control-input axis="/controls/winch/place" control="PLACEWINCH"/><br />
</hitch><br />
<hitch name="aerotow" x="0.0" y="0.0" z="0.0" force-is-calculated-by-other="0"><br />
<tow length="60" weight-per-meter="0.0035" elastic-constant="9000" break-force="100" mp-auto-connect-period="0.0"/><br />
<winch max-tow-length="1000" min-tow-length="60" initial-tow-length="60"/><br />
<control-input axis="/controls/aerotow/find-aircraft" control="FINDAITOW"/><br />
</hitch><br />
</syntaxhighlight><br />
<br />
== Visualization ==<br />
<br />
=== Blender visualization tool ===<br />
<br />
[[File:Yasim_visualisation_dc6.png|thumb|dc6 FDM in Blender]]To make the programmed aircraft visible it is possible to load and compare it with the 3D model within [[Blender]]. They applaud for this ''very'' useful script goes to M. Franz, thank you very much!<br />
<br />
For Blender versions <= 2.4 the script is located in FlightGears source code {{flightgear file|utils/Modeller/yasim_import.py}}.<br />
<br />
For Blender versions newer than 2.4, please see [[Blender YASim import]].<br />
<br />
The howto, taken from inside the script:<br />
<br />
yasim_import.py loads and visualizes a YASim FDM geometry<br />
=========================================================<br />
<br />
It is recommended to load the model superimposed over a greyed out and immutable copy of the aircraft model:<br />
<br />
(0) put this script into ~/.blender/scripts/<br />
(1) load or import aircraft model (menu -> "File" -> "Import" -> "AC3D (.ac) ...")<br />
(2) create new *empty* scene (menu -> arrow button left of "SCE:scene1" combobox -> "ADD NEW" -> "empty")<br />
(3) rename scene to yasim (not required)<br />
(4) link to scene1 (F10 -> "Output" tab -> arrow button left of text entry "No Set Scene" -> "scene1")<br />
(5) now load the YASim config file (menu -> "File" -> "Import" -> "YASim (.xml) ...")<br />
<br />
This is good enough for simple checks. But if you are working on the YASim configuration, then you need a<br />
quick and convenient way to reload the file. In that case, continue after (4):<br />
<br />
(5) switch the button area at the bottom of the blender screen to "Scripts Window" mode (green python snake icon)<br />
(6) load the YASim config file (menu -> "Scripts" -> "Import" -> "YASim (.xml) ...")<br />
(7) make the "Scripts Window" area as small as possible by dragging the area separator down<br />
(8) optionally split the "3D View" area and switch the right part to the "Outliner"<br />
(9) press the "Reload YASim" button in the script area to reload the file<br />
<br />
<br />
If the 3D model is displaced with respect to the FDM model, then the <offsets> values from the<br />
model animation XML file should be added as comment to the YASim config file, as a line all by<br />
itself, with no spaces surrounding the equal signs. Spaces elsewhere are allowed. For example:<br />
<br />
<offsets><br />
<x-m>3.45</x-m><br />
<z-m>-0.4</z-m><br />
<pitch-deg>5</pitch-deg><br />
</offsets><br />
<br />
becomes:<br />
<br />
<!-- offsets: x=3.45 z=-0.4 p=5 --><br />
<br />
Possible variables are:<br />
<br />
x ... <x-m><br />
y ... <y-m><br />
z ... <z-m><br />
h ... <heading-deg><br />
p ... <pitch-deg><br />
r ... <roll-deg><br />
<br />
Of course, absolute FDM coordinates can then no longer directly be read from Blender's 3D view.<br />
The cursor coordinates display in the script area, however, shows the coordinates in YASim space.<br />
Note that object names don't contain XML indices but element numbers. YASim_hstab#2 is the third<br />
hstab in the whole file, not necessarily in its parent XML group. A floating-point part in the<br />
object name (e.g. YASim_hstab#2.004) only means that the geometry has been reloaded that often.<br />
It's an unavoidable consequence of how Blender deals with meshes.<br />
<br />
<br />
Elements are displayed as follows:<br />
<br />
cockpit -> monkey head<br />
fuselage -> blue "tube" (with only 12 sides for less clutter); center at "a"<br />
vstab -> red with yellow flaps<br />
wing/mstab/hstab -> green with yellow flaps/spoilers/slats (always 20 cm deep);<br />
symmetric surfaces are only displayed on the left side<br />
thrusters (jet/propeller/thruster) -> dashed line from center to actionpt;<br />
arrow from actionpt along thrust vector (always 1 m long);<br />
propeller circle<br />
rotor -> radius and rel_len_blade_start circle, direction arrow,<br />
normal and forward vector, one blade at phi0<br />
gear -> contact point and compression vector (no arrow head)<br />
tank -> cube (10 cm side length)<br />
weight -> inverted cone<br />
ballast -> cylinder<br />
hitch -> circle (10 cm diameter)<br />
hook -> dashed line for up angle, T-line for down angle<br />
launchbar -> dashed line for up angles, T-line for down angles<br />
A note about step (0) for Windows users: the mentioned path is inside the folder where Blender lives, something like <code>C:\Program Files\Blender Foundation\Blender\.blender\scripts</code>.<br />
<br />
=== Visualize model in OpenSCAD or FreeCAD ===<br />
<br />
There exist a possibility to display the YASim XML elements in the OpenSCAD or FreeCAD tools. This could be extremely useful in the case of UAV aircraft development. <br />
<br />
* [https://github.com/ThunderFly-aerospace/YASim2SCAD YASim2SCAD] - This tool converts YASim XML to scad file which could be displayed as an overlay in OpenSCAD or FreeCAD project.<br />
* [https://gitlab.com/yasimtoscad/yasimtoscad yasimtoscad] - Another tool to convert YASim XML to scad file which could be displayed as an overlay in OpenSCAD.<br />
<br />
<br />
=== Visualization tools ===<br />
<br />
* [https://github.com/bitwisetech/ysimi YSIMI] Interactive Tuning Tools for FlightGear's YASIM Flight Dynamics Model<br />
* [https://github.com/bitwisetech/yasiVers yasiVers] is a tool for visualization of YASim calculations.<br />
<br />
== Export of YASim internals to property tree ==<br />
Ever wondered what is going on inside yasim? See the property tree under /fdm/yasim/<br />
<br />
Some information is static and shows what yasim has compiled from your XML. <br />
Other information is "run-time" like forces, speed, acceleration, c.g. <br />
<br />
If note noted otherwise:<br />
* expect metric unit (meter, kilogram, newton, ...)<br />
* expect minimum version 2017.2<br />
<br />
{| class="wikitable"<br />
|-<br />
! Path !! Description !! Information type !! min. version<br />
|-<br />
| accelerations/ || linear and rot. accelerations in aircraft coord. || run time ||<br />
|-<br />
| debug/ || misc internals, for now subject to change without notice || run time || 2018.1<br />
|-<br />
| forces/ || aerodynamic forces in N || run time ||<br />
|-<br />
| velocities/ || linear and rot. velocities in aircraft coord. || run time ||<br />
|-<br />
| model/cg-x-range-aft || desired CG range || compile time ||<br />
|-<br />
| model/cg-x-range-front || desired CG range || compile time ||<br />
|-<br />
| model/cg-x-max || CG hard limit from gear position || compile time ||<br />
|-<br />
| model/cg-x-min || CG hard limit from gear position || compile time ||<br />
|-<br />
| model/masses || shows the calculated mass points || compile time ||<br />
|-<br />
| model/wings || wing parameters || compile time ||<br />
|}<br />
<br />
<br />
== Command Line ==<br />
=== Windows ===<br />
By using the standard command line, we can see what the YASim solver is calculating. First, open up Command Prompt, enter in the location of yasim.exe, and then the location of the YASim XML file. For example, here's what you would type in for a standard Windows [[Changelog_2.12|FlightGear 2.12.0]] installation, and viewing the [[F-14_Tomcat|F-14B's]] YASim file.<br />
{{Note|You can copy & paste the examples into Command Prompt by right-clicking on the title and navigate to Edit > Paste. Then, click Enter to execute.}} <br />
<br />
<code>"C:\Program Files\FlightGear\bin\Win32\yasim.exe" "C:\Program Files\FlightGear\data\Aircraft\f-14b\f-14b-yasim.xml"</code><br />
<br />
The results will give many different values.<br />
<br />
* '''Drag Coefficient:''' The drag coefficient of the aircraft.<br />
* '''Lift Ratio:''' The lift ratio of the aircraft.<br />
* '''Cruise AoA:''' The cruise AoA, from conditions at [[YASim#cruise|<cruise>]] in the xml file.<br />
* '''Tail Incidence:''' The incidence angle of the tail, "solved" by YASim as a way to stabilize the aircraft.<br />
* '''Approach Elevator:''' The approach elevator, from conditions at [[YASim#approach|<approach>]] in the xml file.<br />
* '''CG:''' Center of gravity of the aircraft in coordinates. Unless it's supposed to be offset, it should always have a Y value of 0.<br />
<br />
The YASim standalone solver also has some command line flags that change it's behaviour.<br />
<br />
<code>"C:\Program Files\FlightGear\bin\Win32\yasim.exe" "C:\Program Files\FlightGear\data\Aircraft\f-14b\f-14b-yasim.xml" -g -a 1000 -s 490</code><br />
<br />
* '''-g:''' Instructs YASim to generate space-separated tabular data instead of the usual solver output. This can be redirected to a file and used in various plotting programs to visualize the actual lift, drag, L/D curves. The columns of the output from left to right are: AoA, Lift, Drag, L/D. (aoa in degrees, lift and drag in G's).<br />
* '''-a <altitude in meter:>''' Run the solver at the given altitude in meter.<br />
* '''-s <speed in knots>:''' Also run at the given airspeed in knots.<br />
<br />
{{Note|The values generated by this method are for the aircraft taken as a whole, as solved by YASim, so they differ from the values of the wing airfoil.}}<br />
<br />
To get the tabular output for the example above at 1000 m and 150 knots, and to redirect this to a file, one would issue:<br />
<br />
<code>"C:\Program Files\FlightGear\bin\Win32\yasim.exe" "C:\Program Files\FlightGear\data\Aircraft\f-14b\f-14b-yasim.xml" -g -a 1000 -s 150 > "C:\Program Files\FlightGear\yasim.txt"</code><br />
<br />
== New features and bugfixes in version 2017.2 ==<br />
<br />
=== XML parser ===<br />
==== support for metric and imperial units ====<br />
To make life easier for aircraft developers, the parser supports new additional attributes with a unit suffix, e.g. speed-kt for knots and speed-kmh for kilometers per hour.<br />
* <code><airplane {mass, mass-lbs, mass-kg}="12345" ></code><br />
* <code><approach {speed, speed-kt, speed-kmh}="123" ></code><br />
* <code><cruise {speed, speed-kt, speed-kmh}="123" ></code><br />
* <code><solve-weight {weight, weight-lbs, weight-kg}="123" ></code><br />
* <code><jet {mass, mass-lbs, mass-kg}="1234" ></code><br />
* <code><tank {capacity, capacity-lbs, capacity-kg}="12345" ></code><br />
* <code><ballast {mass, mass-lbs, mass-kg}="1234" ></code><br />
<br />
{{Note|Aircraft using this new attributes will not run on older versions of FlightGear, so it is probably wise to publish those only after a reasonable number of users switched version 2017.2 or newer.}}<br />
<br />
==== CG tuning help ====<br />
{{Note| The feature described in this section is not fully implemented yet, however, it may be of some help already.<br />
It is currently implemented for the yasim CLI tool only. It does not affect the airplane behaviour while running FlightGear. }}<br />
<br />
New attributes have been added to <airplane> to assist tuning the center of gravity (CG).<br />
The CG position is often expressed relative to the [https://en.wikipedia.org/wiki/Chord_(aeronautics)#Mean_aerodynamic_chord MAC] of the wing in percent. You can specify a desired range for CG in % relative to MAC, it will show up in the output of the yasim CLI tool (see example below):<br />
<br />
* cg-min: default 25% (just a guess, better numbers are welcome)<br />
* cg-max: default 30% (just a guess, better numbers are welcome)<br />
<br />
{{Note| By convention 0% is leading edge, 100% is trailing edge, however the absolute values on x-axis are the other way round, e.g. nose is +x, tail is -x }}<br />
{{warning|The MAC calculation in version 2017.2 works only on the <wing> element. Numbers will be wrong, if your model uses a combination of <wing> and <mstab> to build a wing with two or more sections.<br />
Section support will be added in version 2018.1}}<br />
YASim will print the leading edge coordinates of the MAC (x,y) and its length.<br />
<br />
'''Example output'''<br />
<pre><br />
$ yasim Citation-II-yasim.xml <br />
This aircraft uses yasim version '2017.2' <br />
========================== <br />
= YASim solution results = <br />
========================== <br />
Iterations: 2210 <br />
Drag Coefficient: 12.304669 <br />
Lift Ratio: 85.317558 <br />
Cruise AoA: 4.016746 deg <br />
Tail Incidence: -3.053278 deg <br />
Approach Elevator: -0.377542 <br />
<br />
CG: x:-6.543, y:-0.000, z:0.044 <br />
Wing MAC (*1): x:-6.00, y:3.83, length:2.0 <br />
CG-x rel. MAC: 0.272 <br />
CG-x desired: -6.599 < -6.543 < -6.198 <br />
<br />
Inertia tensor [kg*m^2], origo at CG: <br />
<br />
18009.289, -0.000, 7120.470 <br />
-0.000, 42459.316, 0.000 <br />
7120.470, 0.000, 56980.656 <br />
<br />
(*1) MAC calculation works on <wing> only! Numbers will be wrong for segmented wings, e.g. <wing>+<mstab>.<br />
</pre><br />
<br />
=== Aircraft developer helpers ===<br />
The command line utility got some new options. For some strange reason, the -a parameter expects altitude in meters instead of ft. This is now visible in the usage message but left unchanged for compatibility.<br />
<syntaxhighlight>Usage:<br />
yasim <aircraft.xml> [-g [-a meters] [-s kts] [-approach | -cruise] ]<br />
yasim <aircraft.xml> [-d [-a meters] [-approach | -cruise] ]<br />
yasim <aircraft.xml> [-m]<br />
-g print lift/drag table: aoa, lift, drag, lift/drag <br />
-d print drag over TAS: kts, drag<br />
-a set altitude in meters!<br />
-s set speed in knots<br />
-m print mass distribution table: id, x, y, z, mass</syntaxhighlight><br />
<br />
=== Bugfixes ===<br />
The following bugfixes require <airplane version="2017.2"> for backward compatibility <br />
* Ground effect: corrected the calculation of the height where g.e. ends<br />
* Stall parameters were set wrong for wings with camber=0<br />
<br />
== New features and bugfixes in version 2018.1 ==<br />
The following is under development and hopefully finds its way into FG version 2018.1<br />
<br />
=== Wing Section Support ===<br />
Many airliners have wings with a geometry that is just a little more complex than what YASim supported initially (tapered wing with some angles like sweep, dihedral, ...), e.g. they have an inboard section and an outboard section that can be described with YASim wing syntax. You can use a wing + a mstab XML element to describe this geometry but it is easier if YASim can just append more wing sections by simply adding more wing XML elements. This is now (Version 2018.1) possible, yasim will simply append sections if it finds more than one wing or hstab in the XML.<br />
You should use '''&lt;wing append="1" ... &gt;''' for all but the first wing/hstab declaration. <br />
{{Note|YASim will ignore the root point (x,y,z), the chord length and the incidence attributes, if you add "append" and calculate those from the previous wing section. }}<br />
MAC calculation works for the whole wing.<br />
<br />
{{warning|Aircrafts using this feature will not work with older versions of flightgear. }}<br />
To keep the aircraft backward compatible for a while, it is recommended to create a copy of its yasim XML file for development. <br />
Once you are happy with the CG and wing parameters you can use the output of the YASim CLI tool to modifiy the original XML. <br />
The tool will output the needed x,y,z etc per wing section to create a XML in old format with (only one) <wing> + <mstab>.<br />
<br />
=== More information from CLI tools ===<br />
You should configure the maximum take of weight (MTOW) in your XML file by adding either ''mtow-lbs'' or ''mtow-kg'' attribute to the airplane:<br />
<br />
<code> &lt;airplane mass="7500" version="2018.1" mtow-lbs="12500"&gt; </code><br />
<br />
'''Example output'''<br />
<pre><br />
yasim CRJ700.xml <br />
==========================<br />
= YASim solution results =<br />
==========================<br />
Iterations : 1024<br />
Drag Coefficient : 17.707<br />
Lift Ratio : 145.841<br />
Cruise AoA : -0.11 deg<br />
Tail Incidence : 3.47 deg<br />
Approach Elevator : -0.792<br />
<br />
CG : x:-0.046, y:0.000, z:-1.222<br />
Wing MAC : (x:0.79, y:4.99), length:3.4 <br />
hard limit CG-x : 14.232 m<br />
soft limit CG-x : -0.058 m<br />
CG-x : -0.046 m<br />
CG-x rel. MAC : 25%<br />
soft limit CG-x : -0.228 m<br />
hard limit CG-x : -0.986 m<br />
<br />
wing lever : -0.012 m<br />
tail lever : -13.997 m<br />
<br />
max thrust : 157.18 kN<br />
thrust/empty : 0.81<br />
thrust/mtow : 0.49<br />
<br />
wing span : 22.64 m<br />
sweep lead. edge : 30.2 .. 30.6 deg<br />
wing area : 58.70 m^2<br />
wing load empty : 336.15 kg/m^2 (Empty 19731 kg)<br />
wing load MTOW : 562.18 kg/m^2 (MTOW 32999 kg)<br />
<br />
tail span : 8.533 m<br />
tail area : 14.838 m^2<br />
<br />
#wing sections: 2<br />
Section 0 base point (0.450, 1.226, -2.034), chord 5.085, incidence at section root 5.0deg<br />
Section 1 base point (-0.663, 4.754, -1.942), chord 3.204, incidence at section root 3.0deg<br />
<br />
Inertia tensor [kg*m^2], origo at CG:<br />
<br />
195646, 0, 122265<br />
0, 1757279, 0<br />
122265, 0, 1904528<br />
</pre><br />
<br />
=== Variable tail incidence / elevator trim ===<br />
Small GA aircrafts usually trim with a trim tab on the elevator. For efficiency, airliners normally do not trim the elevator ("flap") <br />
but rotate the whole stabilizer (=tail) wing, e.g. they change the incidence for this wing. While this feature was somehow foreseen, <br />
it was not implemented yet, most likely because the "tail incidence" is one of the free variables used by the YASim solver. <br />
However, it is possible now to use the control="INCIDENCE" within the &lt;hstab&gt; to implement an alternative trim '''while maintaining full elevator authority'''.<br />
<pre><br />
<hstab ... incidence-min-deg="-13.0" incidence-max-deg="2.0"><br />
...<br />
<control-input axis="/controls/flight/hstab-trim" control="INCIDENCE" /><br />
<control-speed control="INCIDENCE" transition-time="20.0" /><br />
<control-output control="INCIDENCE" prop="/surface-positions/hstab-rad" /> <br />
</hstab><br />
</pre><br />
{{Note|The control output of INCIDENCE is the angle in radians, not in degree, as that is the unit internally used by YASim.}}<br />
{{warning|The OPTIONAL incidence-min-deg and incidence-max-deg set the limits for the solver. You must make sure to select a sufficiently large range or solver will fail. }}<br />
First experiments with this feature were successful in that the aircraft pitch could be changed as expected but fine tuning will be necessary.<br />
<br />
<br />
== Related content ==<br />
* [[Howto:Make a helicopter#XML Elements]] &ndash; Rotor and rotorgear YASim elements<br />
* [[Towing]]<br />
* [[YASim Development Tools]]<br />
<br />
== External links ==<br />
* {{cite web<br />
| url = http://www.buckarooshangar.com/flightgear/yasimtut.html<br />
| title = Guide to YASim<br />
| first = Gary R. "Buckaroo"<br />
| last = Neely<br />
| authorlink = http://www.buckarooshangar.com/flightgear/<br />
| date = 2013<br />
| accessdate = April 16, 2020<br />
}} - A very helpful guide<br />
* {{cite web<br />
| url = https://sourceforge.net/projects/dacpei/<br />
| title = DACPEI<br />
| author = pytoche<br />
| date = February 2012<br />
| publisher = SourceForge<br />
| accessdate = April 16, 2020<br />
}} - A fixed wing light aircraft WYSIWUG concept design suite that can export an YASim FDM to FlightGear.<br />
<br />
{{FDM}}<br />
<br />
[[Category:Flight Dynamics Model]]<br />
<br />
[[fr:YASim]]</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=YASim&diff=134765YASim2022-03-11T17:47:06Z<p>Cgdae: Clarified wing length and sweep values.</p>
<hr />
<div>[[File:yasimlogo.png|thumb]] <br />
<br />
'''YASim''' is one of two [[flight dynamics model]]s commonly used in [[FlightGear]]. The flight dynamics model (FDM) determines how the [[aircraft]] moves and flies.<br />
<br />
Gary Neely wrote in his [http://www.buckarooshangar.com/flightgear/ introduction to YASim]:<br />
<br />
:''The FDM is the mathematical model that controls the physics of flight within the simulator. The physical 3D aircraft model has nothing to do with flight dynamics-- in essence it's just a picture to look at. It's the FDM that dictates how the model flies.''<br />
<br />
:''Why YASim? YASim uses the geometry of the aircraft to generate the base flight characteristics. While this suggests a 'realistic' or out-of-the-box approach, it is a only rough approximation that will require much tweaking before you get a result that approaches realism. If you have solid flight data for your aircraft such as wind-tunnel data or you are looking to eventually generate a hyper-realistic simulation, JSBSim is probably a better approach. If you lack such data but know the geometry of the aircraft and have access to the same flight characteristics and limits as a real pilot would, then YASim can provide a solution that is more than sufficient for most simulation needs.''<br />
<br />
== Coordinate system notes ==<br />
All positions specified are in metres (which is weird, since all other units in the file are English). The X axis points forward, Y is left, and Z is up. Take your right hand, and hold it like a gun. Your first and second fingers are the X and Y axes, and your upwards-pointing thumb is the Z. This is slightly different from the coordinate system used by [[JSBSim]]. Sorry. The origin can be placed anywhere, so long as you are consistent. I use the nose of the aircraft.<br />
<br />
(In the [[JSBSim_Aerodynamics#Frames|JSBSim coordinate system]], X and Z are the same as in YASim, but Y points to the right instead of left.)<br />
<br />
== YASim design notes ==<br />
Andy Ross's original design notes for YASim can be found in [https://pdfhost.io/v/~iYsLl7xS_alldvi.pdf this PDF file]. These provide some useful background for how YASim works.<br />
<br />
== XML Elements ==<br />
<!-- To future editors: The all lowercase headings are XML tags and should ''probably'' be left that way --><br />
=== airplane ===<br />
The top-level element for the file. It contains the following attributes: <br />
* '''mass:''' The empty (no fuel) weight, in pounds. It does include the weight of the engine(s), so when you add the engine weight in its tag, it acts just like a ballast.<br />
* '''version:''' The version attribute is used to maintain compatibility when updating yasim (e.g. bugfixes). If this attribute i not given, the original version will be used. Several bugfixes to YASim were implemented in FlightGear 3.2 (see [[FlightGear Newsletter April 2014]]), some more are fixed in FlightGear 2017.2. <br />
Available versions are:<br />
* <code>YASIM_VERSION_ORIGINAL</code> explicitly use the old buggy calculations (same as no version attribute at all)<br />
* <code>YASIM_VERSION_32</code> enable bugfixes up to version 3.2<br />
* <code>2017.2</code> enable bugfixes up to version 2017.2<br />
* <code>2018.1</code> (FIXME) no bugfixes by now. Use this version if your aircraft makes use of new features in YASim 2018.1 so it will cause at least a warning with older FG versions. <br />
* <code>YASIM_VERSION_CURRENT</code> use latest version compiled into the users FlightGear. <br />
{{Warning| Using YASIM_VERSION_CURRENT might make the aircraft unusable in case of future changes to YASim without updating the aircraft accordingly.}}<br />
<br />
'''New in 2018.1'''<br />
* '''mtow-lbs''' and '''mtow-kg:''' use one of them to specify max. takeoff weight. Does not affect the FDM, but is used by CLI tool to calculate some numbers.<br />
<br />
=== approach ===<br />
The approach parameters for the aircraft. The solver will generate an aircraft that matches these settings (by adjusting the parameters of the surface like drag and lift). It is extremely important to give parameters which could be really achieved by defined aircraft geometry, otherwise, it gives an unstable or not flyable result. The element can (and should) contain <control> elements indicating pilot input settings, such as flaps and throttle, for the approach.<br />
<br />
* '''speed:''' The approach airspeed, in knots TAS.<br />
* '''aoa:''' The approach angle of attack, in degrees<br />
* '''fuel:''' Fraction (0-1) of fuel in the tanks. Default is 0.2.<br />
<br />
=== cruise ===<br />
The cruise speed and altitude for the solver to match. As above, this should contain <control> elements indicating aircraft configuration. Especially, make sure the engines are generating enough thrust at cruise!<br />
* '''speed:''' The cruise speed, in knots TAS.<br />
* '''alt:''' The cruise altitude, in feet MSL.<br />
* '''fuel:''' Fraction (0-1) of fuel in the tanks. Default is 0.2.<br />
=== cockpit ===<br />
The location of the cockpit (pilot eyepoint).<br />
* '''x,y,z:''' eyepoint location (see coordinates note)<br />
<br />
=== fuselage ===<br />
This defines a tubelike structure. It will be given an even mass and aerodynamic force distribution by the solver. You can have as many as you like, in any orientation you please.<br />
* '''ax,ay,az:''' One end of the tube (typically the front)<br />
* '''bx,by,bz:''' The other ("back") end.<br />
* '''width:''' The width of the tube, in metres.<br />
* '''taper:''' The approximate radius at the "tips" of the fuselage expressed as a fraction (0-1) of the width value.<br />
* '''midpoint:''' The location of the widest part of the fuselage, expressed as a fraction of the distance between A and B.<br />
* '''idrag:''' Multiplier for the "induced drag" generated by this object. Default is one. With idrag=0 the fuselage generates only drag.<br />
* '''cx,cy,cz:''' Factors for the generated drag in the fuselages "local coordinate system" with x pointing from end to front, z perpendicular to x with y=0 in the aircraft coordinate system. E.g. for a fuselage of a height of 2 times the width you can define cy=2 and (due to the doubled front surface) cx=2.<br />
<br />
=== Surfaces ===<br />
==== wing ====<br />
This defines the main wing of the aircraft. You can have only one (but see below about using vstab objects for extra lifting surfaces). The wing should have a <stall> subelement to indicate stall behavior, control surface subelements (flap0, flap1, spoiler, slat) to indicate what and where the control surfaces are, and <control> subelements to map user input properties to the control surfaces.<br />
* '''x,y,z:''' The "base" of the wing, specified as the location of the mid-chord (not leading edge, trailing edge, or aerodynamic center) point at the root of the LEFT (!) wing.<br />
* '''length:''' The length from the midchord point of the base of the wing to the midchord point at the tip. Note that this is not the same thing as span.<br />
* '''chord:''' The chord of the wing at its base, along the X axis (not normal to the leading edge, as it is sometimes defined).<br />
* '''incidence:''' The incidence angle at the wing root, in degrees. Zero is level with the fuselage (as in an aerobatic plane), positive means that the leading edge is higher than the trailing edge (as in a trainer).<br />
* '''twist:''' The difference between the incidence angle at the wing root and the incidence angle at the wing tip. Typically, this is a negative number so that the wing tips have a lower angle of attack and stall after the wing root (washout).<br />
* '''taper:''' The taper fraction, expressed as the tip chord divided by the root chord. A taper of one is a hershey bar wing, and zero would be a wing ending at a point. Defaults to one.<br />
* '''sweep:''' The sweep angle of the wing, in degrees. Zero is no sweep, positive angles are swept back. Defaults to zero. [This looks to be the sweep of the mid-chord of the wing, not the sweep of the leading edge.]<br />
* '''dihedral:''' The dihedral angle of the wing. Positive angles are upward dihedral. Defaults to zero.<br />
* '''idrag:''' Multiplier for the "induced drag" generated by this surface. In general, low aspect wings will generate less induced drag per-AoA than high aspect (glider) wings. This value isn't constrained well by the solution process, and may require tuning to get throttle settings correct in high AoA (approach) situations.<br />
* '''effectiveness:''' Multiplier for the "normal" drag generated by the wing. Defaults to 1. Arbitrary, dimensionless factor. <br />
* '''camber:''' The lift produced by the wing at zero angle of attack, expressed as a fraction of the maximum lift produced at the stall AoA.<br />
* '''flow:''' The flow regime for the wing. Valid values are "SUBSONIC" (default) and "TRANSONIC". Setting surface to transonic adds more lift above mach number 0.6 by applying a Prandl/Glauert correction term to each surface-element. The effect is a more balanced lift/drag distribution reported by the solver. Use for anything that flies faster than mach 0.6 or has supercritical airfoils.<br />
* '''mcrit:''' The critical mach number for the wing. This point defines the begin of exponential drag rise due to mach speed. Default "0.6", only available if flow="TRANSONIC".<br />
<br />
'''Wing section support (since 2018.1):'''<br />
<br />
Wing section support to define variable geometry (geometry parameters per section)<br />
* More than one <wing>-element is allowed now. <br />
* x, y, z, chord and incidence attribute shall be specifed only for the first <wing> in the XML file. They will be overridden for subsequent <wing>-elements.<br />
* Use '''append="1"''' for additional '''wing''' elements to skip x, y, z, chord and incidence attribute as the will be calculated from previous '''wing''' element tip chord. This workaround is currently needed due to limitations in the XML parser.<br />
<br />
==== hstab ====<br />
These define the horizontal stabilizer of the aircraft. Internally, it is just a wing object and therefore works the same in XML. <br />
You are allowed only one hstab object; the solver needs to know which wing's incidence to play with to get the aircraft trimmed correctly.<br />
<br />
'''New in 2018.1:'''<br />
* '''hstab''' supports sections in the same way '''wing''' does, but it is still considered as /the/ (only) hstab used by the solver.<br />
* '''incidence-min-deg''' and '''incidence-max-deg''': optional attributes to limit valid result range fore the solver. Use with care or you won't get a solution.<br />
<br />
==== vstab ====<br />
A "vertical" stabilizer. Like hstab, this is just another wing, with a few special properties. The surface is not "mirrored" as are wing and hstab objects. If you define a left wing only, you'll only get a left wing. The default dihedral, if unspecified, is 90 degrees instead of zero. But all parameters are equally settable, so there's no requirement that this object be "vertical" at all. You can use it for anything you like, such as extra wings for biplanes. Most importantly, these surfaces are not involved with the solver computation, so you can have none, or as many as you like.<br />
<br />
==== mstab ====<br />
A mirrored horizontal stabilizer. Exactly the same as wing, but not involved with the solver computation, so you can have none, or as many as you like.<br />
<br />
==== stall ====<br />
A subelement of a wing (or hstab/vstab/mstab) that specifies the stall behavior.<br />
* '''aoa:''' The stall angle (maximum lift) in degrees. Note that this is relative to the wing, not the fuselage (since the wing may have a non-zero incidence angle).<br />
* '''width:''' The "width" of the stall, in degrees. A high value indicates a gentle stall. Low values are viscious for a non-twisted wing, but are acceptable for a twisted one (since the whole wing will not stall at the same time).<br />
* '''peak:''' The height of the lift peak, relative to the post-stall secondary lift peak at 45 degrees. Defaults to 1.5. This one is deep voodoo, and probably doesn't need to change much. Bug me for an explanation if you're curious.<br />
<br />
==== flap0, flap1, slat, spoiler ====<br />
These are subelements of wing/hstab/vstab objects, and specify the location and effectiveness of the control surfaces.<br />
* '''start:''' The position along the wing where the control surface begins.Zero is the root, one is the tip.<br />
* '''end:''' The position where the surface ends, as above.<br />
* '''lift:''' The lift multiplier for a flap or slat at full extension. One is a no-op, a typical aileron might be 1.2 or so, a giant jetliner flap 2.0, and a spoiler 0.0. For spoilers, the interpretation is a little different -- they spoil only "prestall" lift. Lift due purely to "flat plate" effects isn't affected. For typical wings that stall at low AoA's essentially all lift is pre-stall and you don't have to care. Jet fighters tend not to have wing spoilers, for exactly this reason. This value is not applicable to slats, which affect stall AoA only.<br />
* '''drag:''' The drag multiplier, as above. Typically should be higher than the lift multiplier for flaps.<br />
* '''aoa:''' Applicable only to slats. This indicates the angle by which the stall AoA is translated by the slat extension.<br />
<br />
=== Rotor and rotorgear ===<br />
YASim has also possibility to simulate rotorcraft blades. The number properties of rotor elements are large therefore are spitted to the separate page [[Howto:Make a helicopter#XML%20Elements|howto make a helicopter in YASim]].<br />
<br />
=== Engine ===<br />
==== Thruster ====<br />
A very simple "thrust only" engine object. Useful for things like thrust vectoring nozzles. All it does is map its THROTTLE input axis to its output thrust rating. Does not consume fuel, etc...<br />
* '''thrust:''' Maximum thrust in pounds<br />
* '''x,y,z:''' The point on the airframe where thrust will be applied.<br />
* '''vx,vy,vy:''' The direction of the thrust in airframe coordinates. The vector will be normalized automatically, so any non-zero vector will work fine.<br />
<br />
Example: <br />
<br />
<syntaxhighlight lang="xml" line><br />
<thruster x="0" y="0" z="0.03" vx="1" vy="0" vz="0" thrust="6.61"><br />
<control-input axis="/controls/engines/engine[0]/throttle" control="THROTTLE" src0="-1" src1="1" dst0="-1" dst1="1"/><br />
</thruster><br />
</syntaxhighlight><br />
<br />
==== Jet ====<br />
A turbojet/fan engine. It accepts a <control> subelement to map a property to its throttle setting, and an <actionpt> subelement to place the action point of the thrust at a different position than the mass of the engine.<br />
* '''x,y,z:''' The location of the engine, as a point mass. If no actionpt is specified, this will also be the point of application of thrust.<br />
* '''mass:''' The mass of the engine, in pounds.<br />
* '''thrust:''' The maximum sea-level thrust, in pounds.<br />
* '''afterburner:''' Maximum total thrust with afterburner/reheat, in pounds [defaults to "no additional thrust"].<br />
* '''rotate:''' Vector angle of the thrust in degrees about the Y axis [0].<br />
* '''n1-idle:''' Idling low pressure core / fan speed [55]. <br />
* '''n1-max:''' Maximum low pressure core / fan speed [102].<br />
* '''n2-idle:''' Idling high pressure core speed [73].<br />
* '''n2-max:''' Maximum high pressure core speed [103].<br />
* '''tsfc:''' Thrust-specific fuel consumption [0.8]. This should be considerably lower for modern turbofans.<br />
* '''atsfc:''' (version >= 2016.3.1) Thrust specific fuel consumption with afterburner on. When set to zero defaults to older behaviour where it is calculated from dry fuel consumption [0].<br />
* '''egt:''' Exhaust gas temperature at takeoff in K [1050].<br />
* '''epr:''' Engine pressure ratio at takeoff [3.0].<br />
* '''exhaust-speed:''' The maximum exhaust speed in knots [~1555].<br />
* '''spool-time:''' Time, in seconds, for the engine to respond to 90% of a commanded powersetting.<br />
<br />
==== Propeller ====<br />
A propeller. This element requires an engine subtag. Currently <piston-engine> and <turbine-engine> are supported.<br />
* '''x,y,z:''' The position of the mass (!) of the engine/propeller combination. If the point of force application is different (and it will be) it should be set with an <actionpt> subelement.<br />
* '''mass:''' The mass of the engine/propeller, in pounds.<br />
* '''moment:''' The moment, in kg-metres^2. This has to be hand calculated and guessed at for now. A more automated system will be forthcoming. Use a negative moment value for counter-rotating ("European" -- CCW as seen from behind the prop) propellers. A good guess for this value is the radius of the prop (in meters) squared times the mass (kg) divided by three; that is the moment of a plain "stick" bolted to the prop shaft.<br />
* '''radius:''' The radius, in meters, or the propeller.<br />
* '''cruise-speed:''' The max efficiency cruise speed of the propeller. Generally not the same as the aircraft's cruise speed.<br />
* '''cruise-rpm:''' The RPM of the propeller at max-eff. cruise.<br />
* '''cruise-power:''' The power sunk by the prop at cruise, in horsepower.<br />
* '''cruise-alt:''' The reference cruise altitude in feet.<br />
* '''takeoff-power:''' The takeoff power required by the propeller...<br />
* '''takeoff-rpm:''' ...at the given takeoff RPM.<br />
* '''gear-ratio:''' The factor by which the engine RPM is multiplied to produce the propeller RPM. Optional (defaults to 1.0).<br />
* '''contra:''' When set (contra="1"), this indicates that the propeller is a contra-rotating pair. It will not contribute to the aircraft's net gyroscopic moment, nor will it produce asymmetric torque on the aircraft body. Asymmetric slipstream effects, when implemented, will also be zero when this is set.<br />
<br />
<br />
YASim assumes a fixed-pitch propeller by default. If your engine is using a constant-speed propeller, you'll also need to provide these attributes:<br />
<br />
* '''min-rpm:''' The minimum operational RPM for a constant speed propeller. This is the speed to which the prop governor will seek when the blue lever is at a minimum. The coarse-stop attribute limits how far the governor can go into trying to reach this RPM.<br />
* '''max-rpm:''' The maximum operational RPM for a constant speed propeller. See above. The fine-stop attribute limits how far the governor can go in trying to reach this RPM.<br />
* '''fine-stop:''' The minimum pitch of the propeller (high RPM) as a ratio of ideal cruise pitch. This is set to 0.25 by default -- a higher value will result in a lower RPM at low power settings (e.g. idle, taxi, and approach).<br />
* '''coarse-stop:''' The maximum pitch of the propeller (low RPM) as a ratio of ideal cruise pitch. This is set to 4.0 by default -- a lower value may result in a higher RPM at high power settings.<br />
<br />
<br />
===== piston-engine =====<br />
<br />
A piston engine definition. This must be a subelement of an enclosing <propeller> tag.<br />
<br />
* '''eng-power:''' Maximum BHP of the engine at sea level.<br />
* '''eng-rpm:''' The engine RPM at which eng-power is developed<br />
* '''displacement:''' The engine displacement in cubic inches.<br />
* '''compression:''' The engine compression ratio.<br />
<br />
<syntaxhighlight lang="xml" line><br />
<piston-engine eng-power="2" eng-rpm="3800" displacement="20" ><br />
<control-input axis="/controls/engines/engine[0]/throttle" control="THROTTLE"/><br />
<control-input axis="/controls/engines/engine[0]/starter" control="STARTER"/><br />
<control-input axis="/controls/engines/engine[0]/magnetos" control="MAGNETOS"/><br />
<control-input axis="/controls/engines/engine[0]/mixture" control="MIXTURE"/><br />
</piston-engine><br />
</syntaxhighlight><br />
<br />
===== electric-engine =====<br />
<br />
A simplified electric DC engine model. The model is available since the end of April 2020, therefore it is currently available in daily build FlightGear snapshots. This definition must be a subelement of an enclosing <propeller> tag.<br />
<br />
* '''Kv''' electric engine constant in revolutions per minute to volt. <br />
* '''voltage''' The voltage applied to the motor e.g. Nominal battery voltage in Volts. <br />
* '''Rm''' The engine winding resistance in Ohms.<br />
<br />
<br />
Example:<br />
<br />
<syntaxhighlight lang="xml" line><br />
<propeller x="0.02" y="0" z="0.03"<br />
mass="0.05"<br />
moment="0.0006"<br />
radius="0.203"<br />
cruise-speed="26"<br />
cruise-rpm="7000"<br />
cruise-power="0.5"<br />
cruise-alt="2000"<br />
takeoff-power="0.70"<br />
takeoff-rpm="9200"<br />
contra="1"><br />
<actionpt x="0" y="0" z="0.03"/><br />
<electric-engine Kv="750" voltage="15" Rm="0.02" ><br />
<control-input axis="/controls/engines/engine[0]/throttle" control="THROTTLE"/><br />
</electric-engine><br />
</propeller><br />
</syntaxhighlight><br />
<br />
=== Landing gear ===<br />
==== gear ====<br />
Defines a landing gear. Accepts <control> subelements to map properties to steering and braking. Can also be used to simulate floats. Although the coefficients are still called ..fric, it is calculated in fluids as a drag (proportional to the square of the speed). In fluids gears are not considered to detect crashes (as on ground). <br />
* '''x,y,z:''' The location of the fully-extended gear tip.<br />
* '''compression:''' The distance in metres along the "up" axis that the gear will compress.<br />
* '''initial-load:''' The initial load of the spring in multiples of compression. Defaults to 0. (With this parameter a lower spring-constants will be used for the gear-> can reduce numerical problems (jitter)) '''Note:''' the spring-constant is varied from 0% compression to 20% compression to get continuous behavior around 0 compression. (could be physically explained by wheel deformation)<br />
* '''upx/upy/upz:''' The direction of compression, defaults to vertical (0,0,1) if unspecified. These are used only for a direction -- the vector need not be normalized, as the length is specified by "compression".<br />
* '''sfric:''' Static (non-skidding) coefficient of friction. Defaults to 0.8.<br />
* '''dfric:''' Dynamic friction. Defaults to 0.7.<br />
* '''stiction:''' Stiction to ground. Defaults to 0. stiction = "1" ensures the gear isn't sliding unintentionally (Note: please correct docu here for more detailed facts, developers didn't document this extension here and this is based on trial and guessing only)<br />
* '''spring:''' A dimensionless multiplier for the automatically generated spring constant. Increase to make the gear stiffer, decrease to make it squishier.<br />
* '''damp:''' A dimensionless multiplier for the automatically generated damping coefficient. Decrease to make the gear "bouncier", increase to make it "slower". Beware of increasing this too far: very high damping forces can make the numerics unstable. If you can't make the gear stop bouncing with this number, try increasing the compression length instead.<br />
* '''on-water:''' if this is set to "0" the gear will be ignored if on water. Defaults to "0"<br />
* '''on-solid:''' if this set to "0" the gear will be ignored if not on water. Defaults to "1"<br />
* '''speed-planing:'''<br />
* '''spring-factor-not-planing:''' At zero speed the spring factor is multiplied by spring-factor-not-planing. Above speed-planing this factor is equal to 1. The idea is, to use this for floats simulating the transition from swimming to planing. speed-planing defaults to 0, spring-factor-not-planing defaults to 1.<br />
* '''reduce-friction-by-extension:''' at full extension the friction is reduced by this relative value. 0.7 means 30% friction at full extension. If you specify a value greater than one, the friction will be zero before reaching full extension. Defaults to "0"<br />
* '''ignored-by-solver:''' with the on-water/on-solid tags you can have more than one set of gears in one aircraft, If the solver (who automatically generates the spring constants) would take all gears into account, the result would be wrong. E. G. set this tag to "1" for all gears, which are not active on runways. Defaults to "0". You can not exclude all gears in the solving process.<br />
<br />
<br />
<syntaxhighlight lang="xml" line><br />
<!-- front gear --><br />
<br />
<gear x="0.0" y="0.0" z="-0.205"<br />
spring="0.9"<br />
damp="0.8"<br />
dfric="0.9"<br />
sfric="1.1"<br />
compression="0.051"><br />
<control-input axis="/controls/flight/rudder" control="STEER" square="true" src0="-1.0" src1="1.0" dst0="-0.3" dst1="0.3"/><br />
<control-input axis="/controls/gear/brake-right" control="BRAKE" split="true"/><br />
<control-input axis="/controls/gear/brake-parking" control="BRAKE" split="true"/><br />
</gear><br />
<br />
<!-- two rear gears --><br />
<br />
<gear x="-0.4" y="0.25" z="-0.205"<br />
spring="0.9"<br />
damp="0.8"<br />
dfric="0.9"<br />
sfric="1.1"<br />
compression="0.051"><br />
<control-input axis="/controls/gear/brake-right" control="BRAKE" split="true"/><br />
<control-input axis="/controls/gear/brake-parking" control="BRAKE" split="true"/><br />
</gear><br />
<br />
<gear x="-0.4" y="-0.25" z="-0.205"<br />
spring="0.9"<br />
damp="0.8"<br />
dfric="0.9"<br />
sfric="1.1"<br />
compression="0.051"><br />
<control-input axis="/controls/gear/brake-left" control="BRAKE" split="true"/><br />
<control-input axis="/controls/gear/brake-parking" control="BRAKE" split="true"/><br />
</gear><br />
</syntaxhighlight><br />
<br />
==== Launchbar ====<br />
Defines a catapult launchbar or strop.<br />
* '''x,y,z:''' The location of the mount point of the launch bar or strop on the aircraft.<br />
* '''length:''' The length of the launch bar from mount point to tip<br />
* '''down-angle:''' The max angle below the horizontal the launchbar can achieve.<br />
* '''up-angle:''' The max angle above the horizontal the launchbar can achieve.<br />
* '''holdback-{x,y,z}:''' The location of the holdback mount point on the aircraft.<br />
* '''holdback-length:''' The length of the holdback from mount point to tip. Note: holdback up-angle and down-angle are the same as those defined for the launchbar and are not specified in the configuration.<br />
<br />
=== Fuel ===<br />
==== tank ====<br />
A fuel tank. Tanks in the aircraft are identified numerically (starting from zero), in the order they are defined in the file. If the left tank is first, "tank[0]" will be the left tank. <br />
* '''x,y,z:''' The location of the tank.<br />
* '''capacity:''' The maximum contents of the tank, in pounds. Not gallons -- YASim supports fuels of varying densities.<br />
* '''jet:''' A boolean. If present, this causes the fuel density to be treated as Jet-A. Otherwise, gasoline density is used. A more elaborate density setting (in pounds per gallon, for example) would be easy to implement. Bug me.<br />
<br />
=== Center of Gravity ===<br />
==== Ballast ====<br />
This is a mechanism for modifying the mass distribution of the aircraft. A ballast setting specifies that a particular amount of the empty weight of the aircraft must be placed at a given location. The remaining non-ballast weight will be distributed "intelligently" across the fuselage and wing objects. Note again: this does NOT change the empty weight of the aircraft. <br />
* '''x,y,z:''' The location of the ballast.<br />
* '''mass:''' How much mass, in pounds, to put there. Note that this value can be negative. I find that I often need to "lighten" the tail of the aircraft.<br />
<br />
<br />
<syntaxhighlight lang="xml" line><br />
<ballast x="-0.24" y="0.0" z="0.33" mass-kg="0.5"/><br />
</syntaxhighlight><br />
<br />
==== Weight ====<br />
This is an added weight, something not part of the empty weight of the aircraft, like passengers, cargo, or external stores. The actual value of the mass is not specified here, instead, a mapping to a property is used. This allows external code, such as the panel, to control the weight (loading a given cargo configuration from preference files, dropping bombs at runtime, etc...)<br />
* '''x,y,z:''' The location of the weight.<br />
* '''mass-prop:''' The name of the fgfs property containing the mass, in pounds, of this weight.<br />
* '''size:''' The aerodynamic "size", in metres, of the object. This is important for external stores, which will cause drag. For reasonably aerodynamic stuff like bombs, the size should be roughly the width of the object. For other stuff, you're on your own. The default is zero, which results in no aerodynamic force (internal cargo).<br />
* '''solve-weight:''' Subtag of approach and cruise parameters. Used to specify a non-zero setting for a <weight> tag during solution. The default is to assume all weights are zero at the given performance numbers.<br />
* '''idx:''' Index of the weight in the file (starting with zero).<br />
* '''weight:''' Weight setting in pounds.<br />
<br />
<syntaxhighlight lang="xml" line><br />
<weight x="-0.06471" y="0.225" z="-0.2" mass-prop="/sim/weight[0]/weight-kg"/><br />
</syntaxhighlight><br />
<br />
=== Controls ===<br />
==== control-input ====<br />
This element manages a mapping from fgfs properties (user input) to settable values on the aircraft's objects. Note that the value to be set MUST (!) be valid on the given object type. This is not checked for by the parser, and will cause a runtime crash if you try it. Wing's don't have throttle controls, etc... Note that multiple axes may be set on the same value. They are summed before setting.<br />
* '''axis:''' The name of the double-valued fgfs property "axis" to use as input, such as "/controls/flight/aileron".<br />
* '''control:''' Which control axis to set on the objects. It can have the following values:<br />
** THROTTLE - The throttle on a jet or propeller. <br />
** MIXTURE - The mixture on a propeller.<br />
** REHEAT - The afterburner on a jet<br />
** PROP - The propeller advance<br />
** BRAKE - The brake on a gear.<br />
** STEER - The steering angle on a gear. <br />
** INCIDENCE - The incidence angle of a wing.<br />
** FLAP0 - The flap0 deflection of a wing. <br />
** FLAP1 - The flap1 deflection of a wing. <br />
** SLAT - The slat extension of a wing. <br />
** SPOILER - The spoiler extension for a wing. <br />
** CYCLICAIL - The "aileron" cyclic input of a rotor <br />
** CYCLICELE - The "elevator" cyclic input of a rotor <br />
** COLLECTIVE - The collective input of a rotor<br />
** ROTORENGINEON - If not equal zero the rotor is rotating <br />
** WINCHRELSPEED - The relative winch speed <br />
** {... and many more, see [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/FDM/YASim/ControlMap.cpp#l25 ControlMap.cpp] ...}<br />
* '''invert:''' Negate the value of the property before settling on the object.<br />
* '''split:''' Applicable to wing control surfaces. Sets the normal value on the left-wing, and a negated value on the right-wing.<br />
* '''square:''' Squares the value before setting. Useful for controls like a steering that needs a wide range, yet lots of sensitivity in the center. Obviously only applicable to values that have a range of [-1:1] or [0:1]. <br />
* '''src0/src1/dst0/dst1:''' If present, these define a linear mapping from the source to the output value. Input values in the range src0-src1 are mapped linearly to dst0-dst1, with clamping for input values that lie outside the range.<br />
<br />
==== control-output ====<br />
This can be used to pass the value of a YASim control axis (after all mapping and summing is applied) back to the property tree.<br />
* '''control:''' Name of the control axis. See above.<br />
* '''prop:''' Property node to receive the value.<br />
* '''side:''' Optional, for split controls. Either "right" or "left" <br />
* '''min/max:''' Clamping applied to output value.<br />
<br />
==== control-speed ====<br />
Some controls (most notably flaps and hydraulics) have maximum slew rates and cannot respond instantly to pilot input. This can be implemented with a control-speed tag, which defines a "transition time" required to slew through the full input range. Note that this tag is semi-deprecated, complicated control input filtering can be done much more robustly from a Nasal script.<br />
* '''control:''' Name of the control axis. See above.<br />
* '''transition-time:''' Time in seconds to slew through input range.<br />
<br />
==== control-setting ====<br />
This tag is used to define a particular setting for a control axis inside the <cruise> or <approach> tags, where obviously property input is not available. It can be used, for example, to inform the solver that the approach performance values assume full flaps, etc...<br />
* '''axis:''' Name of the control input (i.e. a property name)<br />
* '''value:''' Value of the control axis.<br />
<br />
=== Winch and Aerotow ===<br />
==== hitch ====<br />
A hitch, can be used for winch-start (in gliders) or aerotow (in gliders and motor aircraft) or for external cargo with helicopter. You can do aerotow over the net via multiplayer (see j3 and bocian as an example).<br />
* '''name:''' the name of the hitch. must be aerotow if you want to do aerotow via multiplayer. You will find many properties at /sim/hitches/name. Most of them are directly tied to the internal variables, you can modify them as you like. You can add a listener to the property "broken", e. g. for playing a sound.<br />
* '''x,y,z:''' The position of the hitch<br />
* '''force-is-calculated-by-other:''' if you want to simulate aerotowing over the internet, set this value to "1" in the motor aircraft. Don't specify or set this to zero in gliders. In a LAN the time lag might be small enough to set it on both aircraft to "0". It's intended, that this is done automatically in the future.<br />
==== tow ====<br />
The tow used for aerotow or winch. This must be a subelement of an enclosing <hitch> tag.<br />
* '''length:''' upstretched length in metres<br />
* '''weight-per-meter:''' in kg/metre<br />
* '''elastic-constant:''' lower values give higher elasticity<br />
* '''break-force:''' in N<br />
* '''mp-auto-connect-period:''' the every x seconds a towed multiplayer aircraft is searched. If found, this tow is connected automatically, parameters are copied from the other aircraft. Should be set only in the motor aircraft, not in the glider<br />
==== winch ====<br />
The tow used for aerotow or winch. This must be a subelement of an enclosing <hitch> tag.<br />
* '''max-tow-length:''' in m<br />
* '''min-tow-length''': in m<br />
* '''initial-tow-length:''' in m. The initial tow length also defines the length/search radius used for the mp-autoconnect feature<br />
* '''max-winch-speed:''' in m/s<br />
* '''power:''' in kW<br />
* '''max-force:''' in N<br />
<br />
<br />
<syntaxhighlight lang="xml" line><br />
<hitch name="winch" x="0.0" y="0.0" z="0.0"><br />
<tow length="50" weight-per-meter="0.0035" elastic-constant="40000" break-force="10000"/><br />
<!-- 3mm paracord--><br />
<winch max-tow-length="1000" min-tow-length="1" initial-tow-length="1000" max-winch-speed="20" power="2" max-force="80"/><br />
<control-input axis="/controls/winch/place" control="PLACEWINCH"/><br />
</hitch><br />
<hitch name="aerotow" x="0.0" y="0.0" z="0.0" force-is-calculated-by-other="0"><br />
<tow length="60" weight-per-meter="0.0035" elastic-constant="9000" break-force="100" mp-auto-connect-period="0.0"/><br />
<winch max-tow-length="1000" min-tow-length="60" initial-tow-length="60"/><br />
<control-input axis="/controls/aerotow/find-aircraft" control="FINDAITOW"/><br />
</hitch><br />
</syntaxhighlight><br />
<br />
== Visualization ==<br />
<br />
=== Blender visualization tool ===<br />
<br />
[[File:Yasim_visualisation_dc6.png|thumb|dc6 FDM in Blender]]To make the programmed aircraft visible it is possible to load and compare it with the 3D model within [[Blender]]. They applaud for this ''very'' useful script goes to M. Franz, thank you very much!<br />
<br />
For Blender versions <= 2.4 the script is located in FlightGears source code {{flightgear file|utils/Modeller/yasim_import.py}}.<br />
<br />
For Blender versions newer than 2.4, please see [[Blender YASim import]].<br />
<br />
The howto, taken from inside the script:<br />
<br />
yasim_import.py loads and visualizes a YASim FDM geometry<br />
=========================================================<br />
<br />
It is recommended to load the model superimposed over a greyed out and immutable copy of the aircraft model:<br />
<br />
(0) put this script into ~/.blender/scripts/<br />
(1) load or import aircraft model (menu -> "File" -> "Import" -> "AC3D (.ac) ...")<br />
(2) create new *empty* scene (menu -> arrow button left of "SCE:scene1" combobox -> "ADD NEW" -> "empty")<br />
(3) rename scene to yasim (not required)<br />
(4) link to scene1 (F10 -> "Output" tab -> arrow button left of text entry "No Set Scene" -> "scene1")<br />
(5) now load the YASim config file (menu -> "File" -> "Import" -> "YASim (.xml) ...")<br />
<br />
This is good enough for simple checks. But if you are working on the YASim configuration, then you need a<br />
quick and convenient way to reload the file. In that case, continue after (4):<br />
<br />
(5) switch the button area at the bottom of the blender screen to "Scripts Window" mode (green python snake icon)<br />
(6) load the YASim config file (menu -> "Scripts" -> "Import" -> "YASim (.xml) ...")<br />
(7) make the "Scripts Window" area as small as possible by dragging the area separator down<br />
(8) optionally split the "3D View" area and switch the right part to the "Outliner"<br />
(9) press the "Reload YASim" button in the script area to reload the file<br />
<br />
<br />
If the 3D model is displaced with respect to the FDM model, then the <offsets> values from the<br />
model animation XML file should be added as comment to the YASim config file, as a line all by<br />
itself, with no spaces surrounding the equal signs. Spaces elsewhere are allowed. For example:<br />
<br />
<offsets><br />
<x-m>3.45</x-m><br />
<z-m>-0.4</z-m><br />
<pitch-deg>5</pitch-deg><br />
</offsets><br />
<br />
becomes:<br />
<br />
<!-- offsets: x=3.45 z=-0.4 p=5 --><br />
<br />
Possible variables are:<br />
<br />
x ... <x-m><br />
y ... <y-m><br />
z ... <z-m><br />
h ... <heading-deg><br />
p ... <pitch-deg><br />
r ... <roll-deg><br />
<br />
Of course, absolute FDM coordinates can then no longer directly be read from Blender's 3D view.<br />
The cursor coordinates display in the script area, however, shows the coordinates in YASim space.<br />
Note that object names don't contain XML indices but element numbers. YASim_hstab#2 is the third<br />
hstab in the whole file, not necessarily in its parent XML group. A floating-point part in the<br />
object name (e.g. YASim_hstab#2.004) only means that the geometry has been reloaded that often.<br />
It's an unavoidable consequence of how Blender deals with meshes.<br />
<br />
<br />
Elements are displayed as follows:<br />
<br />
cockpit -> monkey head<br />
fuselage -> blue "tube" (with only 12 sides for less clutter); center at "a"<br />
vstab -> red with yellow flaps<br />
wing/mstab/hstab -> green with yellow flaps/spoilers/slats (always 20 cm deep);<br />
symmetric surfaces are only displayed on the left side<br />
thrusters (jet/propeller/thruster) -> dashed line from center to actionpt;<br />
arrow from actionpt along thrust vector (always 1 m long);<br />
propeller circle<br />
rotor -> radius and rel_len_blade_start circle, direction arrow,<br />
normal and forward vector, one blade at phi0<br />
gear -> contact point and compression vector (no arrow head)<br />
tank -> cube (10 cm side length)<br />
weight -> inverted cone<br />
ballast -> cylinder<br />
hitch -> circle (10 cm diameter)<br />
hook -> dashed line for up angle, T-line for down angle<br />
launchbar -> dashed line for up angles, T-line for down angles<br />
A note about step (0) for Windows users: the mentioned path is inside the folder where Blender lives, something like <code>C:\Program Files\Blender Foundation\Blender\.blender\scripts</code>.<br />
<br />
=== Visualize model in OpenSCAD or FreeCAD ===<br />
<br />
There exist a possibility to display the YASim XML elements in the OpenSCAD or FreeCAD tools. This could be extremely useful in the case of UAV aircraft development. <br />
<br />
* [https://github.com/ThunderFly-aerospace/YASim2SCAD YASim2SCAD] - This tool converts YASim XML to scad file which could be displayed as an overlay in OpenSCAD or FreeCAD project.<br />
* [https://gitlab.com/yasimtoscad/yasimtoscad yasimtoscad] - Another tool to convert YASim XML to scad file which could be displayed as an overlay in OpenSCAD.<br />
<br />
<br />
=== Visualization tools ===<br />
<br />
* [https://github.com/bitwisetech/ysimi YSIMI] Interactive Tuning Tools for FlightGear's YASIM Flight Dynamics Model<br />
* [https://github.com/bitwisetech/yasiVers yasiVers] is a tool for visualization of YASim calculations.<br />
<br />
== Export of YASim internals to property tree ==<br />
Ever wondered what is going on inside yasim? See the property tree under /fdm/yasim/<br />
<br />
Some information is static and shows what yasim has compiled from your XML. <br />
Other information is "run-time" like forces, speed, acceleration, c.g. <br />
<br />
If note noted otherwise:<br />
* expect metric unit (meter, kilogram, newton, ...)<br />
* expect minimum version 2017.2<br />
<br />
{| class="wikitable"<br />
|-<br />
! Path !! Description !! Information type !! min. version<br />
|-<br />
| accelerations/ || linear and rot. accelerations in aircraft coord. || run time ||<br />
|-<br />
| debug/ || misc internals, for now subject to change without notice || run time || 2018.1<br />
|-<br />
| forces/ || aerodynamic forces in N || run time ||<br />
|-<br />
| velocities/ || linear and rot. velocities in aircraft coord. || run time ||<br />
|-<br />
| model/cg-x-range-aft || desired CG range || compile time ||<br />
|-<br />
| model/cg-x-range-front || desired CG range || compile time ||<br />
|-<br />
| model/cg-x-max || CG hard limit from gear position || compile time ||<br />
|-<br />
| model/cg-x-min || CG hard limit from gear position || compile time ||<br />
|-<br />
| model/masses || shows the calculated mass points || compile time ||<br />
|-<br />
| model/wings || wing parameters || compile time ||<br />
|}<br />
<br />
<br />
== Command Line ==<br />
=== Windows ===<br />
By using the standard command line, we can see what the YASim solver is calculating. First, open up Command Prompt, enter in the location of yasim.exe, and then the location of the YASim XML file. For example, here's what you would type in for a standard Windows [[Changelog_2.12|FlightGear 2.12.0]] installation, and viewing the [[F-14_Tomcat|F-14B's]] YASim file.<br />
{{Note|You can copy & paste the examples into Command Prompt by right-clicking on the title and navigate to Edit > Paste. Then, click Enter to execute.}} <br />
<br />
<code>"C:\Program Files\FlightGear\bin\Win32\yasim.exe" "C:\Program Files\FlightGear\data\Aircraft\f-14b\f-14b-yasim.xml"</code><br />
<br />
The results will give many different values.<br />
<br />
* '''Drag Coefficient:''' The drag coefficient of the aircraft.<br />
* '''Lift Ratio:''' The lift ratio of the aircraft.<br />
* '''Cruise AoA:''' The cruise AoA, from conditions at [[YASim#cruise|<cruise>]] in the xml file.<br />
* '''Tail Incidence:''' The incidence angle of the tail, "solved" by YASim as a way to stabilize the aircraft.<br />
* '''Approach Elevator:''' The approach elevator, from conditions at [[YASim#approach|<approach>]] in the xml file.<br />
* '''CG:''' Center of gravity of the aircraft in coordinates. Unless it's supposed to be offset, it should always have a Y value of 0.<br />
<br />
The YASim standalone solver also has some command line flags that change it's behaviour.<br />
<br />
<code>"C:\Program Files\FlightGear\bin\Win32\yasim.exe" "C:\Program Files\FlightGear\data\Aircraft\f-14b\f-14b-yasim.xml" -g -a 1000 -s 490</code><br />
<br />
* '''-g:''' Instructs YASim to generate space-separated tabular data instead of the usual solver output. This can be redirected to a file and used in various plotting programs to visualize the actual lift, drag, L/D curves. The columns of the output from left to right are: AoA, Lift, Drag, L/D. (aoa in degrees, lift and drag in G's).<br />
* '''-a <altitude in meter:>''' Run the solver at the given altitude in meter.<br />
* '''-s <speed in knots>:''' Also run at the given airspeed in knots.<br />
<br />
{{Note|The values generated by this method are for the aircraft taken as a whole, as solved by YASim, so they differ from the values of the wing airfoil.}}<br />
<br />
To get the tabular output for the example above at 1000 m and 150 knots, and to redirect this to a file, one would issue:<br />
<br />
<code>"C:\Program Files\FlightGear\bin\Win32\yasim.exe" "C:\Program Files\FlightGear\data\Aircraft\f-14b\f-14b-yasim.xml" -g -a 1000 -s 150 > "C:\Program Files\FlightGear\yasim.txt"</code><br />
<br />
== New features and bugfixes in version 2017.2 ==<br />
<br />
=== XML parser ===<br />
==== support for metric and imperial units ====<br />
To make life easier for aircraft developers, the parser supports new additional attributes with a unit suffix, e.g. speed-kt for knots and speed-kmh for kilometers per hour.<br />
* <code><airplane {mass, mass-lbs, mass-kg}="12345" ></code><br />
* <code><approach {speed, speed-kt, speed-kmh}="123" ></code><br />
* <code><cruise {speed, speed-kt, speed-kmh}="123" ></code><br />
* <code><solve-weight {weight, weight-lbs, weight-kg}="123" ></code><br />
* <code><jet {mass, mass-lbs, mass-kg}="1234" ></code><br />
* <code><tank {capacity, capacity-lbs, capacity-kg}="12345" ></code><br />
* <code><ballast {mass, mass-lbs, mass-kg}="1234" ></code><br />
<br />
{{Note|Aircraft using this new attributes will not run on older versions of FlightGear, so it is probably wise to publish those only after a reasonable number of users switched version 2017.2 or newer.}}<br />
<br />
==== CG tuning help ====<br />
{{Note| The feature described in this section is not fully implemented yet, however, it may be of some help already.<br />
It is currently implemented for the yasim CLI tool only. It does not affect the airplane behaviour while running FlightGear. }}<br />
<br />
New attributes have been added to <airplane> to assist tuning the center of gravity (CG).<br />
The CG position is often expressed relative to the [https://en.wikipedia.org/wiki/Chord_(aeronautics)#Mean_aerodynamic_chord MAC] of the wing in percent. You can specify a desired range for CG in % relative to MAC, it will show up in the output of the yasim CLI tool (see example below):<br />
<br />
* cg-min: default 25% (just a guess, better numbers are welcome)<br />
* cg-max: default 30% (just a guess, better numbers are welcome)<br />
<br />
{{Note| By convention 0% is leading edge, 100% is trailing edge, however the absolute values on x-axis are the other way round, e.g. nose is +x, tail is -x }}<br />
{{warning|The MAC calculation in version 2017.2 works only on the <wing> element. Numbers will be wrong, if your model uses a combination of <wing> and <mstab> to build a wing with two or more sections.<br />
Section support will be added in version 2018.1}}<br />
YASim will print the leading edge coordinates of the MAC (x,y) and its length.<br />
<br />
'''Example output'''<br />
<pre><br />
$ yasim Citation-II-yasim.xml <br />
This aircraft uses yasim version '2017.2' <br />
========================== <br />
= YASim solution results = <br />
========================== <br />
Iterations: 2210 <br />
Drag Coefficient: 12.304669 <br />
Lift Ratio: 85.317558 <br />
Cruise AoA: 4.016746 deg <br />
Tail Incidence: -3.053278 deg <br />
Approach Elevator: -0.377542 <br />
<br />
CG: x:-6.543, y:-0.000, z:0.044 <br />
Wing MAC (*1): x:-6.00, y:3.83, length:2.0 <br />
CG-x rel. MAC: 0.272 <br />
CG-x desired: -6.599 < -6.543 < -6.198 <br />
<br />
Inertia tensor [kg*m^2], origo at CG: <br />
<br />
18009.289, -0.000, 7120.470 <br />
-0.000, 42459.316, 0.000 <br />
7120.470, 0.000, 56980.656 <br />
<br />
(*1) MAC calculation works on <wing> only! Numbers will be wrong for segmented wings, e.g. <wing>+<mstab>.<br />
</pre><br />
<br />
=== Aircraft developer helpers ===<br />
The command line utility got some new options. For some strange reason, the -a parameter expects altitude in meters instead of ft. This is now visible in the usage message but left unchanged for compatibility.<br />
<syntaxhighlight>Usage:<br />
yasim <aircraft.xml> [-g [-a meters] [-s kts] [-approach | -cruise] ]<br />
yasim <aircraft.xml> [-d [-a meters] [-approach | -cruise] ]<br />
yasim <aircraft.xml> [-m]<br />
-g print lift/drag table: aoa, lift, drag, lift/drag <br />
-d print drag over TAS: kts, drag<br />
-a set altitude in meters!<br />
-s set speed in knots<br />
-m print mass distribution table: id, x, y, z, mass</syntaxhighlight><br />
<br />
=== Bugfixes ===<br />
The following bugfixes require <airplane version="2017.2"> for backward compatibility <br />
* Ground effect: corrected the calculation of the height where g.e. ends<br />
* Stall parameters were set wrong for wings with camber=0<br />
<br />
== New features and bugfixes in version 2018.1 ==<br />
The following is under development and hopefully finds its way into FG version 2018.1<br />
<br />
=== Wing Section Support ===<br />
Many airliners have wings with a geometry that is just a little more complex than what YASim supported initially (tapered wing with some angles like sweep, dihedral, ...), e.g. they have an inboard section and an outboard section that can be described with YASim wing syntax. You can use a wing + a mstab XML element to describe this geometry but it is easier if YASim can just append more wing sections by simply adding more wing XML elements. This is now (Version 2018.1) possible, yasim will simply append sections if it finds more than one wing or hstab in the XML.<br />
You should use '''&lt;wing append="1" ... &gt;''' for all but the first wing/hstab declaration. <br />
{{Note|YASim will ignore the root point (x,y,z), the chord length and the incidence attributes, if you add "append" and calculate those from the previous wing section. }}<br />
MAC calculation works for the whole wing.<br />
<br />
{{warning|Aircrafts using this feature will not work with older versions of flightgear. }}<br />
To keep the aircraft backward compatible for a while, it is recommended to create a copy of its yasim XML file for development. <br />
Once you are happy with the CG and wing parameters you can use the output of the YASim CLI tool to modifiy the original XML. <br />
The tool will output the needed x,y,z etc per wing section to create a XML in old format with (only one) <wing> + <mstab>.<br />
<br />
=== More information from CLI tools ===<br />
You should configure the maximum take of weight (MTOW) in your XML file by adding either ''mtow-lbs'' or ''mtow-kg'' attribute to the airplane:<br />
<br />
<code> &lt;airplane mass="7500" version="2018.1" mtow-lbs="12500"&gt; </code><br />
<br />
'''Example output'''<br />
<pre><br />
yasim CRJ700.xml <br />
==========================<br />
= YASim solution results =<br />
==========================<br />
Iterations : 1024<br />
Drag Coefficient : 17.707<br />
Lift Ratio : 145.841<br />
Cruise AoA : -0.11 deg<br />
Tail Incidence : 3.47 deg<br />
Approach Elevator : -0.792<br />
<br />
CG : x:-0.046, y:0.000, z:-1.222<br />
Wing MAC : (x:0.79, y:4.99), length:3.4 <br />
hard limit CG-x : 14.232 m<br />
soft limit CG-x : -0.058 m<br />
CG-x : -0.046 m<br />
CG-x rel. MAC : 25%<br />
soft limit CG-x : -0.228 m<br />
hard limit CG-x : -0.986 m<br />
<br />
wing lever : -0.012 m<br />
tail lever : -13.997 m<br />
<br />
max thrust : 157.18 kN<br />
thrust/empty : 0.81<br />
thrust/mtow : 0.49<br />
<br />
wing span : 22.64 m<br />
sweep lead. edge : 30.2 .. 30.6 deg<br />
wing area : 58.70 m^2<br />
wing load empty : 336.15 kg/m^2 (Empty 19731 kg)<br />
wing load MTOW : 562.18 kg/m^2 (MTOW 32999 kg)<br />
<br />
tail span : 8.533 m<br />
tail area : 14.838 m^2<br />
<br />
#wing sections: 2<br />
Section 0 base point (0.450, 1.226, -2.034), chord 5.085, incidence at section root 5.0deg<br />
Section 1 base point (-0.663, 4.754, -1.942), chord 3.204, incidence at section root 3.0deg<br />
<br />
Inertia tensor [kg*m^2], origo at CG:<br />
<br />
195646, 0, 122265<br />
0, 1757279, 0<br />
122265, 0, 1904528<br />
</pre><br />
<br />
=== Variable tail incidence / elevator trim ===<br />
Small GA aircrafts usually trim with a trim tab on the elevator. For efficiency, airliners normally do not trim the elevator ("flap") <br />
but rotate the whole stabilizer (=tail) wing, e.g. they change the incidence for this wing. While this feature was somehow foreseen, <br />
it was not implemented yet, most likely because the "tail incidence" is one of the free variables used by the YASim solver. <br />
However, it is possible now to use the control="INCIDENCE" within the &lt;hstab&gt; to implement an alternative trim '''while maintaining full elevator authority'''.<br />
<pre><br />
<hstab ... incidence-min-deg="-13.0" incidence-max-deg="2.0"><br />
...<br />
<control-input axis="/controls/flight/hstab-trim" control="INCIDENCE" /><br />
<control-speed control="INCIDENCE" transition-time="20.0" /><br />
<control-output control="INCIDENCE" prop="/surface-positions/hstab-rad" /> <br />
</hstab><br />
</pre><br />
{{Note|The control output of INCIDENCE is the angle in radians, not in degree, as that is the unit internally used by YASim.}}<br />
{{warning|The OPTIONAL incidence-min-deg and incidence-max-deg set the limits for the solver. You must make sure to select a sufficiently large range or solver will fail. }}<br />
First experiments with this feature were successful in that the aircraft pitch could be changed as expected but fine tuning will be necessary.<br />
<br />
<br />
== Related content ==<br />
* [[Howto:Make a helicopter#XML Elements]] &ndash; Rotor and rotorgear YASim elements<br />
* [[Towing]]<br />
* [[YASim Development Tools]]<br />
<br />
== External links ==<br />
* {{cite web<br />
| url = http://www.buckarooshangar.com/flightgear/yasimtut.html<br />
| title = Guide to YASim<br />
| first = Gary R. "Buckaroo"<br />
| last = Neely<br />
| authorlink = http://www.buckarooshangar.com/flightgear/<br />
| date = 2013<br />
| accessdate = April 16, 2020<br />
}} - A very helpful guide<br />
* {{cite web<br />
| url = https://sourceforge.net/projects/dacpei/<br />
| title = DACPEI<br />
| author = pytoche<br />
| date = February 2012<br />
| publisher = SourceForge<br />
| accessdate = April 16, 2020<br />
}} - A fixed wing light aircraft WYSIWUG concept design suite that can export an YASim FDM to FlightGear.<br />
<br />
{{FDM}}<br />
<br />
[[Category:Flight Dynamics Model]]<br />
<br />
[[fr:YASim]]</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=Howto:Animate_models&diff=134675Howto:Animate models2022-02-15T22:58:01Z<p>Cgdae: /* Tracking */</p>
<hr />
<div>The real world is full of motion. To simulate this in [[FlightGear]], '''models must be animated'''.<br />
<br />
FlightGear allows you to animate models 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. <br />
<br />
This document provides basic information for all kind of animations. When animating your model, it is very helpful to find an aircraft with parts similar to yours and use it as an example. Cut and paste the code into your wrapper file and then edit to suit.<br />
<br />
== Notes ==<br />
=== File name of main model and animation XML file ===<br />
{{main article|Aircraft-set.xml#Not used for loading multiplayer aircraft}}<br />
The file name of the main model and animation XML file, or the .ac file if there is no XML file, (in essence the property <code>/sim/model/path</code>) will be the name of the aircraft that is transmitted when using [[multiplayer]] and will also be used for loading multiplayer aircraft.<br />
<br />
There is also a mechanism to substitute a full aircraft model with a simpler AI aircraft model if one is available at the same file path (including for example <code>Models/Boeing-797-800.xml</code>), but in <code>[[$FG_ROOT]]/'''AI'''/Aircraft/</code> instead of <code>$FG_ROOT/Aircraft/</code>.<br />
<br />
=== .ac files ===<br />
{{Main article|AC files: Understanding and changing .ac code#Identifying an object}}<br />
<br />
When referring to an .ac file in your xml animation, it is important that the <code><object-name></code> exactly matches the object named in the .ac file (this includes cases!). <br />
<br />
'''Note for SketchUp users:''' The spatial reference X/Y/Z used in animation to locate an object or a point are different from the ones in AC3D ie X values are the same in both but Y in animation must be matched to AC3D's -Z (Z value but opposite sign) and Z value in animation must be matched to AC3D's Y value. <br />
<br />
'''Note for SketchUp users:''' when exporting to AC3D in Sketchup, the .ac file will name the objects in your model to "blah" by default. You need to amend the relevant object names in your .ac file using text edit, so that the xml will work.<br />
<br />
=== Animation order ===<br />
Animations are executed by FlightGear in the order that they are read in the model's .xml file. Therefore, it is very important to pay attention to the order, especially when multiple animations are applied to the same object(s). Wrong ordering of animations might cause [[Howto:Animate models#Timed|timed]] animations (used to create flashing lights) to not work. For further details see this [https://sourceforge.net/p/flightgear/mailman/message/37090714/ thread] on the development mailing list. Updated [https://scenery.flightgear.org/app.php?c=Models&a=browse&shared=18 shared Effects models] will be available very soon.<br />
<br />
Similar problems can be encountered with the dist-scale instead of the timed animation.<br />
== Tags used in most animations ==<br />
=== Name ===<br />
With a name animation, you can group multiple objects. <br />
<br />
<source><br />
<animation><br />
<name>Collection1</name><br />
<object-name>Object1</object-name><br />
<object-name>Object2</object-name><br />
<object-name>Object3</object-name><br />
</animation><br />
</source><br />
<br />
The example above creates a "virtual object" with the name Collection1. In animation, we can animate this group of objects, by using:<br />
<br />
<source><br />
<object-name>Collection1</object-name><br />
</source><br />
<br />
=== Object-name ===<br />
These names are set in the 3D model. Each single object has a unique name; for easy identification it is advised to use descriptive names (LeftElevator, Rudder etc.). Animations are only applied to those objects that are mentioned in an object-name line (one object per line!). Animations lacking those, will be applied to the entire model.<br />
<br />
=== Property ===<br />
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 <code><property></code> to provide the property path:<br />
<br />
<source><br />
<animation><br />
<type>rotate</type><br />
<object-name>Rudder</object-name><br />
<property>controls/rudder</property><br />
</animation><br />
</source><br />
<br />
Note the omission of the leading slash '/' when referring to the property. This assures that when the model is used for AI or multiplayer traffic the animations will follow that of the AI controller instead of that of the user.<br />
<br />
=== Axis ===<br />
An axis part is required in every animation that involves a rotating or moving thing.<br />
<br />
<source><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</source><br />
<br />
The axis are similar to the ones of the 3D model. There is a difference between rotation and translation:<br />
* In rotation animations, the axis part defines around what axis the object rotates. Negative/positive values make the difference between counterclockwise and clockwise rotations.<br />
* In translate animations, the part defines along what axis the object moves. If the x-axis is poiting backwards, an x-value of -1 will result in forward motion.<br />
<br />
You could also define two points, between which FlightGear will calculate the correct axis. This makes the use of a [[#Center|<nowiki><center></nowiki>]] tag redundant! Such coordinates are extremely useful for animating control surfaces (rudder, elevators etc.).<br />
<br />
<source><br />
<axis> <br />
<x1-m> 4.9</x1-m><br />
<y1-m> 7.1</y1-m><br />
<z1-m>-1.0</z1-m><br />
<x2-m> 5.9</x2-m><br />
<y2-m>11.2</y2-m><br />
<z2-m>-0.5</z2-m><br />
</axis><br />
</source><br />
<br />
=== Center ===<br />
Various animations ([[#Rotate|rotate]], [[#Spin|spin]], [[#Scale|scale]]) move around a center point.<br />
<br />
<source><br />
<center><br />
<x-m>-1.50</x-m><br />
<y-m> 1 </y-m><br />
<z-m> 0.25</z-m><br />
</center><br />
</source><br />
<br />
The axis are similar to the ones of the 3D model, so finding coordinates is easily done in 3D modeling software.<br />
<br />
=== Using a geometry object for axis and centre (2017.2) ===<br />
<br />
Added in V2017.2 is support to allow a geometry object (a line segment with two vertices) that is used to define both the centre and the axis for an animation. This will work with rotate, translate and the knob animations.<br />
<br />
The axis line should be balanced, i.e. it should protrude equal amounts. The axis line should be normalized (i.e. 1m) as its length acts as a factor (affecting translate animations).<br />
<br />
The XML syntax for this is:<br />
<br />
<source><br />
<axis><br />
<object-name>some-object</object-name><br />
</axis><br />
</source><br />
<br />
If the <code><axis>...</axis></code> section is omitted entirely, <code>{object-name}-axis</code> will be used by default, where <code>{object-name}</code> is the name of the object being animated (if we are animating more than one object, the first object is used). In the earlier example this would be <code>Rudder-axis</code>.<br />
<br />
In the '''.ac''' file, specify a SURF with type (bottom 4 bits, 0=polygon, 1=closedline, 2=line) set to 2, and two vertices that define the axis. For example:<br />
<br />
OBJECT poly<br />
name "aileron.l-axis"<br />
numvert 2<br />
3.2077502191170844 0.18160835055097943 4.055616960642423<br />
2.6758650763079 0.28024033462188946 6.477876098622225<br />
numsurf 1<br />
SURF 0x12<br />
mat 0<br />
refs 2<br />
0 0 0<br />
1 0 0<br />
kids 0<br />
<br />
Once the object-name used for the axis has been processed the geometry object will be hidden. This also allows a visual check for any axis objects that are not yet assigned.<br />
<br />
It is possible to reuse the same object definition multiple times within a single XML file. <br />
<br />
[[File:Canopy-animation-axis-object.png|small|Illustration of where an axis object (2017.2) can be placed for a canopy]]<br />
<br />
[[File:Gauges-knobs-animation-axis-object.png|small|Illustration of where an axis object (2017.2) can be placed for cockpit elements]]<br />
<br />
== Additional tags that can be used in most animations ==<br />
=== Conditions ===<br />
Multiple animations can make use of a conditional. Check <tt>$FGDATA/Docs/README.conditions</tt> for some more details.<br />
<br />
* '''equals:''' property value (or second property) is equal to value/(first)property.<br />
* '''greater-than:''' property value (or second property) is larger than value/(first)property.<br />
* '''greater-than-equals:''' property value (or second property) is greater than or equal to value/(first)property.<br />
* '''less-than:''' property value (or second property) is smaller than value/(first)property.<br />
* '''less-than-equals:''' property value (or second property) is smaller than or equal to value/(first)property.<br />
<br />
The example below is true when n1 has a value greater than 25.<br />
<source><br />
<condition><br />
<greater-than><br />
<property>engines/engine[1]/n1</property><br />
<value>25</value><br />
</greater-than><br />
</condition><br />
</source><br />
<br />
Then there are some special tags:<br />
<br />
* '''and:'''<br />
* '''not:'''<br />
* '''or:'''<br />
<br />
In the example below, the condition is true when either n1 is greater than 25% or equal to 0%.<br />
<source><br />
<condition><br />
<or><br />
<greater-than><br />
<property>engines/engine[1]/n1</property><br />
<value>25</value><br />
</greater-than><br />
<equals><br />
<property>engines/engine[1]/n1</property><br />
<value>0</value><br />
</equals><br />
</or><br />
</condition><br />
</source><br />
<br />
An example of implementation into an animation looks as follows:<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>rotate</type><br />
<property>suface-positions/left-aileron-pos-norm</property><br />
<factor>25</factor><br />
<condition><br />
<greater-than><br />
<property>suface-positions/left-aileron-pos-norm</property><br />
<value>10</value><br />
</greater-than><br />
</condition><br />
<center><br />
<x-m>-1.50</x-m><br />
<y-m> 1 </y-m><br />
<z-m> 0.25</z-m><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
=== Interpolation ===<br />
For non-fixed factors, an interpolation "table" can be created. <br />
<br />
<source><br />
<interpolation><br />
<entry><br />
<ind> 0.0</ind><br />
<dep> 0.0</dep><br />
</entry><br />
<entry><br />
<ind> 0.667</ind><br />
<dep> 0.0</dep><br />
</entry><br />
<entry><br />
<ind> 1.0</ind><br />
<dep> 0.5</dep><br />
</entry><br />
</interpolation><br />
</source><br />
<br />
The lines above represent the following table:<br />
<br />
{|<br />
!Input<br />
!Output<br />
|-<br />
|0.0<br />
|0.0<br />
|-<br />
|0.667<br />
|0.0<br />
|-<br />
|1.0<br />
|0.5<br />
|}<br />
<br />
You can add as many entries as you need. Interpolation tables are often used for gear animations (eg. to open doors during gear-movements and close them again once the gear is either retracted or fully extended).<br />
<br />
=== Expressions ===<br />
For some animations it is possible to define complex animations by using [[Expressions|Expressions]]. This even allows to drive the animation from multiple properties without the need for additional Nasal scripts. Here is an example for a translate animation depending on two properties and the cosine function:<br />
<syntaxhighlight lang="xml"><br />
<animation><br />
<type>translate</type><br />
<expression><br />
<product><br />
<property>/my/factor-property</property><br />
<cos><br />
<deg2rad><br />
<property>/my/angular-property</property><br />
</deg2rad><br />
</cos><br />
</product><br />
</expression><br />
[..]more elements[..]<br />
</animation><br />
</syntaxhighlight><br />
<br />
Animations which can utilize [[Expressions|Expressions]] are: <br />
* [[Howto:Animate_models#Translate|Translate]]<br />
* [[Howto:Animate_models#Rotate|Rotate]]<br />
* [[Howto:Animate_models#Scale|Scale]]<br />
* [[Howto:Animate_models#Range|Range]]<br />
* [[Howto:Animate_models#Blend|Blend]]<br />
<br />
See more detailed info at [[Expressions|Expressions]]<br />
<br />
== Lights ==<br />
As of January 2021 FlightGear supports multiple light sources just like Project Rembrandt has always done.<br />
[[Compositor#Lights|Adding lights to a model]]<br />
<br />
== Object animations ==<br />
=== Alpha-test ===<br />
<source><br />
<animation><br />
<type>alpha-test</type><br />
<object-name>Object</object-name><br />
<alpha-factor>0.01</alpha-factor><br />
</animation><br />
</source><br />
This "animation" is a way to set an alpha test on a model branch. The effect is to avoid depth buffer writing of pixel that are not seen because they are transparent. This is particulary useful when modeling a metallic structure or a tree with a billboard. The threshold of transparency is set with the <alpha-factor> element. See also [[Pixel testing in effects]].<br />
<br />
=== Blend ===<br />
Blends an object with the surrounding. Comparable to a translucency animation. A value of 0 corresponds to no transparency, i.e. and ordinary solid object, and a value of 1 makes the object fully transparent, i.e., not visible at all.<br />
<br />
<source><br />
<animation><br />
<type>blend</type><br />
<property>/velocities/airspeed-kt</property><br />
<factor>0.00025</factor><br />
<min>0.2</min><br />
<max>0.7</max><br />
</animation><br />
</source><br />
<br />
* '''property:'''<br />
* '''factor:'''<br />
* '''min:'''<br />
* '''max:'''<br />
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]<br />
<br />
Note that when using the Project Rembrandt renderer, all transparent and translucent objects must be registered to display properly. [[Project_Rembrandt#Registering_all_translucent_surfaces|More information here.]]<br />
<br />
=== Billboard ===<br />
This faces an object towards the viewer. Often used on 2D objects, like clouds, trees and lights.<br />
<br />
<source><br />
<animation><br />
<type>billboard</type><br />
<object-name>Object</object-name><br />
<spherical type="bool">true</spherical><br />
</animation><br />
</source><br />
<br />
* '''spherical:'''<br />
<br />
=== Dist-scale ===<br />
Used to scale an object, based on the distance to the viewer. <code><nowiki><ind></nowiki></code> and <code><nowiki><dep></nowiki></code> (independent and dependent) are the distance in meters and the scale at that distance.<br />
<br />
<source><br />
<animation><br />
<type>dist-scale</type><br />
<object-name>Object</object-name><br />
<interpolation><br />
<entry><br />
<ind>0</ind><br />
<dep>1</dep><br />
</entry><br />
<entry><br />
<ind>300</ind><br />
<dep>4</dep><br />
</entry><br />
<entry><br />
<ind>1500</ind><br />
<dep>8</dep><br />
</entry><br />
</interpolation><br />
</animation><br />
</source><br />
<br />
You can optionally add [[#Center|&lt;center&gt;]] coordinates, to scale the object around that point.<br />
<br />
=== Flash ===<br />
<br />
Used to scale an object based on the cosine of the angle between the axis provided in the animation and the view vector.<br />
<br />
<source><br />
<animation><br />
<type>flash</type><br />
<object-name>Object</object-name><br />
<offset>0.0</offset><br />
<factor>1.0</factor><br />
<power>2</power><br />
<two-sides type="bool">false</two-sides><br />
<min>0.0</min><br />
<max>1.0</max><br />
<center><br />
<x-m>0.0</x-m><br />
<y-m>0.0</y-m><br />
<z-m>0.0</z-m><br />
</center><br />
<axis><br />
<x>0.0</x><br />
<y>-1</y><br />
<z>0.1</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
* '''offset:'''<br />
* '''factor:'''<br />
* '''power:'''<br />
* '''two-sides:''' if false, nothing is drawn if the cosine is negative.<br />
* '''min:'''<br />
* '''max:'''<br />
<br />
scale = factor * pow( cosine, power ) + offset<br />
<br />
scale is then clamped between min and max.<br />
<br />
and this scale factor is applied to the object, from the center specified. It works best if scale is less than 1. Otherwise, there will be clipping issues.<br />
<br />
=== Noshadow ===<br />
This animation is used to make sure an object will cast no shadow.<br />
<br />
<source><br />
<animation><br />
<type>noshadow</type><br />
<object-name>Object</object-name><br />
</animation><br />
</source><br />
<br />
=== Range ===<br />
: ''See also [[Modeling - Getting Started#Level of Detail (LOD)]].''<br />
<br />
To prevent objects -like instruments- being drawn when the aircraft is actually too far away for them to be seen anyway, a range animation is used. <br />
<br />
<syntaxhighlight lang="xml"><br />
<animation><br />
<type>range</type><br />
<min-m>0</min-m><br />
<max-m>30</max-m><br />
</animation><br />
</syntaxhighlight><br />
<br />
* '''min-m:''' the shortest distance (in meters) from the object center at which it is visible.<br />
* '''max-m:''' the largest distance (in meters) from the object center at which it is visible.<br />
<br />
You could also use the generic level of detail (LOD) properties, which can be set by the user through View > Adjust LOD rangers: <br />
{| class="wikitable"<br />
! Property<br />
! Description<br />
! Default value<br />
|-<br />
|<tt>/sim/rendering/static-lod/bare</tt><br />
| only a rough exterior model<br />
| 30,000 m<br />
|-<br />
|<tt>/sim/rendering/static-lod/rough</tt> <br />
| most should be visible<br />
| 9,000 m<br />
|-<br />
|<tt>/sim/rendering/static-lod/detailed</tt> <br />
| all details should be visible<br />
| 1,500 m<br />
|}<br />
<br />
The animation code will look like this:<br />
<syntaxhighlight lang="xml"><br />
<animation><br />
<type>range</type><br />
<min-m>0</min-m><br />
<max-property>sim/rendering/static-lod/bare</max-property><br />
</animation><br />
</syntaxhighlight><br />
<br />
You can have both ranges (max and min) bound to a property, or just one of them.<br />
* '''min-property:''' <br />
* '''max-property:'''<br />
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]<br />
<br />
=== Rotate ===<br />
One of the most important and frequently used animations of all. It rotates an object to an absolute position in degrees, as provided by the property-value.<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>rotate</type><br />
<property>surface-positions/left-aileron-pos-norm</property><br />
<factor>25</factor><br />
<offset-deg>25</offset-deg><br />
<center><br />
<x-m>-1.50</x-m><br />
<y-m> 1 </y-m><br />
<z-m> 0.25</z-m><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
* '''factor:''' is optional.<br />
* '''offset-deg:''' is optional. Offset in degrees.<br />
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]<br />
<br />
=== Scale ===<br />
A scale animation scales (resizes) an object. This can be either property-value dependant (first example) or a fixed scale (second example).<br />
<br />
<source><br />
<animation><br />
<type>scale</type><br />
<object-name>Object</object-name><br />
<property>sim/time/sun-angle-rad</property><br />
<x-min>1.0</x-min><br />
<y-min>1.0</y-min><br />
<z-min>1.0</z-min><br />
<x-factor>1.4</x-factor><br />
<y-factor>1.4</y-factor><br />
<z-factor>2.0</z-factor><br />
</animation><br />
</source><br />
<br />
* ?-min: the mimimum scale factor for each axis. If the property value would result in a smaller factor than this setting, the scale animation will hold.<br />
* ?-factor: the scale factor for each axis (factor*property=scale factor).<br />
<br />
<source><br />
<animation><br />
<type>scale</type><br />
<x-offset>0.5</x-offset><br />
<y-offset>0.5</y-offset><br />
<z-offset>0.5</z-offset><br />
</animation><br />
</source><br />
<br />
* x.offset: the scale factor.<br />
* Add [[#Center|&lt;center&gt;]] coordinates, to scale the object around that point.<br />
* '''You can optionally use an [[Howto:Animate_models#Expressions|expression]] in the <factor> or <offset> inputs.''' For more details see [[Expressions|Expressions]]<br />
<br />
=== Select ===<br />
This animation selects (or unselects) objects when certain conditions are true (or false). The example below shows the object when the n1 of engine[1] is higher than 25%.<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>select</type><br />
<condition><br />
<greater-than><br />
<property>engines/engine[0]/n1</property><br />
<value>25</value><br />
</greater-than><br />
</condition><br />
</animation><br />
</source><br />
<br />
=== Shader ===<br />
<source><br />
<animation><br />
<type>shader</type><br />
<shader>chrome</shader><br />
<texture>chrome2.png</texture><br />
<object-name>Object</object-name><br />
</animation><br />
</source><br />
<br />
* '''shader:''' <br />
* '''texture:''' path to the texture used by the shader.<br />
<br />
=== Spin ===<br />
Very similar to [[#Rotate|rotate]], but the property provides a value in revolutions per minute (RPM) rather than an absolute position in degrees, and offset cannot be used.<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>spin</type><br />
<property>engines/engine[0]/n1</property><br />
<factor>25</factor><br />
<center><br />
<x-m>-1.50</x-m><br />
<y-m> 1 </y-m><br />
<z-m> 0.25</z-m><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
* '''factor:''' is optional.<br />
<br />
=== Timed ===<br />
Swtiches between objects at specified intervals. This example switches between a lights-on model and a lights-off model. Lights on are shown 0.2 seconds, while lights off are displayed for 0.8 seconds.<br />
<br />
<source><br />
<animation><br />
<type>timed</type><br />
<object-name>BacklightOn</object-name><br />
<object-name>BacklightOff</object-name><br />
<use-personality type="bool">true</use-personality><br />
<branch-duration-sec>0.8</branch-duration-sec><br />
<branch-duration-sec>0.2</branch-duration-sec><br />
</animation><br />
</source><br />
<br />
=== Tracking ===<br />
A ''locked-track animation'' can do exactly the same thing as the [https://docs.blender.org/manual/en/latest/animation/constraints/tracking/locked_track.html Locked Track constraint] available in Blender and can also be used to simulate simple inverse kinematic systems consisting of two bones connected with a revolute joint (aka hinge). For details see: [[Howto:Animate gear scissors using the tracking animation]]<br />
<br />
=== Translate ===<br />
The same as [[#Textranslate|textranslate]], but this animation moves a whole object (so including fixed textures). The example below will move an object in the y-direction:<br />
<br />
{| class="wikitable" border="0" cellspacing="0" <br />
!Property value<br />
!Output<br />
|-<br />
| -1<br />
| -2.5<br />
|-<br />
| 0<br />
| 2.5<br />
|-<br />
| 1<br />
| 7.5<br />
|}<br />
<br />
<source><br />
<animation><br />
<type>translate</type><br />
<object-name>Object</object-name><br />
<property>controls/seat/pilot/position-norm</property><br />
<factor>5</factor><br />
<offset-m>2.5</offset-m><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
When using interpolation tables such as:<br />
<source><br />
<interpolation><br />
<entry><ind>0.0</ind><dep> 0</dep></entry><br />
<entry><ind>0.666</ind><dep>0.18</dep></entry><br />
<entry><ind>1.0</ind><dep>0.27</dep></entry><br />
</interpolation><br />
</source><br />
The first figure (<ind> refers to the value of the property associated with the object and the second figure (in <dep>) refers to the amount that the object moves in metres. For example, in this case, the object moves 18cm when the value reads 0.66 and 27cm when the value is 1.<br />
<br />
'''IF used WTIHOUT property''' : The object is placed at some (Value of Offset) meters away from its original position, along the virtual axis formed by said original position and the point with coordinates x/y/z defined in the <axis> tag.<br />
Mathematically, assuming the Object to translate is (in the model space) placed at point A (x1, y1, z1) and you want to relocate it to point B (x2, y2, z2) then x2,y2,z2 are the values in the <axis> tag of the Translate animation and <offset> can be computed as SQRT((x2-x1)^2+(y2-y1)^2+(z2-z1)^2)<br />
<br />
<br />
* '''factor:''' is optional.<br />
* '''offset-m:''' is optional. Offset in meters.<br />
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]<br />
<br />
== Material animation ==<br />
An animation type that can be used in various ways. Of course you can combine the below mentiond systems into one (big) animation.<br />
<br />
<source><br />
<animation> <br />
<type>material</type> <br />
<object-name>Object</object-name><br />
<property-base>sim/model/c172p/material</property-base><br />
<global type="bool">true</global> <!-- This tag is no longer supported --><br />
...<br />
lines as mentioned below<br />
...<br />
</animation><br />
</source><br />
<br />
'''Optional:'''<br />
* '''property-base:''' when using prop(erties), you might want to set a property-base. All props will be relative to this path.<br />
* '''global (deprecated):''' by setting this to <tt>true</tt>, all objects using the same material as the defined object(s) (via <tt><object-name></tt>) will be affected by the animation. This is preferred to listing several objects in <object-name> tags. It's not only faster, but also doesn't break animations by forcing objects together. <span style="color:red; text-decoration: underline;">This tag is no longer supported</span><br />
<br />
'''Notes:'''<br />
* Numbers are clamped to 0.0-1.0, except "shininess", which is clamped to 0-128.<br />
* By appending <tt>-prop</tt> each of the material properties can read its value from another property.<br />
<br />
=== Ambient ===<br />
<source><br />
<ambient><br />
<red>1.0</red><br />
<green>0.2</green><br />
<blue>0.0</blue><br />
</ambient><br />
</source><br />
<br />
=== Diffuse ===<br />
<source><br />
<diffuse><br />
<red>1.0</red><br />
<green>0.2</green><br />
<blue>0.0</blue><br />
</diffuse><br />
</source><br />
<br />
=== Emission ===<br />
{{Main article|Howto: Illuminate faces}}<br />
<source><br />
<emission><br />
<red>1.0</red><br />
<green>0.2</green><br />
<blue>0.0</blue><br />
<factor-prop>controls/lighting/panel-norm</factor-prop><br />
</emission><br />
</source><br />
<br />
Emission colors are multiplied by the factor-prop value. 1 is maximum color intensity, while 0 is the minimum. Colors are calculated according to the [http://en.wikipedia.org/wiki/RGB_color_model RGB color model].<br />
<br />
=== Shininess ===<br />
Shininess is clamped to 0-128.<br />
<source><br />
<shininess>105</shininess><br />
</source><br />
<br />
=== Specular ===<br />
<source><br />
<specular><br />
<red>1.0</red><br />
<green>0.2</green><br />
<blue>0.0</blue><br />
</specular><br />
</source><br />
<br />
=== Texture ===<br />
Used for the [[Livery over MP]] system.<br />
<br />
<source><br />
<property-base>sim/model/livery</property-base> <br />
<texture-prop>engine</texture-prop> <br />
<texture>KLM.png</texture> <br />
</source><br />
<br />
=== Transparency ===<br />
<source><br />
<transparency><br />
<alpha-prop>rotors/tail/rpm</alpha-prop><br />
<factor>-0.0015</factor><br />
<offset>1</offset><br />
</transparency><br />
</source><br />
<br />
=== Threshold ===<br />
<source><br />
<threshold>0.001</threshold><br />
</source><br />
<br />
== Texture Animations ==<br />
<br />
Applying different matrix transformations to the textures of an object.<br />
<br />
=== Textranslate ===<br />
A very important animation for cockpits! This animation moves textures over a surface.<br />
<br />
<source><br />
<animation><br />
<type>textranslate</type><br />
<object-name>Object</object-name><br />
<property>autopilot/settings/target-speed-kt</property><br />
<bias>0.0001</bias><br />
<factor>0.001</factor><br />
<step>100</step><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
</axis><br />
</animation><br />
</source><br />
<br />
* '''bias:''' Adds an offset to the property before factor/step. A small value is needed to compensate for [http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems floating point accuracy].<br />
* '''factor:''' property * factor * texture width/height = the amount of pixels that the texture should be translated. If your texture is 256 pixels, an textranslate of 0.1 will result in the texture moving with 26 pixels, into the direction specified by the axis settings.<br />
* '''step:''' the step size at which the texture is translated. If this is set to 0.1, the texture will only be translated at 0.1, 0.2, 0.3 etc.<br />
* '''axis:''' the direction in which the texture is translated. Y is up/down, while X is left/right.<br />
<br />
=== Texrotate ===<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>texrotate</type><br />
<property>some/property/path</property><br />
<factor>25</factor><br />
<offset-deg>25</offset-deg><br />
<center><br />
<x>0.5</x><br />
<y>0.5</y><br />
<z>0</z><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>0</y><br />
<z>1</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
=== Textrapezoid ===<br />
<br />
<source><br />
<animation><br />
<type>textrapezoid</type><br />
<object-name>HUD.l.canvas</object-name><br />
<property>/hud/trapezoid-correction</property><br />
<side>bottom</side><br />
</animation><br />
</source><br />
<br />
* '''side''': side of quad which should be scaled (''top'' (default)/''right''/''bottom''/''left'')<br />
<br />
=== Texmultiple ===<br />
<br />
Only one texture matrix can be applied to each object. With ''textmultiple'' multiple texture animations can be combined into a single matrix, applied to the specified object.<br />
<br />
<source><br />
<animation><br />
<type>texmultiple</type><br />
<object-name>HUD.l.canvas</object-name><br />
<transform><br />
<subtype>textranslate</subtype><br />
<property>/hud/offset-x</property><br />
<axis><br />
<x>1</x><br />
<y>0</y><br />
<z>0</z><br />
</axis><br />
</transform><br />
<transform><br />
<subtype>textranslate</subtype><br />
<property>/hud/offset-y</property><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</transform><br />
<transform><br />
<subtype>textrapezoid</subtype><br />
<property>/hud/trapezoid-correction</property><br />
</transform><br />
</animation><br />
</source><br />
<br />
== Object interaction animations ==<br />
=== Enable-hot ===<br />
Scenery objects are automatically defined as solid by FlightGear, meaning that an aircraft can taxi on them and/or crash when touching. For certain objects (groundmarkings, beacon light-beams etc.) this might be an unwanted feature. The solidness can be disabled with the following animation:<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<enable-hot type="bool">false</enable-hot><br />
</animation><br />
</source><br />
<br />
* '''enable-hot:''' can be either true or false. Remember that objects are automatically solid, so it should not be necessary to set this at all when wanting solidness.<br />
<br />
=== Interactions ===<br />
<source><br />
<animation> <br />
<type>interaction</type> <br />
<object-name>Object</object-name> <br />
<interaction-type>carrier-wire</interaction-type> <br />
</animation> <br />
</source><br />
<br />
* '''interaction-type:''' can have the following values:<br />
**'''carrier-catapult:'''<br />
** '''carrier-wire:''' makes the object act as an arresting wire, as used on [[aircraft carrier]]s.<br />
<br />
== Direct manipulation animations ==<br />
=== Knob / slider (v. 2.11-) ===<br />
{{Main article|Knob / slider animation}}<br />
<br />
=== Pick ===<br />
{{Main article|Howto: Make a clickable panel#Pick}}<br />
<br />
=== Touch ===<br />
<br />
The touch animation provides the normalized coordinates of a touch (or click) event on a 2d surface. The coordinates are passed in the argument and can be accessed using cmdarg() in Nasal.<br />
<br />
* Touch animation is designed to work with a quad that is being used as a Canvas placement (display).<br />
* The touch animation must not be combined with a pick animation on the same object.<br />
* More info here: [[Touch Animation]]<br />
<br />
==== touch example ====<br />
<br />
<animation><br />
<type>touch</type><br />
<visible>true</visible><br />
<object-name>CanvasPlacement</object-name><br />
<action><br />
<touch>0</touch><br />
<repeatable>false</repeatable><br />
<binding><br />
<command>nasal</command><br />
<script>print("touch input (",cmdarg().getNode("x").getValue(),",",cmdarg().getNode("y").getValue())</script><br />
</binding><br />
</action><br />
</animation><br />
<br />
== Shadow Handling ==<br />
There exist several possibilites for handling of shadows. <br /><br />
See '''[[ALS_technical_notes|ALS Technical Notes]]''' and more specific '''[[ALS_technical_notes#ALS_fuselage_shadow_effect|Fuselage Shadow Effect with ALS]]''' for a relatively simple shadow handling.<br /><br />
See '''[[Project Rembrandt]]''' which - amongst other functionality - implements a very realistic shadow mapping.<br />
As of January 2021 Project Rembrandt was replaced by the '''[[Compositor]]''' renderer which combines both Project Rembrandt and ALS in a single rendering engine. This also means that the Fuselage Shadow Effect with ALS is now deprecated.<br />
<br />
== References ==<br />
{{Appendix|all|<br />
* {{cite web |url=http://www.opensubscriber.com/message/flightgear-devel@flightgear.org/958955.html |title="material" animation (and the bo105 as an example) |first=Melchior |last=Franz |date=22 March 2005 |work=FlightGear-devel mailinglist }}<br />
* {{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg01546.html |title=flash animation |first=Frederic |last=Bouvier |date=22 Feb 2006 |work=FlightGear-devel mailinglist }}<br />
}}<br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[MP Fallback models]]<br />
* [[Howto:Animate gear scissors]]<br />
* [[Howto:Animate helicopters]]<br />
* [[Howto:Creating 3D instruments]]<br />
<br />
=== Forum topics ===<br />
* {{forum link|t=37353|title=3d models, how to produce them in an understandable way}} (April 2020-) - Touches on the subject of not using LOD range animations in scenery models.<br />
* {{forum link|t=36545|title=speedo Drum settings}} (November 2019) - Animating a mechanical multi-digit drum counter<br />
<br />
[[Category:Aircraft enhancement|Animate models]]<br />
[[Category:Howto|Animate models]]<br />
[[Category:Modeling|Animate models]]<br />
[[Category:Scenery enhancement|Animate models]]</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=Howto:Animate_gear_scissors_using_the_tracking_animation&diff=134674Howto:Animate gear scissors using the tracking animation2022-02-15T22:55:07Z<p>Cgdae: Added link to the main animation page</p>
<hr />
<div>A '''locked-track animation''' is an [[Howto:Animate_models|animation]] that can do exactly the same thing as the [https://docs.blender.org/manual/en/latest/animation/constraints/tracking/locked_track.html Locked Track constraint] available in Blender, and it can also be used to simulate simple inverse kinematic systems consisting of two bones connected with a revolute joint (also known as a hinge).<br />
<br />
==Blender==<br />
If you get used to Blender its a really powerful tool (I have problems if trying to work with other modelling programs :P) and with using the<br />
right scripts it gets a very neat tool for creating models for FlightGear. For example for a gear scissor just add an armature with two bones, add an inverse kinematic (IK) constraint to the second bone and attach an element of the scissor to each bone, and you are done. You can watch the animation in Blender and using an exporter script now it is possible to watch exactly the same animation inside FlightGear. You do not need to guess any coordinates/axes/etc. and if you modify and object you just have to export it again, without manually modifying the animation XML file.<br />
<br />
There are (currently) only two axes required. The <code>lock-axis</code> and the <code>track-axis</code>. They should be orthogonal, as the rotation is only possible round the <code>lock-axis</code>. Internally the <code>track-axis</code> is always orthonormalized to the <code>lock-axis</code>, as calculations always are performed in the plane normal to the <code>lock-axis</code>.<br />
<br />
<gallery widths=200 heights=200><br />
File:Tracking animation (locked-track initial pose).png|Initial pose<br />
File:Tracking animation (locked-track target moved).png|The target has moved and the <code>locked-track</code> animation ensures the object still points at the target (with the <code>track-axis</code>)<br />
File:Tracking animation (locked-track target moved outside plane).png|The target is projected into the plane defined by the object center and the <code>lock-axis</code> before the <code>locked-track</code> animation is applied.<br />
</gallery><br />
{{#ev:youtube|bWGLapFgOtw}}<br />
<br />
For example, you can use the normal rotate animation to rotate the main strut. Every attached hydraulic cylinder, link, etc. is then animated using the<br />
<code>locked-track</code> animation. For a hydraulic cylinder the piston and the cylinder housing each are animated using a <code>locked-track</code> animation tracking each other. For a gear scissor, a <code>locked-track</code> animation tracks from a point attached to the strut to a point on the axis. Two objects can be attached to the animation, allowing to animate a scissor. (The object and the slave object, are rotated such that the exactly fill the space between the two attachment points of the scissor).<br />
<br />
For the animation a center point and an orientation (axis) are required to calculate the location and orientation of the rotation. Think of the center as the location of the hinge somewhere in space and of the axis as the actual orientation of the hinge. You can now either specify the position of the hinge and the orientation of its axis or (the alternate form) two points on the axis of the hinge, which are then used to calculate the center and orientation of the hinge. (If you use the alternate form the center and axis are automatically calculated from the two given points).<br />
<br />
There is no rotation that you can not describe with a single axis<br />
given by its xyz coordinates.<br />
<br />
=== Slave center/object ===<br />
The <code>slave-center</code> specifies the location of the revolute joint. Optionally an object can be specified using <code>slave-name</code>, which will be attached to the animated object and also tracks to the target object.<br />
<br />
<gallery widths=320 heights=256><br />
File:Tracking animation with slave object.png|Initial pose<br />
File:Tracking animation with slave object (scissor, inverse kinematics).png|The target has moved and the <code>locked-track</code> animation ensures the <code>track-axis</code> still points at the target. The <code>object</code> and the <code>slave-object</code> are rotated such that the available space is exactly filled (aka scissor animation). <br />
</gallery><br />
<br />
== Examples ==<br />
Basic usage (Same behaviour as [http://wiki.blender.org/index.php/Doc:2.6/Manual/Constraints/Tracking/Locked_Track Locked Track constraint] in Blender):<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="utf8"?><br />
<PropertyList><br />
<animation><br />
<type>locked-track</type><br />
<br />
<object-name>ADS Arm - Fuselage.r</object-name><br />
<center><br />
<x-m>4.9</x-m><br />
<y-m>1.47</y-m><br />
<z-m>3.82</z-m><br />
</center><br />
<lock-axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</lock-axis><br />
<track-axis><br />
<x>0.75</x><br />
<y>0</y><br />
<z>-0.662</z><br />
</track-axis><br />
<br />
<target-name>ADS Arm - Ramp.r</target-name><br />
<target-center><br />
<x-m>7.969</x-m><br />
<y-m>1.475</y-m><br />
<z-m>1.11</z-m><br />
</target-center><br />
<br />
</animation><br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
Gear scissor/link with joint (In Blender the same animation can be achieved using an armature with two bones and an IK constraint applied to the second bone, tracking the target object. The animated object is attached to the first bone and the slave object to the second bone.):<br />
<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="utf8"?><br />
<PropertyList><br />
<animation><br />
<type>locked-track</type><br />
<br />
<object-name>NLG Front Door</object-name><br />
<center><br />
<x-m>-11.52</x-m><br />
<y-m>0</y-m><br />
<z-m>1.13</z-m><br />
</center><br />
<lock-axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</lock-axis><br />
<track-axis><br />
<x>1</x><br />
<y>0</y><br />
<z>0</z><br />
</track-axis><br />
<br />
<target-name>NLG-Strut</target-name><br />
<target-center><br />
<x-m>-9.9</x-m><br />
<y-m>0</y-m><br />
<z-m>1.13</z-m><br />
</target-center><br />
<br />
<slave-name>NLG Front Door Arm</slave-name><br />
<slave-center><br />
<x-m>-11.335</x-m><br />
<y-m>0</y-m><br />
<z-m>1.076</z-m><br />
</slave-center><br />
</animation><br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
Use a condition to disable tracking (and optionally apply specify a rotation being applied while disabled):<br />
<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="utf8"?><br />
<PropertyList><br />
<animation><br />
<type>locked-track</type><br />
<br />
<condition><br />
<property>/controls/gear/nose-wheel-steering</property><br />
</condition><br />
<disabled-rotation-deg>-90</disabled-rotation-deg><br />
<br />
<object-name>Torque Link Upper Arm</object-name><br />
<center><br />
<x-m>-9.785</x-m><br />
<y-m>0</y-m><br />
<z-m>1.04</z-m><br />
</center><br />
<lock-axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</lock-axis><br />
<track-axis><br />
<x>0.022</x><br />
<y>0</y><br />
<z>-1</z><br />
</track-axis><br />
<br />
<target-name>Torque Link Lower Arm</target-name><br />
<target-center><br />
<x-m>-9.789</x-m><br />
<y-m>0</y-m><br />
<z-m>0.454</z-m><br />
</target-center><br />
<br />
<slave-center><br />
<x-m>-10.033</x-m><br />
<y-m>0</y-m><br />
<z-m>1.035</z-m><br />
</slave-center><br />
</animation><br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
== Lessons learned ==<br />
=== Scissors - with parenting ===<br />
[[File:Scissors-locked-track-example.png|thumb]]<br />
<br />
As seen to right, we have a oleo strut, and a gear leg. The oleo strut has a compression animation which uses a translate animation to move up or down according to gear-compression. There are two torque links - the top is called <code>NLGTorqueLink1</code> and the bottom <code>NLGTorqueLink2</code>.<br />
<br />
The bottom link must be a child of the top link. <br />
<br />
After the translation animation, setup a locked track animation on <code>NLGTorqueLink1</code>. The center is the hinge of the top scissor arm, the target is the hinge of the bottom arm, <code>target-name</code> is the oleo strut which is translated. Finally, the <code>slave-name</code> is the bottom scissor arm, and the <code>slave-center</code> is where the two arms meet.<br />
<br />
<syntaxhighlight><br />
<animation><br />
<type>locked-track</type><br />
<object-name>NLGTorqueLink1</object-name> <!-- upper --><br />
<center><br />
<x-m>-13.468</x-m><br />
<y-m>-0.006419</y-m><br />
<z-m>-3.34389</z-m><br />
</center><br />
<lock-axis><br />
<x>0</x><br />
<y>-1</y> <!-- inverting this gives strange results! --><br />
<z>0</z><br />
</lock-axis><br />
<track-axis> <!-- +- ve doesn't matter --><br />
<x>0.100957</x><br />
<y>0.569667</y><br />
<z>0.001675</z><br />
</track-axis><br />
<br />
<target-name>NLGSlidingTubeAxle</target-name> <!-- oleo strut --><br />
<target-center> <!-- rotation axis of lower --><br />
<x-m>-13.569</x-m><br />
<y-m>-0.004744</y-m><br />
<z-m>-3.91356</z-m><br />
</target-center><br />
<br />
<slave-name>NLGTorqueLink2</slave-name><br />
<slave-center> <!-- middle hinge --><br />
<x-m>-13.2685</x-m><br />
<y-m>-0.005584</y-m><br />
<z-m>-3.67419</z-m><br />
</slave-center><br />
</animation><br />
</syntaxhighlight><br />
<br />
=== Scissors - without parenting ===<br />
The same animation can be done without parenting. The way this is animated is as follows:<br />
<br />
Each torque link rotates around its base, where it meets the oleo strut / gear leg and is locked on the y-axis. The target position is at the 3D cursor, where both of them meet, and the track axis is the axis between the two centers of rotation of the torque links (about ten degrees off vertical). The target object is the other torque link (number 1 for number 2 and vice versa). The <code>slave-center</code> is the center of rotation for the other torque link.<br />
<br />
<syntaxhighlight><br />
<animation><br />
<type>locked-track</type><br />
<object-name>NLGTorqueLink2</object-name> <!-- lower --><br />
<center><br />
<x-m>-13.569</x-m><br />
<y-m>-0.004744</y-m><br />
<z-m>-3.91356</z-m><br />
</center><br />
<lock-axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</lock-axis><br />
<track-axis><br />
<x>0.100955</x><br />
<y>0.569668</y><br />
<z>0.001675</z><br />
</track-axis><br />
<br />
<target-name>NLGTorqueLink1</target-name><br />
<target-center> <br />
<x-m>-13.2685</x-m><br />
<y-m>-0.005584</y-m><br />
<z-m>-3.67419</z-m><br />
</target-center><br />
<br />
<slave-center> <!-- rotation axis of upper --><br />
<x-m>-13.468</x-m><br />
<y-m>-0.006419</y-m><br />
<z-m>-3.34389</z-m><br />
</slave-center><br />
</animation><br />
<br />
<animation><br />
<type>locked-track</type><br />
<object-name>NLGTorqueLink1</object-name> <!-- upper --><br />
<center><br />
<x-m>-13.468</x-m><br />
<y-m>-0.006419</y-m><br />
<z-m>-3.34389</z-m><br />
</center><br />
<lock-axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</lock-axis><br />
<track-axis><br />
<x>-0.100955</x><br />
<y>-0.569668</y><br />
<z>-0.001675</z><br />
</track-axis><br />
<br />
<target-name>NLGTorqueLink2</target-name><br />
<target-center><br />
<x-m>-13.2685</x-m><br />
<y-m>-0.005584</y-m><br />
<z-m>-3.67419</z-m><br />
</target-center><br />
<br />
<slave-center> <!-- rotation axis of lower --><br />
<x-m>-13.569</x-m><br />
<y-m>-0.004744</y-m><br />
<z-m>-3.91356</z-m><br />
</slave-center><br />
</animation><br />
</syntaxhighlight><br />
This is confusing and non-intuitive, to say the least, but works!<br />
<br />
===3 axis ''locked-track'' animation===<br />
Sometime is necessary realize the animation to an object with ball joint, is the typical case of a hydraulic jack actuate the opening the landing gear, it is necessary to proceed in two stages, ''as <code>locked-track</code> animation always needs at least a locked axis''.<br />
<br />
<gallery widths=640 heights=400><br />
File:3 axis locked track animation example 01.jpg|3 axis locked-track animation example.<br />
</gallery><br />
<br />
First locks, for example, the y axis and directs the object to a target object, in this example <code>BOX_GEAR_GREEN.000</code> with coordinates: <code>target-center</code>. The <code>track-axis</code> is the axis that should point the target:<br />
<br><br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="utf8"?><br />
<animation><br />
<type>locked-track</type><br />
<object-name>gear-front-jack-02</object-name><br />
<center><br />
<x-m>-2.91953</x-m><br />
<y-m>-0.06230</y-m><br />
<z-m>-1.30829</z-m><br />
</center><br />
<lock-axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</lock-axis><br />
<track-axis><br />
<x>1</x><br />
<y>-0.23</y><br />
<z>0.630</z> <br />
</track-axis><br />
<target-name>BOX_GEAR_GREEN.000</target-name><br />
<target-center><br />
<x-m>-2.04543</x-m><br />
<y-m>-0.23232</y-m><br />
<z-m>-0.82533</z-m><br />
</target-center><br />
</animation><br />
</syntaxhighlight><br />
<br />
Then write a second <code>locked-track</code>, which should be put immediately under the first, which locks the x axis. Everything else is equal, as all other references are unchanged.<br />
<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="utf8"?><br />
<animation><br />
<type>locked-track</type><br />
<object-name>gear-front-jack-02</object-name><br />
<center><br />
<x-m>-2.91953</x-m><br />
<y-m>-0.06230</y-m><br />
<z-m>-1.30829</z-m><br />
</center><br />
<lock-axis><br />
<x>1</x><br />
<y>0</y><br />
<z>0</z><br />
</lock-axis><br />
<track-axis><br />
<x>1</x><br />
<y>-0.23</y><br />
<z>0.630</z> <br />
</track-axis><br />
<target-name>BOX_GEAR_GREEN.000</target-name><br />
<target-center><br />
<x-m>-2.04543</x-m><br />
<y-m>-0.23232</y-m><br />
<z-m>-0.82533</z-m><br />
</target-center><br />
</animation><br />
</syntaxhighlight><br />
<br />
{{#ev:youtube|4hx0NU6E91s}}<br />
<br />
===The track-axis configuration===<br />
The <code>track-axis</code> is the real direction of the object that follows the target point. It is not very simple to configure as it also depends on the geometry of the piece. A very simple method for configure the axis direction is define it when the object is in the "rest" position, in essence in the position where the object is in the 3D file. When we activate the animation, even if we have correctly defined the center point and the target point, often the initial position of the object is not what we think is correct. At this point it is necessary to operate by varying the values of the free axes (Remember: the locked axis is the one defined in the lock-axis) until the piece assumes the correct initial position.<br />
<br />
===Tips===<br />
====Graphic graph of coordinates of vertices of a line in angular coordinates according to the linear XYZ form====<br />
Strangely, the coordinates of the <track-axis> section do not seem to work on the coordinates given in the form: <code><nowiki><x1-m> .. </ x1-m> ... <z2-m> .. </ z2-m ></nowiki></code>. We must give the coordinates in the form <code><nowiki><x> ... </ x> ... <z> .. </ z></nowiki></code>. To easily convert vertices, you can use the 3D CAD application FreeCAD. You create a line by inserting the two vertices (V1 and V2) and then activating the Bounding Box display, as shown in the figure. The 3 coordinates X, Y, Z can be used directly as x, y and z coordinates. But be careful with the signs.<br />
<br />
<gallery widths=640 heights=400><br />
File:FreeCad Bounding Box for Axis value conversion.jpg|Coordinates of vertices of a line convert in angular coordinates according to the xyz form.<br />
</gallery><br />
<br />
[[Category:Modeling]]<br />
[[Category:Aircraft enhancement]]</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=User:Cgdae&diff=134634User:Cgdae2022-02-12T21:47:57Z<p>Cgdae: /* Notes about locked-track animations */</p>
<hr />
<div>== Recent ==<br />
<br />
Current work in progress:<br />
<br />
* .<br />
<br />
On next:<br />
<br />
* [[Video encoding]] of Flightgear's main window.<br />
** E.g. see: http://op59.net/fgvideo-harrier-gr3-manhattan.mkv<br />
* [[Highlighting]].<br />
* [[SimpleTime]].<br />
* [[ExtraViewWindows|Extra view windows]]<br />
* [[Instant_Replay#Record.2Freplay_on_next|Enhancements to record/replay]]<br />
* [[Carrier_over_MP#Pilot_Using_the_Carrier|Enhancements to multiplayer carrier operation]]<br />
<br />
Other:<br />
<br />
* [[:Category:Hackathon 2021 Ideas]]<br />
*[[Walk_build_system|The Walk Flightgear Build system]] - a different kind of build system which i use to build Flightgear.<br />
*Harrier-GR3 autohover: https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Harrier-GR3/<br />
*Flightgear on [http://www.openbsd.org OpenBSD].<br />
<br />
<br />
==Old==<br />
*[https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/debug/logdelta.hxx logdeltas] - control of debug log levels based on source filename prefixes, line numbers and function prefixes.<br />
*[[Post_FlightGear_2020.2_LTS_changes#Record.2Freplay|Record/replay]]:<br />
** Multiplayer record.<br />
**Continuous record.<br />
**Recovery snapshots.<br />
*[[Changelog_2020.1#Multiplayer |Multiplayer views]].<br />
*[[Changelog_2020.1#Graphics |Tower View AGL]].</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=Howto_talk:Animate_gear_scissors_using_the_tracking_animation&diff=134633Howto talk:Animate gear scissors using the tracking animation2022-02-12T21:47:11Z<p>Cgdae: Some alternative ways of specifying locked-track animations.</p>
<hr />
<div>It is really sad that no one knows how to make an example of the "animation Tracking" animation. The animation is really interesting, but it is not explained in an understandable way in the wiki, someone has used it successfully?<br />
--[[User:Abassign|Abassign]] ([[User talk:Abassign|talk]]) 19:06, 11 July 2016 (EDT)<br />
<br />
<br />
== Notes about locked-track animations ==<br />
<br />
I've found this page a little difficult to understand, so here's some alternative notes about locked-track animations.<br />
<br />
<pre><br />
<br />
o a_center<br />
/<br />
a<br />
/<br />
o slave_center:lock_axis<br />
\<br />
b<br />
\<br />
o b_center<br />
<br />
</pre><br />
<br />
We want to animate '''a''' and '''b''', which involves first modifying one or both of them with simple animations such as '''rotate''' or '''translate''', then applying two locked-track animations that rotate each object about the (modified) '''a_center''' and '''b_center''' points so that they meet at a new '''slave_center''' position (with an unchanged '''lock_axis''' direction).<br />
<br />
The XML specifications for the required locked-track animations contain duplicate and derived data, which i think contributes to making it difficult to understand.<br />
<br />
There are a few examples of locked-track animations in {{fgaddon file|Aircraft/Citation/Models/Citation-II.xml}}. These are without parenting, i.e. they do not require that '''b''' is a child object of '''a'''. I've similarly kept to this non-parenting style, because it seems to be conceptually simpler.<br />
<br />
So here's a Python function that can be used to generate the two locked-track XML specifications. It turns out that one only needs 6 pieces of information.<br />
<br />
<pre><br />
def locked_track_animation(<br />
a_name,<br />
a_center,<br />
b_name,<br />
b_center,<br />
slave_center,<br />
lock_axis,<br />
):<br />
'''<br />
Returns text for a locked track animation.<br />
<br />
a_name:<br />
Name of component A.<br />
a_center:<br />
Position of center of rotation of A.<br />
b_name:<br />
Name of component B.<br />
b_center:<br />
Position of center of rotation of B.<br />
slave_center:<br />
Position of hinge linking A and B.<br />
lock_axis:<br />
Axis of hinge.<br />
'''<br />
def ac2xml( p):<br />
'''<br />
Convert from .ac coordinates to Flightgear .xml<br />
coordinates.<br />
'''<br />
return numpy.array( ( p[0], -p[2], p[1]))<br />
<br />
a_center = ac2xml( a_center)<br />
b_center = ac2xml( b_center)<br />
slave_center = ac2xml( slave_center)<br />
lock_axis = ac2xml( lock_axis)<br />
<br />
track_axis = b_center - a_center<br />
<br />
text = textwrap.dedent( f'''<br />
<animation><br />
<type>locked-track</type><br />
<object-name>{a_name}</object-name><br />
<center><br />
<x-m>{a_center[0]}</x-m><br />
<y-m>{a_center[1]}</y-m><br />
<z-m>{a_center[2]}</z-m><br />
</center><br />
<lock-axis><br />
<x>{lock_axis[0]}</x><br />
<y>{lock_axis[1]}</y><br />
<z>{lock_axis[2]}</z><br />
</lock-axis><br />
<track-axis><br />
<x>{track_axis[0]}</x><br />
<y>{track_axis[1]}</y><br />
<z>{track_axis[2]}</z><br />
</track-axis><br />
<slave-center><br />
<x-m>{slave_center[0]}</x-m><br />
<y-m>{slave_center[1]}</y-m><br />
<z-m>{slave_center[2]}</z-m><br />
</slave-center><br />
<target-name>{b_name}</target-name><br />
<target-center><br />
<x-m>{b_center[0]}</x-m><br />
<y-m>{b_center[1]}</y-m><br />
<z-m>{b_center[2]}</z-m><br />
</target-center><br />
</animation><br />
<br />
<animation><br />
<type>locked-track</type><br />
<object-name>{b_name}</object-name><br />
<center><br />
<x-m>{b_center[0]}</x-m><br />
<y-m>{b_center[1]}</y-m><br />
<z-m>{b_center[2]}</z-m><br />
</center><br />
<lock-axis><br />
<x>{-lock_axis[0]}</x><br />
<y>{-lock_axis[1]}</y><br />
<z>{-lock_axis[2]}</z><br />
</lock-axis><br />
<track-axis><br />
<x>{-track_axis[0]}</x><br />
<y>{-track_axis[1]}</y><br />
<z>{-track_axis[2]}</z><br />
</track-axis><br />
<slave-center><br />
<x-m>{slave_center[0]}</x-m><br />
<y-m>{slave_center[1]}</y-m><br />
<z-m>{slave_center[2]}</z-m><br />
</slave-center><br />
<target-name>{a_name}</target-name><br />
<target-center><br />
<x-m>{a_center[0]}</x-m><br />
<y-m>{a_center[1]}</y-m><br />
<z-m>{a_center[2]}</z-m><br />
</target-center><br />
</animation><br />
<br />
''')<br />
return text<br />
</pre><br />
<br />
* The various positions and axes should be as in the '''.ac''' file, i.e. before any animations have been applied.<br />
* Note how we can derive '''track_axis''' from '''a_center''' and '''b_center''', and use -ve versions of '''lock_axis''' and '''track_axis''' in the second animation.<br />
* I'm not sure it's currently possible to [[Howto:Animate_models#Using_a_geometry_object_for_axis_and_centre_.282017.2.29|use geometry objects]] for the three positions and one axis that are required.<br />
<br />
Here's an example call:<br />
<br />
lta = locked_track_animation(<br />
a_name='gear_pusher_lo.l',<br />
a_center=gear_pushed_bottom,<br />
b_name='gear_pusher_hi.l',<br />
b_center=gear_pusher_top,<br />
slave_center=gear_pusher_mid,<br />
lock_axis=(0, 0, 1),<br />
)<br />
<br />
== A simpler syntax? ==<br />
<br />
Given that typical use of a locked-track animation only uses 6 pieces of information, it might be worth adding in support for a different XML specification that takes these 6 items only.<br />
<br />
So maybe we could define a new animation called '''hinge''' which looks like:<br />
<br />
<pre><br />
<animation><br />
<type>hinge</type><br />
<a><br />
<object-name>foo<object-name><br />
<center><br />
<x-m>...</x-m><br />
<y-m>...</y-m><br />
<z-m>...</z-m><br />
</center><br />
</a><br />
<b><br />
<object-name>bar<object-name><br />
<center><br />
<x-m>...</x-m><br />
<y-m>...</y-m><br />
<z-m>...</z-m><br />
</center><br />
</b><br />
<hinge><br />
<center><br />
<x-m>...</x-m><br />
<y-m>...</y-m><br />
<z-m>...</z-m><br />
</center><br />
<axis><br />
<x-m>...</x-m><br />
<y-m>...</y-m><br />
<z-m>...</z-m><br />
</axis><br />
</b><br />
</animation><br />
</pre><br />
<br />
Internally this would be converted into two locked-track animations.<br />
<br />
If we then add support for specifying a position using a geometry object, like we already do with axes, this could become:<br />
<br />
<pre><br />
<animation><br />
<type>hinge</type><br />
<a><br />
<object-name>foo</object-name><br />
<center><br />
<object-name>foo-center</object-name><br />
</center><br />
</a><br />
<b><br />
<object-name>bar</object-name><br />
<center><br />
<object-name>bar-center</object-name><br />
</center><br />
</b><br />
<hinge><br />
<center><br />
<object-name>foo.bar.hinge-center</object-name><br />
</center><br />
<axis><br />
<object-name>foo.bar.hinge-axis</object-name><br />
</axis><br />
</b><br />
</animation><br />
</pre><br />
<br />
Finally we could use the existing default '''-axis''' suffix and create a new default '''-center''' suffix to give a very concise syntax:<br />
<br />
<pre><br />
<animation><br />
<type>hinge</type><br />
<a><br />
<object-name>foo</object-name><br />
<!-- we use first vertex of object 'foo-center' as center. --><br />
</a><br />
<b><br />
<object-name>bar</object-name><br />
<!-- we use first vertex of object 'bar-center' as center. --><br />
</b><br />
<hinge><br />
<object-name>foo.bar.hinge</object-name><br />
<!-- we use first two vertices of<br />
foo.bar.hinge-axis as axis (in the usual way) and<br />
use the mid-point as the hinge center. --><br />
</b><br />
</animation><br />
</pre><br />
<br />
Or maybe avoid the new '''-center''' convention and instead use the first vertex of a '''*-axis''' object?<br />
<br />
[[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 21:47, 12 February 2022 (UTC)</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=User:Cgdae&diff=134632User:Cgdae2022-02-12T21:41:01Z<p>Cgdae: Added suggestions for a simpler syntax for locked-track animations.</p>
<hr />
<div>== Recent ==<br />
<br />
Current work in progress:<br />
<br />
* .<br />
<br />
On next:<br />
<br />
* [[Video encoding]] of Flightgear's main window.<br />
** E.g. see: http://op59.net/fgvideo-harrier-gr3-manhattan.mkv<br />
* [[Highlighting]].<br />
* [[SimpleTime]].<br />
* [[ExtraViewWindows|Extra view windows]]<br />
* [[Instant_Replay#Record.2Freplay_on_next|Enhancements to record/replay]]<br />
* [[Carrier_over_MP#Pilot_Using_the_Carrier|Enhancements to multiplayer carrier operation]]<br />
<br />
Other:<br />
<br />
* [[:Category:Hackathon 2021 Ideas]]<br />
*[[Walk_build_system|The Walk Flightgear Build system]] - a different kind of build system which i use to build Flightgear.<br />
*Harrier-GR3 autohover: https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Harrier-GR3/<br />
*Flightgear on [http://www.openbsd.org OpenBSD].<br />
<br />
<br />
=== Notes about locked-track animations ===<br />
<br />
I've found [[Howto:Animate_gear_scissors_using_the_tracking_animation]] a little difficult to understand, so here's some alternative notes about locked-track animations.<br />
<br />
<pre><br />
<br />
o a_center<br />
/<br />
a<br />
/<br />
o slave_center:lock_axis<br />
\<br />
b<br />
\<br />
o b_center<br />
<br />
</pre><br />
<br />
We want to animate '''a''' and '''b''', which involves first modifying one or both of them with simple animations such as '''rotate''' or '''translate''', then applying two locked-track animations that rotate each object about the (modified) '''a_center''' and '''b_center''' points so that they meet at a new '''slave_center''' position (with an unchanged '''lock_axis''' direction).<br />
<br />
The XML specifications for the required locked-track animations contain duplicate and derived data, which i think contributes to making it difficult to understand.<br />
<br />
There are a few examples of locked-track animations in {{fgaddon file|Aircraft/Citation/Models/Citation-II.xml}}. These are without parenting, i.e. they do not require that '''b''' is a child object of '''a'''. I've similarly kept to this non-parenting style, because it seems to be conceptually simpler.<br />
<br />
So here's a Python function that can be used to generate the two locked-track XML specifications. It turns out that one only needs 6 pieces of information.<br />
<br />
<pre><br />
def locked_track_animation(<br />
a_name,<br />
a_center,<br />
b_name,<br />
b_center,<br />
slave_center,<br />
lock_axis,<br />
):<br />
'''<br />
Returns text for a locked track animation.<br />
<br />
a_name:<br />
Name of component A.<br />
a_center:<br />
Position of center of rotation of A.<br />
b_name:<br />
Name of component B.<br />
b_center:<br />
Position of center of rotation of B.<br />
slave_center:<br />
Position of hinge linking A and B.<br />
lock_axis:<br />
Axis of hinge.<br />
'''<br />
def ac2xml( p):<br />
'''<br />
Convert from .ac coordinates to Flightgear .xml<br />
coordinates.<br />
'''<br />
return numpy.array( ( p[0], -p[2], p[1]))<br />
<br />
a_center = ac2xml( a_center)<br />
b_center = ac2xml( b_center)<br />
slave_center = ac2xml( slave_center)<br />
lock_axis = ac2xml( lock_axis)<br />
<br />
track_axis = b_center - a_center<br />
<br />
text = textwrap.dedent( f'''<br />
<animation><br />
<type>locked-track</type><br />
<object-name>{a_name}</object-name><br />
<center><br />
<x-m>{a_center[0]}</x-m><br />
<y-m>{a_center[1]}</y-m><br />
<z-m>{a_center[2]}</z-m><br />
</center><br />
<lock-axis><br />
<x>{lock_axis[0]}</x><br />
<y>{lock_axis[1]}</y><br />
<z>{lock_axis[2]}</z><br />
</lock-axis><br />
<track-axis><br />
<x>{track_axis[0]}</x><br />
<y>{track_axis[1]}</y><br />
<z>{track_axis[2]}</z><br />
</track-axis><br />
<slave-center><br />
<x-m>{slave_center[0]}</x-m><br />
<y-m>{slave_center[1]}</y-m><br />
<z-m>{slave_center[2]}</z-m><br />
</slave-center><br />
<target-name>{b_name}</target-name><br />
<target-center><br />
<x-m>{b_center[0]}</x-m><br />
<y-m>{b_center[1]}</y-m><br />
<z-m>{b_center[2]}</z-m><br />
</target-center><br />
</animation><br />
<br />
<animation><br />
<type>locked-track</type><br />
<object-name>{b_name}</object-name><br />
<center><br />
<x-m>{b_center[0]}</x-m><br />
<y-m>{b_center[1]}</y-m><br />
<z-m>{b_center[2]}</z-m><br />
</center><br />
<lock-axis><br />
<x>{-lock_axis[0]}</x><br />
<y>{-lock_axis[1]}</y><br />
<z>{-lock_axis[2]}</z><br />
</lock-axis><br />
<track-axis><br />
<x>{-track_axis[0]}</x><br />
<y>{-track_axis[1]}</y><br />
<z>{-track_axis[2]}</z><br />
</track-axis><br />
<slave-center><br />
<x-m>{slave_center[0]}</x-m><br />
<y-m>{slave_center[1]}</y-m><br />
<z-m>{slave_center[2]}</z-m><br />
</slave-center><br />
<target-name>{a_name}</target-name><br />
<target-center><br />
<x-m>{a_center[0]}</x-m><br />
<y-m>{a_center[1]}</y-m><br />
<z-m>{a_center[2]}</z-m><br />
</target-center><br />
</animation><br />
<br />
''')<br />
return text<br />
</pre><br />
<br />
* The various positions and axes should be as in the '''.ac''' file, i.e. before any animations have been applied.<br />
* Note how we can derive '''track_axis''' from '''a_center''' and '''b_center''', and use -ve versions of '''lock_axis''' and '''track_axis''' in the second animation.<br />
* I'm not sure it's currently possible to [[Howto:Animate_models#Using_a_geometry_object_for_axis_and_centre_.282017.2.29|use geometry objects]] for the three positions and one axis that are required.<br />
<br />
Here's an example call:<br />
<br />
lta = locked_track_animation(<br />
a_name='gear_pusher_lo.l',<br />
a_center=gear_pushed_bottom,<br />
b_name='gear_pusher_hi.l',<br />
b_center=gear_pusher_top,<br />
slave_center=gear_pusher_mid,<br />
lock_axis=(0, 0, 1),<br />
)<br />
<br />
==== A simpler syntax? ====<br />
<br />
Given that typical use of a locked-track animation only uses 6 pieces of information, it might be worth adding in support for a different XML specification that takes these 6 items only.<br />
<br />
So maybe we could define a different animation called '''hinge''' which looks like:<br />
<br />
<pre><br />
<animation><br />
<type>hinge</type><br />
<a><br />
<object-name>foo<object-name><br />
<center><br />
<x-m>...</x-m><br />
<y-m>...</y-m><br />
<z-m>...</z-m><br />
</center><br />
</a><br />
<b><br />
<object-name>bar<object-name><br />
<center><br />
<x-m>...</x-m><br />
<y-m>...</y-m><br />
<z-m>...</z-m><br />
</center><br />
</b><br />
<hinge><br />
<center><br />
<x-m>...</x-m><br />
<y-m>...</y-m><br />
<z-m>...</z-m><br />
</center><br />
<axis><br />
<x-m>...</x-m><br />
<y-m>...</y-m><br />
<z-m>...</z-m><br />
</axis><br />
</b><br />
</animation><br />
</pre><br />
<br />
Internally this would be converted into two locked-track animations.<br />
<br />
If we then add support for specifying a position using a geometry object, like we already do with axes, this could become:<br />
<br />
<pre><br />
<animation><br />
<type>hinge</type><br />
<a><br />
<object-name>foo</object-name><br />
<center><br />
<object-name>foo-center</object-name><br />
</center><br />
</a><br />
<b><br />
<object-name>bar</object-name><br />
<center><br />
<object-name>bar-center</object-name><br />
</center><br />
</b><br />
<hinge><br />
<center><br />
<object-name>foo.bar.hinge-center</object-name><br />
</center><br />
<axis><br />
<object-name>foo.bar.hinge-axis</object-name><br />
</axis><br />
</b><br />
</animation><br />
</pre><br />
<br />
Finally we could use the existing default '''-axis''' suffix and create a new default '''-center''' suffix to give a very concise syntax:<br />
<br />
<pre><br />
<animation><br />
<type>hinge</type><br />
<a><br />
<object-name>foo</object-name><br />
<!-- we use first vertex of object 'foo-center' as center. --><br />
</a><br />
<b><br />
<object-name>bar</object-name><br />
<!-- we use first vertex of object 'bar-center' as center. --><br />
</b><br />
<hinge><br />
<object-name>foo.bar.hinge</object-name><br />
<!-- we use first two vertices of<br />
foo.bar.hinge-axis as axis (in the usual way) and<br />
use the mid-point as the hinge center. --><br />
</b><br />
</animation><br />
</pre><br />
<br />
Or maybe avoid the new '''-center''' convention and instead use the first vertex of a '''*-axis''' object?<br />
<br />
==Old==<br />
*[https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/debug/logdelta.hxx logdeltas] - control of debug log levels based on source filename prefixes, line numbers and function prefixes.<br />
*[[Post_FlightGear_2020.2_LTS_changes#Record.2Freplay|Record/replay]]:<br />
** Multiplayer record.<br />
**Continuous record.<br />
**Recovery snapshots.<br />
*[[Changelog_2020.1#Multiplayer |Multiplayer views]].<br />
*[[Changelog_2020.1#Graphics |Tower View AGL]].</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=User:Cgdae&diff=134631User:Cgdae2022-02-12T17:56:34Z<p>Cgdae: Added notes about locked-track animations</p>
<hr />
<div>== Recent ==<br />
<br />
Current work in progress:<br />
<br />
* .<br />
<br />
On next:<br />
<br />
* [[Video encoding]] of Flightgear's main window.<br />
** E.g. see: http://op59.net/fgvideo-harrier-gr3-manhattan.mkv<br />
* [[Highlighting]].<br />
* [[SimpleTime]].<br />
* [[ExtraViewWindows|Extra view windows]]<br />
* [[Instant_Replay#Record.2Freplay_on_next|Enhancements to record/replay]]<br />
* [[Carrier_over_MP#Pilot_Using_the_Carrier|Enhancements to multiplayer carrier operation]]<br />
<br />
Other:<br />
<br />
* [[:Category:Hackathon 2021 Ideas]]<br />
*[[Walk_build_system|The Walk Flightgear Build system]] - a different kind of build system which i use to build Flightgear.<br />
*Harrier-GR3 autohover: https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/Harrier-GR3/<br />
*Flightgear on [http://www.openbsd.org OpenBSD].<br />
<br />
<br />
=== Notes about locked-track animations ===<br />
<br />
I've found [[Howto:Animate_gear_scissors_using_the_tracking_animation]] a little difficult to understand, so here's some alternative notes about locked-track animations.<br />
<br />
<pre><br />
<br />
o a_center<br />
/<br />
a<br />
/<br />
o slave_center:lock_axis<br />
\<br />
b<br />
\<br />
o b_center<br />
<br />
</pre><br />
<br />
We want to animate '''a''' and '''b''', which involves first modifying one or both of them with simple animations such as '''rotate''' or '''translate''', then applying two locked-track animations that rotate each object about the (modified) '''a_center''' and '''b_center''' points so that they meet at a new '''slave_center''' position (with an unchanged '''lock_axis''' direction).<br />
<br />
The XML specifications for the required locked-track animations contain duplicate and derived data, which i think contributes to making it difficult to understand.<br />
<br />
There are a few examples of locked-track animations in {{fgaddon file|Aircraft/Citation/Models/Citation-II.xml}}. These are without parenting, i.e. they do not require that '''b''' is a child object of '''a'''. I've similarly kept to this non-parenting style, because it seems to be conceptually simpler.<br />
<br />
So here's a Python function that can be used to generate the two locked-track XML specifications. It turns out that one only needs 6 pieces of information.<br />
<br />
<pre><br />
def locked_track_animation(<br />
a_name,<br />
a_center,<br />
b_name,<br />
b_center,<br />
slave_center,<br />
lock_axis,<br />
):<br />
'''<br />
Returns text for a locked track animation.<br />
<br />
a_name:<br />
Name of component A.<br />
a_center:<br />
Position of center of rotation of A.<br />
b_name:<br />
Name of component B.<br />
b_center:<br />
Position of center of rotation of B.<br />
slave_center:<br />
Position of hinge linking A and B.<br />
lock_axis:<br />
Axis of hinge.<br />
'''<br />
def ac2xml( p):<br />
'''<br />
Convert from .ac coordinates to Flightgear .xml<br />
coordinates.<br />
'''<br />
return numpy.array( ( p[0], -p[2], p[1]))<br />
<br />
a_center = ac2xml( a_center)<br />
b_center = ac2xml( b_center)<br />
slave_center = ac2xml( slave_center)<br />
lock_axis = ac2xml( lock_axis)<br />
<br />
track_axis = b_center - a_center<br />
<br />
text = textwrap.dedent( f'''<br />
<animation><br />
<type>locked-track</type><br />
<object-name>{a_name}</object-name><br />
<center><br />
<x-m>{a_center[0]}</x-m><br />
<y-m>{a_center[1]}</y-m><br />
<z-m>{a_center[2]}</z-m><br />
</center><br />
<lock-axis><br />
<x>{lock_axis[0]}</x><br />
<y>{lock_axis[1]}</y><br />
<z>{lock_axis[2]}</z><br />
</lock-axis><br />
<track-axis><br />
<x>{track_axis[0]}</x><br />
<y>{track_axis[1]}</y><br />
<z>{track_axis[2]}</z><br />
</track-axis><br />
<slave-center><br />
<x-m>{slave_center[0]}</x-m><br />
<y-m>{slave_center[1]}</y-m><br />
<z-m>{slave_center[2]}</z-m><br />
</slave-center><br />
<target-name>{b_name}</target-name><br />
<target-center><br />
<x-m>{b_center[0]}</x-m><br />
<y-m>{b_center[1]}</y-m><br />
<z-m>{b_center[2]}</z-m><br />
</target-center><br />
</animation><br />
<br />
<animation><br />
<type>locked-track</type><br />
<object-name>{b_name}</object-name><br />
<center><br />
<x-m>{b_center[0]}</x-m><br />
<y-m>{b_center[1]}</y-m><br />
<z-m>{b_center[2]}</z-m><br />
</center><br />
<lock-axis><br />
<x>{-lock_axis[0]}</x><br />
<y>{-lock_axis[1]}</y><br />
<z>{-lock_axis[2]}</z><br />
</lock-axis><br />
<track-axis><br />
<x>{-track_axis[0]}</x><br />
<y>{-track_axis[1]}</y><br />
<z>{-track_axis[2]}</z><br />
</track-axis><br />
<slave-center><br />
<x-m>{slave_center[0]}</x-m><br />
<y-m>{slave_center[1]}</y-m><br />
<z-m>{slave_center[2]}</z-m><br />
</slave-center><br />
<target-name>{a_name}</target-name><br />
<target-center><br />
<x-m>{a_center[0]}</x-m><br />
<y-m>{a_center[1]}</y-m><br />
<z-m>{a_center[2]}</z-m><br />
</target-center><br />
</animation><br />
<br />
''')<br />
return text<br />
</pre><br />
<br />
* The various positions and axes should be as in the '''.ac''' file, i.e. before any animations have been applied.<br />
* Note how we can derive '''track_axis''' from '''a_center''' and '''b_center''', and use -ve versions of '''lock_axis''' and '''track_axis''' in the second animation.<br />
* I'm not sure it's currently possible to [[Howto:Animate_models#Using_a_geometry_object_for_axis_and_centre_.282017.2.29|use geometry objects]] for the three positions and one axis that are required.<br />
<br />
Here's an example call:<br />
<br />
lta = locked_track_animation(<br />
a_name='gear_pusher_lo.l',<br />
a_center=gear_pushed_bottom,<br />
b_name='gear_pusher_hi.l',<br />
b_center=gear_pusher_top,<br />
slave_center=gear_pusher_mid,<br />
lock_axis=(0, 0, 1),<br />
)<br />
<br />
<br />
==Old==<br />
*[https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/debug/logdelta.hxx logdeltas] - control of debug log levels based on source filename prefixes, line numbers and function prefixes.<br />
*[[Post_FlightGear_2020.2_LTS_changes#Record.2Freplay|Record/replay]]:<br />
** Multiplayer record.<br />
**Continuous record.<br />
**Recovery snapshots.<br />
*[[Changelog_2020.1#Multiplayer |Multiplayer views]].<br />
*[[Changelog_2020.1#Graphics |Tower View AGL]].</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=Howto:Animate_models&diff=134629Howto:Animate models2022-02-11T13:12:23Z<p>Cgdae: /* Using a geometry object for axis and centre (2017.2) */</p>
<hr />
<div>The real world is full of motion. To simulate this in [[FlightGear]], '''models must be animated'''.<br />
<br />
FlightGear allows you to animate models 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. <br />
<br />
This document provides basic information for all kind of animations. When animating your model, it is very helpful to find an aircraft with parts similar to yours and use it as an example. Cut and paste the code into your wrapper file and then edit to suit.<br />
<br />
== Notes ==<br />
=== File name of main model and animation XML file ===<br />
{{main article|Aircraft-set.xml#Not used for loading multiplayer aircraft}}<br />
The file name of the main model and animation XML file, or the .ac file if there is no XML file, (in essence the property <code>/sim/model/path</code>) will be the name of the aircraft that is transmitted when using [[multiplayer]] and will also be used for loading multiplayer aircraft.<br />
<br />
There is also a mechanism to substitute a full aircraft model with a simpler AI aircraft model if one is available at the same file path (including for example <code>Models/Boeing-797-800.xml</code>), but in <code>[[$FG_ROOT]]/'''AI'''/Aircraft/</code> instead of <code>$FG_ROOT/Aircraft/</code>.<br />
<br />
=== .ac files ===<br />
{{Main article|AC files: Understanding and changing .ac code#Identifying an object}}<br />
<br />
When referring to an .ac file in your xml animation, it is important that the <code><object-name></code> exactly matches the object named in the .ac file (this includes cases!). <br />
<br />
'''Note for SketchUp users:''' The spatial reference X/Y/Z used in animation to locate an object or a point are different from the ones in AC3D ie X values are the same in both but Y in animation must be matched to AC3D's -Z (Z value but opposite sign) and Z value in animation must be matched to AC3D's Y value. <br />
<br />
'''Note for SketchUp users:''' when exporting to AC3D in Sketchup, the .ac file will name the objects in your model to "blah" by default. You need to amend the relevant object names in your .ac file using text edit, so that the xml will work.<br />
<br />
=== Animation order ===<br />
Animations are executed by FlightGear in the order that they are read in the model's .xml file. Therefore, it is very important to pay attention to the order, especially when multiple animations are applied to the same object(s). Wrong ordering of animations might cause [[Howto:Animate models#Timed|timed]] animations (used to create flashing lights) to not work. For further details see this [https://sourceforge.net/p/flightgear/mailman/message/37090714/ thread] on the development mailing list. Updated [https://scenery.flightgear.org/app.php?c=Models&a=browse&shared=18 shared Effects models] will be available very soon.<br />
<br />
Similar problems can be encountered with the dist-scale instead of the timed animation.<br />
== Tags used in most animations ==<br />
=== Name ===<br />
With a name animation, you can group multiple objects. <br />
<br />
<source><br />
<animation><br />
<name>Collection1</name><br />
<object-name>Object1</object-name><br />
<object-name>Object2</object-name><br />
<object-name>Object3</object-name><br />
</animation><br />
</source><br />
<br />
The example above creates a "virtual object" with the name Collection1. In animation, we can animate this group of objects, by using:<br />
<br />
<source><br />
<object-name>Collection1</object-name><br />
</source><br />
<br />
=== Object-name ===<br />
These names are set in the 3D model. Each single object has a unique name; for easy identification it is advised to use descriptive names (LeftElevator, Rudder etc.). Animations are only applied to those objects that are mentioned in an object-name line (one object per line!). Animations lacking those, will be applied to the entire model.<br />
<br />
=== Property ===<br />
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 <code><property></code> to provide the property path:<br />
<br />
<source><br />
<animation><br />
<type>rotate</type><br />
<object-name>Rudder</object-name><br />
<property>controls/rudder</property><br />
</animation><br />
</source><br />
<br />
Note the omission of the leading slash '/' when referring to the property. This assures that when the model is used for AI or multiplayer traffic the animations will follow that of the AI controller instead of that of the user.<br />
<br />
=== Axis ===<br />
An axis part is required in every animation that involves a rotating or moving thing.<br />
<br />
<source><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</source><br />
<br />
The axis are similar to the ones of the 3D model. There is a difference between rotation and translation:<br />
* In rotation animations, the axis part defines around what axis the object rotates. Negative/positive values make the difference between counterclockwise and clockwise rotations.<br />
* In translate animations, the part defines along what axis the object moves. If the x-axis is poiting backwards, an x-value of -1 will result in forward motion.<br />
<br />
You could also define two points, between which FlightGear will calculate the correct axis. This makes the use of a [[#Center|<nowiki><center></nowiki>]] tag redundant! Such coordinates are extremely useful for animating control surfaces (rudder, elevators etc.).<br />
<br />
<source><br />
<axis> <br />
<x1-m> 4.9</x1-m><br />
<y1-m> 7.1</y1-m><br />
<z1-m>-1.0</z1-m><br />
<x2-m> 5.9</x2-m><br />
<y2-m>11.2</y2-m><br />
<z2-m>-0.5</z2-m><br />
</axis><br />
</source><br />
<br />
=== Center ===<br />
Various animations ([[#Rotate|rotate]], [[#Spin|spin]], [[#Scale|scale]]) move around a center point.<br />
<br />
<source><br />
<center><br />
<x-m>-1.50</x-m><br />
<y-m> 1 </y-m><br />
<z-m> 0.25</z-m><br />
</center><br />
</source><br />
<br />
The axis are similar to the ones of the 3D model, so finding coordinates is easily done in 3D modeling software.<br />
<br />
=== Using a geometry object for axis and centre (2017.2) ===<br />
<br />
Added in V2017.2 is support to allow a geometry object (a line segment with two vertices) that is used to define both the centre and the axis for an animation. This will work with rotate, translate and the knob animations.<br />
<br />
The axis line should be balanced, i.e. it should protrude equal amounts. The axis line should be normalized (i.e. 1m) as its length acts as a factor (affecting translate animations).<br />
<br />
The XML syntax for this is:<br />
<br />
<source><br />
<axis><br />
<object-name>some-object</object-name><br />
</axis><br />
</source><br />
<br />
If the <code><axis>...</axis></code> section is omitted entirely, <code>{object-name}-axis</code> will be used by default, where <code>{object-name}</code> is the name of the object being animated (if we are animating more than one object, the first object is used). In the earlier example this would be <code>Rudder-axis</code>.<br />
<br />
In the '''.ac''' file, specify a SURF with type (bottom 4 bits, 0=polygon, 1=closedline, 2=line) set to 2, and two vertices that define the axis. For example:<br />
<br />
OBJECT poly<br />
name "aileron.l-axis"<br />
numvert 2<br />
3.2077502191170844 0.18160835055097943 4.055616960642423<br />
2.6758650763079 0.28024033462188946 6.477876098622225<br />
numsurf 1<br />
SURF 0x12<br />
mat 0<br />
refs 2<br />
0 0 0<br />
1 0 0<br />
kids 0<br />
<br />
Once the object-name used for the axis has been processed the geometry object will be hidden. This also allows a visual check for any axis objects that are not yet assigned.<br />
<br />
It is possible to reuse the same object definition multiple times within a single XML file. <br />
<br />
[[File:Canopy-animation-axis-object.png|small|Illustration of where an axis object (2017.2) can be placed for a canopy]]<br />
<br />
[[File:Gauges-knobs-animation-axis-object.png|small|Illustration of where an axis object (2017.2) can be placed for cockpit elements]]<br />
<br />
== Additional tags that can be used in most animations ==<br />
=== Conditions ===<br />
Multiple animations can make use of a conditional. Check <tt>$FGDATA/Docs/README.conditions</tt> for some more details.<br />
<br />
* '''equals:''' property value (or second property) is equal to value/(first)property.<br />
* '''greater-than:''' property value (or second property) is larger than value/(first)property.<br />
* '''greater-than-equals:''' property value (or second property) is greater than or equal to value/(first)property.<br />
* '''less-than:''' property value (or second property) is smaller than value/(first)property.<br />
* '''less-than-equals:''' property value (or second property) is smaller than or equal to value/(first)property.<br />
<br />
The example below is true when n1 has a value greater than 25.<br />
<source><br />
<condition><br />
<greater-than><br />
<property>engines/engine[1]/n1</property><br />
<value>25</value><br />
</greater-than><br />
</condition><br />
</source><br />
<br />
Then there are some special tags:<br />
<br />
* '''and:'''<br />
* '''not:'''<br />
* '''or:'''<br />
<br />
In the example below, the condition is true when either n1 is greater than 25% or equal to 0%.<br />
<source><br />
<condition><br />
<or><br />
<greater-than><br />
<property>engines/engine[1]/n1</property><br />
<value>25</value><br />
</greater-than><br />
<equals><br />
<property>engines/engine[1]/n1</property><br />
<value>0</value><br />
</equals><br />
</or><br />
</condition><br />
</source><br />
<br />
An example of implementation into an animation looks as follows:<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>rotate</type><br />
<property>suface-positions/left-aileron-pos-norm</property><br />
<factor>25</factor><br />
<condition><br />
<greater-than><br />
<property>suface-positions/left-aileron-pos-norm</property><br />
<value>10</value><br />
</greater-than><br />
</condition><br />
<center><br />
<x-m>-1.50</x-m><br />
<y-m> 1 </y-m><br />
<z-m> 0.25</z-m><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
=== Interpolation ===<br />
For non-fixed factors, an interpolation "table" can be created. <br />
<br />
<source><br />
<interpolation><br />
<entry><br />
<ind> 0.0</ind><br />
<dep> 0.0</dep><br />
</entry><br />
<entry><br />
<ind> 0.667</ind><br />
<dep> 0.0</dep><br />
</entry><br />
<entry><br />
<ind> 1.0</ind><br />
<dep> 0.5</dep><br />
</entry><br />
</interpolation><br />
</source><br />
<br />
The lines above represent the following table:<br />
<br />
{|<br />
!Input<br />
!Output<br />
|-<br />
|0.0<br />
|0.0<br />
|-<br />
|0.667<br />
|0.0<br />
|-<br />
|1.0<br />
|0.5<br />
|}<br />
<br />
You can add as many entries as you need. Interpolation tables are often used for gear animations (eg. to open doors during gear-movements and close them again once the gear is either retracted or fully extended).<br />
<br />
=== Expressions ===<br />
For some animations it is possible to define complex animations by using [[Expressions|Expressions]]. This even allows to drive the animation from multiple properties without the need for additional Nasal scripts. Here is an example for a translate animation depending on two properties and the cosine function:<br />
<syntaxhighlight lang="xml"><br />
<animation><br />
<type>translate</type><br />
<expression><br />
<product><br />
<property>/my/factor-property</property><br />
<cos><br />
<deg2rad><br />
<property>/my/angular-property</property><br />
</deg2rad><br />
</cos><br />
</product><br />
</expression><br />
[..]more elements[..]<br />
</animation><br />
</syntaxhighlight><br />
<br />
Animations which can utilize [[Expressions|Expressions]] are: <br />
* [[Howto:Animate_models#Translate|Translate]]<br />
* [[Howto:Animate_models#Rotate|Rotate]]<br />
* [[Howto:Animate_models#Scale|Scale]]<br />
* [[Howto:Animate_models#Range|Range]]<br />
* [[Howto:Animate_models#Blend|Blend]]<br />
<br />
See more detailed info at [[Expressions|Expressions]]<br />
<br />
== Lights ==<br />
As of January 2021 FlightGear supports multiple light sources just like Project Rembrandt has always done.<br />
[[Compositor#Lights|Adding lights to a model]]<br />
<br />
== Object animations ==<br />
=== Alpha-test ===<br />
<source><br />
<animation><br />
<type>alpha-test</type><br />
<object-name>Object</object-name><br />
<alpha-factor>0.01</alpha-factor><br />
</animation><br />
</source><br />
This "animation" is a way to set an alpha test on a model branch. The effect is to avoid depth buffer writing of pixel that are not seen because they are transparent. This is particulary useful when modeling a metallic structure or a tree with a billboard. The threshold of transparency is set with the <alpha-factor> element. See also [[Pixel testing in effects]].<br />
<br />
=== Blend ===<br />
Blends an object with the surrounding. Comparable to a translucency animation. A value of 0 corresponds to no transparency, i.e. and ordinary solid object, and a value of 1 makes the object fully transparent, i.e., not visible at all.<br />
<br />
<source><br />
<animation><br />
<type>blend</type><br />
<property>/velocities/airspeed-kt</property><br />
<factor>0.00025</factor><br />
<min>0.2</min><br />
<max>0.7</max><br />
</animation><br />
</source><br />
<br />
* '''property:'''<br />
* '''factor:'''<br />
* '''min:'''<br />
* '''max:'''<br />
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]<br />
<br />
Note that when using the Project Rembrandt renderer, all transparent and translucent objects must be registered to display properly. [[Project_Rembrandt#Registering_all_translucent_surfaces|More information here.]]<br />
<br />
=== Billboard ===<br />
This faces an object towards the viewer. Often used on 2D objects, like clouds, trees and lights.<br />
<br />
<source><br />
<animation><br />
<type>billboard</type><br />
<object-name>Object</object-name><br />
<spherical type="bool">true</spherical><br />
</animation><br />
</source><br />
<br />
* '''spherical:'''<br />
<br />
=== Dist-scale ===<br />
Used to scale an object, based on the distance to the viewer. <code><nowiki><ind></nowiki></code> and <code><nowiki><dep></nowiki></code> (independent and dependent) are the distance in meters and the scale at that distance.<br />
<br />
<source><br />
<animation><br />
<type>dist-scale</type><br />
<object-name>Object</object-name><br />
<interpolation><br />
<entry><br />
<ind>0</ind><br />
<dep>1</dep><br />
</entry><br />
<entry><br />
<ind>300</ind><br />
<dep>4</dep><br />
</entry><br />
<entry><br />
<ind>1500</ind><br />
<dep>8</dep><br />
</entry><br />
</interpolation><br />
</animation><br />
</source><br />
<br />
You can optionally add [[#Center|&lt;center&gt;]] coordinates, to scale the object around that point.<br />
<br />
=== Flash ===<br />
<br />
Used to scale an object based on the cosine of the angle between the axis provided in the animation and the view vector.<br />
<br />
<source><br />
<animation><br />
<type>flash</type><br />
<object-name>Object</object-name><br />
<offset>0.0</offset><br />
<factor>1.0</factor><br />
<power>2</power><br />
<two-sides type="bool">false</two-sides><br />
<min>0.0</min><br />
<max>1.0</max><br />
<center><br />
<x-m>0.0</x-m><br />
<y-m>0.0</y-m><br />
<z-m>0.0</z-m><br />
</center><br />
<axis><br />
<x>0.0</x><br />
<y>-1</y><br />
<z>0.1</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
* '''offset:'''<br />
* '''factor:'''<br />
* '''power:'''<br />
* '''two-sides:''' if false, nothing is drawn if the cosine is negative.<br />
* '''min:'''<br />
* '''max:'''<br />
<br />
scale = factor * pow( cosine, power ) + offset<br />
<br />
scale is then clamped between min and max.<br />
<br />
and this scale factor is applied to the object, from the center specified. It works best if scale is less than 1. Otherwise, there will be clipping issues.<br />
<br />
=== Noshadow ===<br />
This animation is used to make sure an object will cast no shadow.<br />
<br />
<source><br />
<animation><br />
<type>noshadow</type><br />
<object-name>Object</object-name><br />
</animation><br />
</source><br />
<br />
=== Range ===<br />
: ''See also [[Modeling - Getting Started#Level of Detail (LOD)]].''<br />
<br />
To prevent objects -like instruments- being drawn when the aircraft is actually too far away for them to be seen anyway, a range animation is used. <br />
<br />
<syntaxhighlight lang="xml"><br />
<animation><br />
<type>range</type><br />
<min-m>0</min-m><br />
<max-m>30</max-m><br />
</animation><br />
</syntaxhighlight><br />
<br />
* '''min-m:''' the shortest distance (in meters) from the object center at which it is visible.<br />
* '''max-m:''' the largest distance (in meters) from the object center at which it is visible.<br />
<br />
You could also use the generic level of detail (LOD) properties, which can be set by the user through View > Adjust LOD rangers: <br />
{| class="wikitable"<br />
! Property<br />
! Description<br />
! Default value<br />
|-<br />
|<tt>/sim/rendering/static-lod/bare</tt><br />
| only a rough exterior model<br />
| 30,000 m<br />
|-<br />
|<tt>/sim/rendering/static-lod/rough</tt> <br />
| most should be visible<br />
| 9,000 m<br />
|-<br />
|<tt>/sim/rendering/static-lod/detailed</tt> <br />
| all details should be visible<br />
| 1,500 m<br />
|}<br />
<br />
The animation code will look like this:<br />
<syntaxhighlight lang="xml"><br />
<animation><br />
<type>range</type><br />
<min-m>0</min-m><br />
<max-property>sim/rendering/static-lod/bare</max-property><br />
</animation><br />
</syntaxhighlight><br />
<br />
You can have both ranges (max and min) bound to a property, or just one of them.<br />
* '''min-property:''' <br />
* '''max-property:'''<br />
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]<br />
<br />
=== Rotate ===<br />
One of the most important and frequently used animations of all. It rotates an object to an absolute position in degrees, as provided by the property-value.<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>rotate</type><br />
<property>surface-positions/left-aileron-pos-norm</property><br />
<factor>25</factor><br />
<offset-deg>25</offset-deg><br />
<center><br />
<x-m>-1.50</x-m><br />
<y-m> 1 </y-m><br />
<z-m> 0.25</z-m><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
* '''factor:''' is optional.<br />
* '''offset-deg:''' is optional. Offset in degrees.<br />
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]<br />
<br />
=== Scale ===<br />
A scale animation scales (resizes) an object. This can be either property-value dependant (first example) or a fixed scale (second example).<br />
<br />
<source><br />
<animation><br />
<type>scale</type><br />
<object-name>Object</object-name><br />
<property>sim/time/sun-angle-rad</property><br />
<x-min>1.0</x-min><br />
<y-min>1.0</y-min><br />
<z-min>1.0</z-min><br />
<x-factor>1.4</x-factor><br />
<y-factor>1.4</y-factor><br />
<z-factor>2.0</z-factor><br />
</animation><br />
</source><br />
<br />
* ?-min: the mimimum scale factor for each axis. If the property value would result in a smaller factor than this setting, the scale animation will hold.<br />
* ?-factor: the scale factor for each axis (factor*property=scale factor).<br />
<br />
<source><br />
<animation><br />
<type>scale</type><br />
<x-offset>0.5</x-offset><br />
<y-offset>0.5</y-offset><br />
<z-offset>0.5</z-offset><br />
</animation><br />
</source><br />
<br />
* x.offset: the scale factor.<br />
* Add [[#Center|&lt;center&gt;]] coordinates, to scale the object around that point.<br />
* '''You can optionally use an [[Howto:Animate_models#Expressions|expression]] in the <factor> or <offset> inputs.''' For more details see [[Expressions|Expressions]]<br />
<br />
=== Select ===<br />
This animation selects (or unselects) objects when certain conditions are true (or false). The example below shows the object when the n1 of engine[1] is higher than 25%.<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>select</type><br />
<condition><br />
<greater-than><br />
<property>engines/engine[0]/n1</property><br />
<value>25</value><br />
</greater-than><br />
</condition><br />
</animation><br />
</source><br />
<br />
=== Shader ===<br />
<source><br />
<animation><br />
<type>shader</type><br />
<shader>chrome</shader><br />
<texture>chrome2.png</texture><br />
<object-name>Object</object-name><br />
</animation><br />
</source><br />
<br />
* '''shader:''' <br />
* '''texture:''' path to the texture used by the shader.<br />
<br />
=== Spin ===<br />
Very similar to [[#Rotate|rotate]], but the property provides a value in revolutions per minute (RPM) rather than an absolute position in degrees, and offset cannot be used.<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>spin</type><br />
<property>engines/engine[0]/n1</property><br />
<factor>25</factor><br />
<center><br />
<x-m>-1.50</x-m><br />
<y-m> 1 </y-m><br />
<z-m> 0.25</z-m><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
* '''factor:''' is optional.<br />
<br />
=== Timed ===<br />
Swtiches between objects at specified intervals. This example switches between a lights-on model and a lights-off model. Lights on are shown 0.2 seconds, while lights off are displayed for 0.8 seconds.<br />
<br />
<source><br />
<animation><br />
<type>timed</type><br />
<object-name>BacklightOn</object-name><br />
<object-name>BacklightOff</object-name><br />
<use-personality type="bool">true</use-personality><br />
<branch-duration-sec>0.8</branch-duration-sec><br />
<branch-duration-sec>0.2</branch-duration-sec><br />
</animation><br />
</source><br />
<br />
=== Tracking ===<br />
The new (in 2.11) [[Howto:Animate gear scissors using the tracking animation|''locked-track animation'']] can do exactly the same thing as the [https://docs.blender.org/manual/en/latest/animation/constraints/tracking/locked_track.html Locked Track constraint] available in Blender. However it can also be used to simulate simple inverse kinematic systems consisting of two bones connected with a revolute joint (aka hinge). See [[Howto:Animate gear scissors using the tracking animation|detailed explanation]].<br />
<br />
=== Translate ===<br />
The same as [[#Textranslate|textranslate]], but this animation moves a whole object (so including fixed textures). The example below will move an object in the y-direction:<br />
<br />
{| class="wikitable" border="0" cellspacing="0" <br />
!Property value<br />
!Output<br />
|-<br />
| -1<br />
| -2.5<br />
|-<br />
| 0<br />
| 2.5<br />
|-<br />
| 1<br />
| 7.5<br />
|}<br />
<br />
<source><br />
<animation><br />
<type>translate</type><br />
<object-name>Object</object-name><br />
<property>controls/seat/pilot/position-norm</property><br />
<factor>5</factor><br />
<offset-m>2.5</offset-m><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
When using interpolation tables such as:<br />
<source><br />
<interpolation><br />
<entry><ind>0.0</ind><dep> 0</dep></entry><br />
<entry><ind>0.666</ind><dep>0.18</dep></entry><br />
<entry><ind>1.0</ind><dep>0.27</dep></entry><br />
</interpolation><br />
</source><br />
The first figure (<ind> refers to the value of the property associated with the object and the second figure (in <dep>) refers to the amount that the object moves in metres. For example, in this case, the object moves 18cm when the value reads 0.66 and 27cm when the value is 1.<br />
<br />
'''IF used WTIHOUT property''' : The object is placed at some (Value of Offset) meters away from its original position, along the virtual axis formed by said original position and the point with coordinates x/y/z defined in the <axis> tag.<br />
Mathematically, assuming the Object to translate is (in the model space) placed at point A (x1, y1, z1) and you want to relocate it to point B (x2, y2, z2) then x2,y2,z2 are the values in the <axis> tag of the Translate animation and <offset> can be computed as SQRT((x2-x1)^2+(y2-y1)^2+(z2-z1)^2)<br />
<br />
<br />
* '''factor:''' is optional.<br />
* '''offset-m:''' is optional. Offset in meters.<br />
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]<br />
<br />
== Material animation ==<br />
An animation type that can be used in various ways. Of course you can combine the below mentiond systems into one (big) animation.<br />
<br />
<source><br />
<animation> <br />
<type>material</type> <br />
<object-name>Object</object-name><br />
<property-base>sim/model/c172p/material</property-base><br />
<global type="bool">true</global> <!-- This tag is no longer supported --><br />
...<br />
lines as mentioned below<br />
...<br />
</animation><br />
</source><br />
<br />
'''Optional:'''<br />
* '''property-base:''' when using prop(erties), you might want to set a property-base. All props will be relative to this path.<br />
* '''global (deprecated):''' by setting this to <tt>true</tt>, all objects using the same material as the defined object(s) (via <tt><object-name></tt>) will be affected by the animation. This is preferred to listing several objects in <object-name> tags. It's not only faster, but also doesn't break animations by forcing objects together. <span style="color:red; text-decoration: underline;">This tag is no longer supported</span><br />
<br />
'''Notes:'''<br />
* Numbers are clamped to 0.0-1.0, except "shininess", which is clamped to 0-128.<br />
* By appending <tt>-prop</tt> each of the material properties can read its value from another property.<br />
<br />
=== Ambient ===<br />
<source><br />
<ambient><br />
<red>1.0</red><br />
<green>0.2</green><br />
<blue>0.0</blue><br />
</ambient><br />
</source><br />
<br />
=== Diffuse ===<br />
<source><br />
<diffuse><br />
<red>1.0</red><br />
<green>0.2</green><br />
<blue>0.0</blue><br />
</diffuse><br />
</source><br />
<br />
=== Emission ===<br />
{{Main article|Howto: Illuminate faces}}<br />
<source><br />
<emission><br />
<red>1.0</red><br />
<green>0.2</green><br />
<blue>0.0</blue><br />
<factor-prop>controls/lighting/panel-norm</factor-prop><br />
</emission><br />
</source><br />
<br />
Emission colors are multiplied by the factor-prop value. 1 is maximum color intensity, while 0 is the minimum. Colors are calculated according to the [http://en.wikipedia.org/wiki/RGB_color_model RGB color model].<br />
<br />
=== Shininess ===<br />
Shininess is clamped to 0-128.<br />
<source><br />
<shininess>105</shininess><br />
</source><br />
<br />
=== Specular ===<br />
<source><br />
<specular><br />
<red>1.0</red><br />
<green>0.2</green><br />
<blue>0.0</blue><br />
</specular><br />
</source><br />
<br />
=== Texture ===<br />
Used for the [[Livery over MP]] system.<br />
<br />
<source><br />
<property-base>sim/model/livery</property-base> <br />
<texture-prop>engine</texture-prop> <br />
<texture>KLM.png</texture> <br />
</source><br />
<br />
=== Transparency ===<br />
<source><br />
<transparency><br />
<alpha-prop>rotors/tail/rpm</alpha-prop><br />
<factor>-0.0015</factor><br />
<offset>1</offset><br />
</transparency><br />
</source><br />
<br />
=== Threshold ===<br />
<source><br />
<threshold>0.001</threshold><br />
</source><br />
<br />
== Texture Animations ==<br />
<br />
Applying different matrix transformations to the textures of an object.<br />
<br />
=== Textranslate ===<br />
A very important animation for cockpits! This animation moves textures over a surface.<br />
<br />
<source><br />
<animation><br />
<type>textranslate</type><br />
<object-name>Object</object-name><br />
<property>autopilot/settings/target-speed-kt</property><br />
<bias>0.0001</bias><br />
<factor>0.001</factor><br />
<step>100</step><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
</axis><br />
</animation><br />
</source><br />
<br />
* '''bias:''' Adds an offset to the property before factor/step. A small value is needed to compensate for [http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems floating point accuracy].<br />
* '''factor:''' property * factor * texture width/height = the amount of pixels that the texture should be translated. If your texture is 256 pixels, an textranslate of 0.1 will result in the texture moving with 26 pixels, into the direction specified by the axis settings.<br />
* '''step:''' the step size at which the texture is translated. If this is set to 0.1, the texture will only be translated at 0.1, 0.2, 0.3 etc.<br />
* '''axis:''' the direction in which the texture is translated. Y is up/down, while X is left/right.<br />
<br />
=== Texrotate ===<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>texrotate</type><br />
<property>some/property/path</property><br />
<factor>25</factor><br />
<offset-deg>25</offset-deg><br />
<center><br />
<x>0.5</x><br />
<y>0.5</y><br />
<z>0</z><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>0</y><br />
<z>1</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
=== Textrapezoid ===<br />
<br />
<source><br />
<animation><br />
<type>textrapezoid</type><br />
<object-name>HUD.l.canvas</object-name><br />
<property>/hud/trapezoid-correction</property><br />
<side>bottom</side><br />
</animation><br />
</source><br />
<br />
* '''side''': side of quad which should be scaled (''top'' (default)/''right''/''bottom''/''left'')<br />
<br />
=== Texmultiple ===<br />
<br />
Only one texture matrix can be applied to each object. With ''textmultiple'' multiple texture animations can be combined into a single matrix, applied to the specified object.<br />
<br />
<source><br />
<animation><br />
<type>texmultiple</type><br />
<object-name>HUD.l.canvas</object-name><br />
<transform><br />
<subtype>textranslate</subtype><br />
<property>/hud/offset-x</property><br />
<axis><br />
<x>1</x><br />
<y>0</y><br />
<z>0</z><br />
</axis><br />
</transform><br />
<transform><br />
<subtype>textranslate</subtype><br />
<property>/hud/offset-y</property><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</transform><br />
<transform><br />
<subtype>textrapezoid</subtype><br />
<property>/hud/trapezoid-correction</property><br />
</transform><br />
</animation><br />
</source><br />
<br />
== Object interaction animations ==<br />
=== Enable-hot ===<br />
Scenery objects are automatically defined as solid by FlightGear, meaning that an aircraft can taxi on them and/or crash when touching. For certain objects (groundmarkings, beacon light-beams etc.) this might be an unwanted feature. The solidness can be disabled with the following animation:<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<enable-hot type="bool">false</enable-hot><br />
</animation><br />
</source><br />
<br />
* '''enable-hot:''' can be either true or false. Remember that objects are automatically solid, so it should not be necessary to set this at all when wanting solidness.<br />
<br />
=== Interactions ===<br />
<source><br />
<animation> <br />
<type>interaction</type> <br />
<object-name>Object</object-name> <br />
<interaction-type>carrier-wire</interaction-type> <br />
</animation> <br />
</source><br />
<br />
* '''interaction-type:''' can have the following values:<br />
**'''carrier-catapult:'''<br />
** '''carrier-wire:''' makes the object act as an arresting wire, as used on [[aircraft carrier]]s.<br />
<br />
== Direct manipulation animations ==<br />
=== Knob / slider (v. 2.11-) ===<br />
{{Main article|Knob / slider animation}}<br />
<br />
=== Pick ===<br />
{{Main article|Howto: Make a clickable panel#Pick}}<br />
<br />
=== Touch ===<br />
<br />
The touch animation provides the normalized coordinates of a touch (or click) event on a 2d surface. The coordinates are passed in the argument and can be accessed using cmdarg() in Nasal.<br />
<br />
* Touch animation is designed to work with a quad that is being used as a Canvas placement (display).<br />
* The touch animation must not be combined with a pick animation on the same object.<br />
* More info here: [[Touch Animation]]<br />
<br />
==== touch example ====<br />
<br />
<animation><br />
<type>touch</type><br />
<visible>true</visible><br />
<object-name>CanvasPlacement</object-name><br />
<action><br />
<touch>0</touch><br />
<repeatable>false</repeatable><br />
<binding><br />
<command>nasal</command><br />
<script>print("touch input (",cmdarg().getNode("x").getValue(),",",cmdarg().getNode("y").getValue())</script><br />
</binding><br />
</action><br />
</animation><br />
<br />
== Shadow Handling ==<br />
There exist several possibilites for handling of shadows. <br /><br />
See '''[[ALS_technical_notes|ALS Technical Notes]]''' and more specific '''[[ALS_technical_notes#ALS_fuselage_shadow_effect|Fuselage Shadow Effect with ALS]]''' for a relatively simple shadow handling.<br /><br />
See '''[[Project Rembrandt]]''' which - amongst other functionality - implements a very realistic shadow mapping.<br />
As of January 2021 Project Rembrandt was replaced by the '''[[Compositor]]''' renderer which combines both Project Rembrandt and ALS in a single rendering engine. This also means that the Fuselage Shadow Effect with ALS is now deprecated.<br />
<br />
== References ==<br />
{{Appendix|all|<br />
* {{cite web |url=http://www.opensubscriber.com/message/flightgear-devel@flightgear.org/958955.html |title="material" animation (and the bo105 as an example) |first=Melchior |last=Franz |date=22 March 2005 |work=FlightGear-devel mailinglist }}<br />
* {{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg01546.html |title=flash animation |first=Frederic |last=Bouvier |date=22 Feb 2006 |work=FlightGear-devel mailinglist }}<br />
}}<br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[MP Fallback models]]<br />
* [[Howto:Animate gear scissors]]<br />
* [[Howto:Animate helicopters]]<br />
* [[Howto:Creating 3D instruments]]<br />
<br />
=== Forum topics ===<br />
* {{forum link|t=37353|title=3d models, how to produce them in an understandable way}} (April 2020-) - Touches on the subject of not using LOD range animations in scenery models.<br />
* {{forum link|t=36545|title=speedo Drum settings}} (November 2019) - Animating a mechanical multi-digit drum counter<br />
<br />
[[Category:Aircraft enhancement|Animate models]]<br />
[[Category:Howto|Animate models]]<br />
[[Category:Modeling|Animate models]]<br />
[[Category:Scenery enhancement|Animate models]]</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=Howto:Animate_models&diff=134565Howto:Animate models2022-02-02T23:31:01Z<p>Cgdae: More information about using geometry object for axis.</p>
<hr />
<div>The real world is full of motion. To simulate this in [[FlightGear]], '''models must be animated'''.<br />
<br />
FlightGear allows you to animate models 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. <br />
<br />
This document provides basic information for all kind of animations. When animating your model, it is very helpful to find an aircraft with parts similar to yours and use it as an example. Cut and paste the code into your wrapper file and then edit to suit.<br />
<br />
== Notes ==<br />
=== File name of main model and animation XML file ===<br />
{{main article|Aircraft-set.xml#Not used for loading multiplayer aircraft}}<br />
The file name of the main model and animation XML file, or the .ac file if there is no XML file, (in essence the property <code>/sim/model/path</code>) will be the name of the aircraft that is transmitted when using [[multiplayer]] and will also be used for loading multiplayer aircraft.<br />
<br />
There is also a mechanism to substitute a full aircraft model with a simpler AI aircraft model if one is available at the same file path (including for example <code>Models/Boeing-797-800.xml</code>), but in <code>[[$FG_ROOT]]/'''AI'''/Aircraft/</code> instead of <code>$FG_ROOT/Aircraft/</code>.<br />
<br />
=== .ac files ===<br />
{{Main article|AC files: Understanding and changing .ac code#Identifying an object}}<br />
<br />
When referring to an .ac file in your xml animation, it is important that the <code><object-name></code> exactly matches the object named in the .ac file (this includes cases!). <br />
<br />
'''Note for SketchUp users:''' The spatial reference X/Y/Z used in animation to locate an object or a point are different from the ones in AC3D ie X values are the same in both but Y in animation must be matched to AC3D's -Z (Z value but opposite sign) and Z value in animation must be matched to AC3D's Y value. <br />
<br />
'''Note for SketchUp users:''' when exporting to AC3D in Sketchup, the .ac file will name the objects in your model to "blah" by default. You need to amend the relevant object names in your .ac file using text edit, so that the xml will work.<br />
<br />
=== Animation order ===<br />
Animations are executed by FlightGear in the order that they are read in the model's .xml file. Therefore, it is very important to pay attention to the order, especially when multiple animations are applied to the same object(s). Wrong ordering of animations might cause [[Howto:Animate models#Timed|timed]] animations (used to create flashing lights) to not work. For further details see this [https://sourceforge.net/p/flightgear/mailman/message/37090714/ thread] on the development mailing list. Updated [https://scenery.flightgear.org/app.php?c=Models&a=browse&shared=18 shared Effects models] will be available very soon.<br />
<br />
Similar problems can be encountered with the dist-scale instead of the timed animation.<br />
== Tags used in most animations ==<br />
=== Name ===<br />
With a name animation, you can group multiple objects. <br />
<br />
<source><br />
<animation><br />
<name>Collection1</name><br />
<object-name>Object1</object-name><br />
<object-name>Object2</object-name><br />
<object-name>Object3</object-name><br />
</animation><br />
</source><br />
<br />
The example above creates a "virtual object" with the name Collection1. In animation, we can animate this group of objects, by using:<br />
<br />
<source><br />
<object-name>Collection1</object-name><br />
</source><br />
<br />
=== Object-name ===<br />
These names are set in the 3D model. Each single object has a unique name; for easy identification it is advised to use descriptive names (LeftElevator, Rudder etc.). Animations are only applied to those objects that are mentioned in an object-name line (one object per line!). Animations lacking those, will be applied to the entire model.<br />
<br />
=== Property ===<br />
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 <code><property></code> to provide the property path:<br />
<br />
<source><br />
<animation><br />
<type>rotate</type><br />
<object-name>Rudder</object-name><br />
<property>controls/rudder</property><br />
</animation><br />
</source><br />
<br />
Note the omission of the leading slash '/' when referring to the property. This assures that when the model is used for AI or multiplayer traffic the animations will follow that of the AI controller instead of that of the user.<br />
<br />
=== Axis ===<br />
An axis part is required in every animation that involves a rotating or moving thing.<br />
<br />
<source><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</source><br />
<br />
The axis are similar to the ones of the 3D model. There is a difference between rotation and translation:<br />
* In rotation animations, the axis part defines around what axis the object rotates. Negative/positive values make the difference between counterclockwise and clockwise rotations.<br />
* In translate animations, the part defines along what axis the object moves. If the x-axis is poiting backwards, an x-value of -1 will result in forward motion.<br />
<br />
You could also define two points, between which FlightGear will calculate the correct axis. This makes the use of a [[#Center|<nowiki><center></nowiki>]] tag redundant! Such coordinates are extremely useful for animating control surfaces (rudder, elevators etc.).<br />
<br />
<source><br />
<axis> <br />
<x1-m> 4.9</x1-m><br />
<y1-m> 7.1</y1-m><br />
<z1-m>-1.0</z1-m><br />
<x2-m> 5.9</x2-m><br />
<y2-m>11.2</y2-m><br />
<z2-m>-0.5</z2-m><br />
</axis><br />
</source><br />
<br />
=== Center ===<br />
Various animations ([[#Rotate|rotate]], [[#Spin|spin]], [[#Scale|scale]]) move around a center point.<br />
<br />
<source><br />
<center><br />
<x-m>-1.50</x-m><br />
<y-m> 1 </y-m><br />
<z-m> 0.25</z-m><br />
</center><br />
</source><br />
<br />
The axis are similar to the ones of the 3D model, so finding coordinates is easily done in 3D modeling software.<br />
<br />
=== Using a geometry object for axis and centre (2017.2) ===<br />
<br />
Added in V2017.2 is support to allow a geometry object (a line segment with two vertices) that is used to define both the centre and the axis for an animation. This will work with rotate, translate and the knob animations.<br />
<br />
The axis line should be balanced, i.e. it should protrude equal amounts. The axis line should be normalized (i.e. 1m) as its length acts as a factor (affecting translate animations).<br />
<br />
The XML syntax for this is:<br />
<br />
<source><br />
<axis><br />
<object-name>some-object</object-name><br />
</axis><br />
</source><br />
<br />
If the <code><axis>...</axis></code> section is omitted entirely, <code>{object-name}-axis</code> will be used by default, where <code>{object-name}</code> is the name of the object being animated. In the earlier example this would be <code>Rudder-axis</code>.<br />
<br />
In the '''.ac''' file, specify a SURF with type (bottom 4 bits, 0=polygon, 1=closedline, 2=line) set to 2, and two vertices that define the axis. For example:<br />
<br />
OBJECT poly<br />
name "aileron.l-axis"<br />
numvert 2<br />
3.2077502191170844 0.18160835055097943 4.055616960642423<br />
2.6758650763079 0.28024033462188946 6.477876098622225<br />
numsurf 1<br />
SURF 0x12<br />
mat 0<br />
refs 2<br />
0 0 0<br />
1 0 0<br />
kids 0<br />
<br />
Once the object-name used for the axis has been processed the geometry object will be hidden. This also allows a visual check for any axis objects that are not yet assigned.<br />
<br />
It is possible to reuse the same object definition multiple times within a single XML file. <br />
<br />
[[File:Canopy-animation-axis-object.png|small|Illustration of where an axis object (2017.2) can be placed for a canopy]]<br />
<br />
[[File:Gauges-knobs-animation-axis-object.png|small|Illustration of where an axis object (2017.2) can be placed for cockpit elements]]<br />
<br />
== Additional tags that can be used in most animations ==<br />
=== Conditions ===<br />
Multiple animations can make use of a conditional. Check <tt>$FGDATA/Docs/README.conditions</tt> for some more details.<br />
<br />
* '''equals:''' property value (or second property) is equal to value/(first)property.<br />
* '''greater-than:''' property value (or second property) is larger than value/(first)property.<br />
* '''greater-than-equals:''' property value (or second property) is greater than or equal to value/(first)property.<br />
* '''less-than:''' property value (or second property) is smaller than value/(first)property.<br />
* '''less-than-equals:''' property value (or second property) is smaller than or equal to value/(first)property.<br />
<br />
The example below is true when n1 has a value greater than 25.<br />
<source><br />
<condition><br />
<greater-than><br />
<property>engines/engine[1]/n1</property><br />
<value>25</value><br />
</greater-than><br />
</condition><br />
</source><br />
<br />
Then there are some special tags:<br />
<br />
* '''and:'''<br />
* '''not:'''<br />
* '''or:'''<br />
<br />
In the example below, the condition is true when either n1 is greater than 25% or equal to 0%.<br />
<source><br />
<condition><br />
<or><br />
<greater-than><br />
<property>engines/engine[1]/n1</property><br />
<value>25</value><br />
</greater-than><br />
<equals><br />
<property>engines/engine[1]/n1</property><br />
<value>0</value><br />
</equals><br />
</or><br />
</condition><br />
</source><br />
<br />
An example of implementation into an animation looks as follows:<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>rotate</type><br />
<property>suface-positions/left-aileron-pos-norm</property><br />
<factor>25</factor><br />
<condition><br />
<greater-than><br />
<property>suface-positions/left-aileron-pos-norm</property><br />
<value>10</value><br />
</greater-than><br />
</condition><br />
<center><br />
<x-m>-1.50</x-m><br />
<y-m> 1 </y-m><br />
<z-m> 0.25</z-m><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
=== Interpolation ===<br />
For non-fixed factors, an interpolation "table" can be created. <br />
<br />
<source><br />
<interpolation><br />
<entry><br />
<ind> 0.0</ind><br />
<dep> 0.0</dep><br />
</entry><br />
<entry><br />
<ind> 0.667</ind><br />
<dep> 0.0</dep><br />
</entry><br />
<entry><br />
<ind> 1.0</ind><br />
<dep> 0.5</dep><br />
</entry><br />
</interpolation><br />
</source><br />
<br />
The lines above represent the following table:<br />
<br />
{|<br />
!Input<br />
!Output<br />
|-<br />
|0.0<br />
|0.0<br />
|-<br />
|0.667<br />
|0.0<br />
|-<br />
|1.0<br />
|0.5<br />
|}<br />
<br />
You can add as many entries as you need. Interpolation tables are often used for gear animations (eg. to open doors during gear-movements and close them again once the gear is either retracted or fully extended).<br />
<br />
=== Expressions ===<br />
For some animations it is possible to define complex animations by using [[Expressions|Expressions]]. This even allows to drive the animation from multiple properties without the need for additional Nasal scripts. Here is an example for a translate animation depending on two properties and the cosine function:<br />
<syntaxhighlight lang="xml"><br />
<animation><br />
<type>translate</type><br />
<expression><br />
<product><br />
<property>/my/factor-property</property><br />
<cos><br />
<deg2rad><br />
<property>/my/angular-property</property><br />
</deg2rad><br />
</cos><br />
</product><br />
</expression><br />
[..]more elements[..]<br />
</animation><br />
</syntaxhighlight><br />
<br />
Animations which can utilize [[Expressions|Expressions]] are: <br />
* [[Howto:Animate_models#Translate|Translate]]<br />
* [[Howto:Animate_models#Rotate|Rotate]]<br />
* [[Howto:Animate_models#Scale|Scale]]<br />
* [[Howto:Animate_models#Range|Range]]<br />
* [[Howto:Animate_models#Blend|Blend]]<br />
<br />
See more detailed info at [[Expressions|Expressions]]<br />
<br />
== Lights ==<br />
As of January 2021 FlightGear supports multiple light sources just like Project Rembrandt has always done.<br />
[[Compositor#Lights|Adding lights to a model]]<br />
<br />
== Object animations ==<br />
=== Alpha-test ===<br />
<source><br />
<animation><br />
<type>alpha-test</type><br />
<object-name>Object</object-name><br />
<alpha-factor>0.01</alpha-factor><br />
</animation><br />
</source><br />
This "animation" is a way to set an alpha test on a model branch. The effect is to avoid depth buffer writing of pixel that are not seen because they are transparent. This is particulary useful when modeling a metallic structure or a tree with a billboard. The threshold of transparency is set with the <alpha-factor> element. See also [[Pixel testing in effects]].<br />
<br />
=== Blend ===<br />
Blends an object with the surrounding. Comparable to a translucency animation. A value of 0 corresponds to no transparency, i.e. and ordinary solid object, and a value of 1 makes the object fully transparent, i.e., not visible at all.<br />
<br />
<source><br />
<animation><br />
<type>blend</type><br />
<property>/velocities/airspeed-kt</property><br />
<factor>0.00025</factor><br />
<min>0.2</min><br />
<max>0.7</max><br />
</animation><br />
</source><br />
<br />
* '''property:'''<br />
* '''factor:'''<br />
* '''min:'''<br />
* '''max:'''<br />
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]<br />
<br />
Note that when using the Project Rembrandt renderer, all transparent and translucent objects must be registered to display properly. [[Project_Rembrandt#Registering_all_translucent_surfaces|More information here.]]<br />
<br />
=== Billboard ===<br />
This faces an object towards the viewer. Often used on 2D objects, like clouds, trees and lights.<br />
<br />
<source><br />
<animation><br />
<type>billboard</type><br />
<object-name>Object</object-name><br />
<spherical type="bool">true</spherical><br />
</animation><br />
</source><br />
<br />
* '''spherical:'''<br />
<br />
=== Dist-scale ===<br />
Used to scale an object, based on the distance to the viewer. <code><nowiki><ind></nowiki></code> and <code><nowiki><dep></nowiki></code> (independent and dependent) are the distance in meters and the scale at that distance.<br />
<br />
<source><br />
<animation><br />
<type>dist-scale</type><br />
<object-name>Object</object-name><br />
<interpolation><br />
<entry><br />
<ind>0</ind><br />
<dep>1</dep><br />
</entry><br />
<entry><br />
<ind>300</ind><br />
<dep>4</dep><br />
</entry><br />
<entry><br />
<ind>1500</ind><br />
<dep>8</dep><br />
</entry><br />
</interpolation><br />
</animation><br />
</source><br />
<br />
You can optionally add [[#Center|&lt;center&gt;]] coordinates, to scale the object around that point.<br />
<br />
=== Flash ===<br />
<br />
Used to scale an object based on the cosine of the angle between the axis provided in the animation and the view vector.<br />
<br />
<source><br />
<animation><br />
<type>flash</type><br />
<object-name>Object</object-name><br />
<offset>0.0</offset><br />
<factor>1.0</factor><br />
<power>2</power><br />
<two-sides type="bool">false</two-sides><br />
<min>0.0</min><br />
<max>1.0</max><br />
<center><br />
<x-m>0.0</x-m><br />
<y-m>0.0</y-m><br />
<z-m>0.0</z-m><br />
</center><br />
<axis><br />
<x>0.0</x><br />
<y>-1</y><br />
<z>0.1</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
* '''offset:'''<br />
* '''factor:'''<br />
* '''power:'''<br />
* '''two-sides:''' if false, nothing is drawn if the cosine is negative.<br />
* '''min:'''<br />
* '''max:'''<br />
<br />
scale = factor * pow( cosine, power ) + offset<br />
<br />
scale is then clamped between min and max.<br />
<br />
and this scale factor is applied to the object, from the center specified. It works best if scale is less than 1. Otherwise, there will be clipping issues.<br />
<br />
=== Noshadow ===<br />
This animation is used to make sure an object will cast no shadow.<br />
<br />
<source><br />
<animation><br />
<type>noshadow</type><br />
<object-name>Object</object-name><br />
</animation><br />
</source><br />
<br />
=== Range ===<br />
: ''See also [[Modeling - Getting Started#Level of Detail (LOD)]].''<br />
<br />
To prevent objects -like instruments- being drawn when the aircraft is actually too far away for them to be seen anyway, a range animation is used. <br />
<br />
<syntaxhighlight lang="xml"><br />
<animation><br />
<type>range</type><br />
<min-m>0</min-m><br />
<max-m>30</max-m><br />
</animation><br />
</syntaxhighlight><br />
<br />
* '''min-m:''' the shortest distance (in meters) from the object center at which it is visible.<br />
* '''max-m:''' the largest distance (in meters) from the object center at which it is visible.<br />
<br />
You could also use the generic level of detail (LOD) properties, which can be set by the user through View > Adjust LOD rangers: <br />
{| class="wikitable"<br />
! Property<br />
! Description<br />
! Default value<br />
|-<br />
|<tt>/sim/rendering/static-lod/bare</tt><br />
| only a rough exterior model<br />
| 30,000 m<br />
|-<br />
|<tt>/sim/rendering/static-lod/rough</tt> <br />
| most should be visible<br />
| 9,000 m<br />
|-<br />
|<tt>/sim/rendering/static-lod/detailed</tt> <br />
| all details should be visible<br />
| 1,500 m<br />
|}<br />
<br />
The animation code will look like this:<br />
<syntaxhighlight lang="xml"><br />
<animation><br />
<type>range</type><br />
<min-m>0</min-m><br />
<max-property>sim/rendering/static-lod/bare</max-property><br />
</animation><br />
</syntaxhighlight><br />
<br />
You can have both ranges (max and min) bound to a property, or just one of them.<br />
* '''min-property:''' <br />
* '''max-property:'''<br />
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]<br />
<br />
=== Rotate ===<br />
One of the most important and frequently used animations of all. It rotates an object to an absolute position in degrees, as provided by the property-value.<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>rotate</type><br />
<property>surface-positions/left-aileron-pos-norm</property><br />
<factor>25</factor><br />
<offset-deg>25</offset-deg><br />
<center><br />
<x-m>-1.50</x-m><br />
<y-m> 1 </y-m><br />
<z-m> 0.25</z-m><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
* '''factor:''' is optional.<br />
* '''offset-deg:''' is optional. Offset in degrees.<br />
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]<br />
<br />
=== Scale ===<br />
A scale animation scales (resizes) an object. This can be either property-value dependant (first example) or a fixed scale (second example).<br />
<br />
<source><br />
<animation><br />
<type>scale</type><br />
<object-name>Object</object-name><br />
<property>sim/time/sun-angle-rad</property><br />
<x-min>1.0</x-min><br />
<y-min>1.0</y-min><br />
<z-min>1.0</z-min><br />
<x-factor>1.4</x-factor><br />
<y-factor>1.4</y-factor><br />
<z-factor>2.0</z-factor><br />
</animation><br />
</source><br />
<br />
* ?-min: the mimimum scale factor for each axis. If the property value would result in a smaller factor than this setting, the scale animation will hold.<br />
* ?-factor: the scale factor for each axis (factor*property=scale factor).<br />
<br />
<source><br />
<animation><br />
<type>scale</type><br />
<x-offset>0.5</x-offset><br />
<y-offset>0.5</y-offset><br />
<z-offset>0.5</z-offset><br />
</animation><br />
</source><br />
<br />
* x.offset: the scale factor.<br />
* Add [[#Center|&lt;center&gt;]] coordinates, to scale the object around that point.<br />
* '''You can optionally use an [[Howto:Animate_models#Expressions|expression]] in the <factor> or <offset> inputs.''' For more details see [[Expressions|Expressions]]<br />
<br />
=== Select ===<br />
This animation selects (or unselects) objects when certain conditions are true (or false). The example below shows the object when the n1 of engine[1] is higher than 25%.<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>select</type><br />
<condition><br />
<greater-than><br />
<property>engines/engine[0]/n1</property><br />
<value>25</value><br />
</greater-than><br />
</condition><br />
</animation><br />
</source><br />
<br />
=== Shader ===<br />
<source><br />
<animation><br />
<type>shader</type><br />
<shader>chrome</shader><br />
<texture>chrome2.png</texture><br />
<object-name>Object</object-name><br />
</animation><br />
</source><br />
<br />
* '''shader:''' <br />
* '''texture:''' path to the texture used by the shader.<br />
<br />
=== Spin ===<br />
Very similar to [[#Rotate|rotate]], but the property provides a value in revolutions per minute (RPM) rather than an absolute position in degrees, and offset cannot be used.<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>spin</type><br />
<property>engines/engine[0]/n1</property><br />
<factor>25</factor><br />
<center><br />
<x-m>-1.50</x-m><br />
<y-m> 1 </y-m><br />
<z-m> 0.25</z-m><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
* '''factor:''' is optional.<br />
<br />
=== Timed ===<br />
Swtiches between objects at specified intervals. This example switches between a lights-on model and a lights-off model. Lights on are shown 0.2 seconds, while lights off are displayed for 0.8 seconds.<br />
<br />
<source><br />
<animation><br />
<type>timed</type><br />
<object-name>BacklightOn</object-name><br />
<object-name>BacklightOff</object-name><br />
<use-personality type="bool">true</use-personality><br />
<branch-duration-sec>0.8</branch-duration-sec><br />
<branch-duration-sec>0.2</branch-duration-sec><br />
</animation><br />
</source><br />
<br />
=== Tracking ===<br />
The new (in 2.11) [[Howto:Animate gear scissors using the tracking animation|''locked-track animation'']] can do exactly the same thing as the [https://docs.blender.org/manual/en/latest/animation/constraints/tracking/locked_track.html Locked Track constraint] available in Blender. However it can also be used to simulate simple inverse kinematic systems consisting of two bones connected with a revolute joint (aka hinge). See [[Howto:Animate gear scissors using the tracking animation|detailed explanation]].<br />
<br />
=== Translate ===<br />
The same as [[#Textranslate|textranslate]], but this animation moves a whole object (so including fixed textures). The example below will move an object in the y-direction:<br />
<br />
{| class="wikitable" border="0" cellspacing="0" <br />
!Property value<br />
!Output<br />
|-<br />
| -1<br />
| -2.5<br />
|-<br />
| 0<br />
| 2.5<br />
|-<br />
| 1<br />
| 7.5<br />
|}<br />
<br />
<source><br />
<animation><br />
<type>translate</type><br />
<object-name>Object</object-name><br />
<property>controls/seat/pilot/position-norm</property><br />
<factor>5</factor><br />
<offset-m>2.5</offset-m><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
When using interpolation tables such as:<br />
<source><br />
<interpolation><br />
<entry><ind>0.0</ind><dep> 0</dep></entry><br />
<entry><ind>0.666</ind><dep>0.18</dep></entry><br />
<entry><ind>1.0</ind><dep>0.27</dep></entry><br />
</interpolation><br />
</source><br />
The first figure (<ind> refers to the value of the property associated with the object and the second figure (in <dep>) refers to the amount that the object moves in metres. For example, in this case, the object moves 18cm when the value reads 0.66 and 27cm when the value is 1.<br />
<br />
'''IF used WTIHOUT property''' : The object is placed at some (Value of Offset) meters away from its original position, along the virtual axis formed by said original position and the point with coordinates x/y/z defined in the <axis> tag.<br />
Mathematically, assuming the Object to translate is (in the model space) placed at point A (x1, y1, z1) and you want to relocate it to point B (x2, y2, z2) then x2,y2,z2 are the values in the <axis> tag of the Translate animation and <offset> can be computed as SQRT((x2-x1)^2+(y2-y1)^2+(z2-z1)^2)<br />
<br />
<br />
* '''factor:''' is optional.<br />
* '''offset-m:''' is optional. Offset in meters.<br />
* '''[[Howto:Animate_models#Expressions|expression]]:''' is optional. For more details see [[Expressions|Expressions]]<br />
<br />
== Material animation ==<br />
An animation type that can be used in various ways. Of course you can combine the below mentiond systems into one (big) animation.<br />
<br />
<source><br />
<animation> <br />
<type>material</type> <br />
<object-name>Object</object-name><br />
<property-base>sim/model/c172p/material</property-base><br />
<global type="bool">true</global> <!-- This tag is no longer supported --><br />
...<br />
lines as mentioned below<br />
...<br />
</animation><br />
</source><br />
<br />
'''Optional:'''<br />
* '''property-base:''' when using prop(erties), you might want to set a property-base. All props will be relative to this path.<br />
* '''global (deprecated):''' by setting this to <tt>true</tt>, all objects using the same material as the defined object(s) (via <tt><object-name></tt>) will be affected by the animation. This is preferred to listing several objects in <object-name> tags. It's not only faster, but also doesn't break animations by forcing objects together. <span style="color:red; text-decoration: underline;">This tag is no longer supported</span><br />
<br />
'''Notes:'''<br />
* Numbers are clamped to 0.0-1.0, except "shininess", which is clamped to 0-128.<br />
* By appending <tt>-prop</tt> each of the material properties can read its value from another property.<br />
<br />
=== Ambient ===<br />
<source><br />
<ambient><br />
<red>1.0</red><br />
<green>0.2</green><br />
<blue>0.0</blue><br />
</ambient><br />
</source><br />
<br />
=== Diffuse ===<br />
<source><br />
<diffuse><br />
<red>1.0</red><br />
<green>0.2</green><br />
<blue>0.0</blue><br />
</diffuse><br />
</source><br />
<br />
=== Emission ===<br />
{{Main article|Howto: Illuminate faces}}<br />
<source><br />
<emission><br />
<red>1.0</red><br />
<green>0.2</green><br />
<blue>0.0</blue><br />
<factor-prop>controls/lighting/panel-norm</factor-prop><br />
</emission><br />
</source><br />
<br />
Emission colors are multiplied by the factor-prop value. 1 is maximum color intensity, while 0 is the minimum. Colors are calculated according to the [http://en.wikipedia.org/wiki/RGB_color_model RGB color model].<br />
<br />
=== Shininess ===<br />
Shininess is clamped to 0-128.<br />
<source><br />
<shininess>105</shininess><br />
</source><br />
<br />
=== Specular ===<br />
<source><br />
<specular><br />
<red>1.0</red><br />
<green>0.2</green><br />
<blue>0.0</blue><br />
</specular><br />
</source><br />
<br />
=== Texture ===<br />
Used for the [[Livery over MP]] system.<br />
<br />
<source><br />
<property-base>sim/model/livery</property-base> <br />
<texture-prop>engine</texture-prop> <br />
<texture>KLM.png</texture> <br />
</source><br />
<br />
=== Transparency ===<br />
<source><br />
<transparency><br />
<alpha-prop>rotors/tail/rpm</alpha-prop><br />
<factor>-0.0015</factor><br />
<offset>1</offset><br />
</transparency><br />
</source><br />
<br />
=== Threshold ===<br />
<source><br />
<threshold>0.001</threshold><br />
</source><br />
<br />
== Texture Animations ==<br />
<br />
Applying different matrix transformations to the textures of an object.<br />
<br />
=== Textranslate ===<br />
A very important animation for cockpits! This animation moves textures over a surface.<br />
<br />
<source><br />
<animation><br />
<type>textranslate</type><br />
<object-name>Object</object-name><br />
<property>autopilot/settings/target-speed-kt</property><br />
<bias>0.0001</bias><br />
<factor>0.001</factor><br />
<step>100</step><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
</axis><br />
</animation><br />
</source><br />
<br />
* '''bias:''' Adds an offset to the property before factor/step. A small value is needed to compensate for [http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems floating point accuracy].<br />
* '''factor:''' property * factor * texture width/height = the amount of pixels that the texture should be translated. If your texture is 256 pixels, an textranslate of 0.1 will result in the texture moving with 26 pixels, into the direction specified by the axis settings.<br />
* '''step:''' the step size at which the texture is translated. If this is set to 0.1, the texture will only be translated at 0.1, 0.2, 0.3 etc.<br />
* '''axis:''' the direction in which the texture is translated. Y is up/down, while X is left/right.<br />
<br />
=== Texrotate ===<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<type>texrotate</type><br />
<property>some/property/path</property><br />
<factor>25</factor><br />
<offset-deg>25</offset-deg><br />
<center><br />
<x>0.5</x><br />
<y>0.5</y><br />
<z>0</z><br />
</center><br />
<axis><br />
<x>0</x><br />
<y>0</y><br />
<z>1</z><br />
</axis><br />
</animation><br />
</source><br />
<br />
=== Textrapezoid ===<br />
<br />
<source><br />
<animation><br />
<type>textrapezoid</type><br />
<object-name>HUD.l.canvas</object-name><br />
<property>/hud/trapezoid-correction</property><br />
<side>bottom</side><br />
</animation><br />
</source><br />
<br />
* '''side''': side of quad which should be scaled (''top'' (default)/''right''/''bottom''/''left'')<br />
<br />
=== Texmultiple ===<br />
<br />
Only one texture matrix can be applied to each object. With ''textmultiple'' multiple texture animations can be combined into a single matrix, applied to the specified object.<br />
<br />
<source><br />
<animation><br />
<type>texmultiple</type><br />
<object-name>HUD.l.canvas</object-name><br />
<transform><br />
<subtype>textranslate</subtype><br />
<property>/hud/offset-x</property><br />
<axis><br />
<x>1</x><br />
<y>0</y><br />
<z>0</z><br />
</axis><br />
</transform><br />
<transform><br />
<subtype>textranslate</subtype><br />
<property>/hud/offset-y</property><br />
<axis><br />
<x>0</x><br />
<y>1</y><br />
<z>0</z><br />
</axis><br />
</transform><br />
<transform><br />
<subtype>textrapezoid</subtype><br />
<property>/hud/trapezoid-correction</property><br />
</transform><br />
</animation><br />
</source><br />
<br />
== Object interaction animations ==<br />
=== Enable-hot ===<br />
Scenery objects are automatically defined as solid by FlightGear, meaning that an aircraft can taxi on them and/or crash when touching. For certain objects (groundmarkings, beacon light-beams etc.) this might be an unwanted feature. The solidness can be disabled with the following animation:<br />
<br />
<source><br />
<animation><br />
<object-name>Object</object-name><br />
<enable-hot type="bool">false</enable-hot><br />
</animation><br />
</source><br />
<br />
* '''enable-hot:''' can be either true or false. Remember that objects are automatically solid, so it should not be necessary to set this at all when wanting solidness.<br />
<br />
=== Interactions ===<br />
<source><br />
<animation> <br />
<type>interaction</type> <br />
<object-name>Object</object-name> <br />
<interaction-type>carrier-wire</interaction-type> <br />
</animation> <br />
</source><br />
<br />
* '''interaction-type:''' can have the following values:<br />
**'''carrier-catapult:'''<br />
** '''carrier-wire:''' makes the object act as an arresting wire, as used on [[aircraft carrier]]s.<br />
<br />
== Direct manipulation animations ==<br />
=== Knob / slider (v. 2.11-) ===<br />
{{Main article|Knob / slider animation}}<br />
<br />
=== Pick ===<br />
{{Main article|Howto: Make a clickable panel#Pick}}<br />
<br />
=== Touch ===<br />
<br />
The touch animation provides the normalized coordinates of a touch (or click) event on a 2d surface. The coordinates are passed in the argument and can be accessed using cmdarg() in Nasal.<br />
<br />
* Touch animation is designed to work with a quad that is being used as a Canvas placement (display).<br />
* The touch animation must not be combined with a pick animation on the same object.<br />
* More info here: [[Touch Animation]]<br />
<br />
==== touch example ====<br />
<br />
<animation><br />
<type>touch</type><br />
<visible>true</visible><br />
<object-name>CanvasPlacement</object-name><br />
<action><br />
<touch>0</touch><br />
<repeatable>false</repeatable><br />
<binding><br />
<command>nasal</command><br />
<script>print("touch input (",cmdarg().getNode("x").getValue(),",",cmdarg().getNode("y").getValue())</script><br />
</binding><br />
</action><br />
</animation><br />
<br />
== Shadow Handling ==<br />
There exist several possibilites for handling of shadows. <br /><br />
See '''[[ALS_technical_notes|ALS Technical Notes]]''' and more specific '''[[ALS_technical_notes#ALS_fuselage_shadow_effect|Fuselage Shadow Effect with ALS]]''' for a relatively simple shadow handling.<br /><br />
See '''[[Project Rembrandt]]''' which - amongst other functionality - implements a very realistic shadow mapping.<br />
As of January 2021 Project Rembrandt was replaced by the '''[[Compositor]]''' renderer which combines both Project Rembrandt and ALS in a single rendering engine. This also means that the Fuselage Shadow Effect with ALS is now deprecated.<br />
<br />
== References ==<br />
{{Appendix|all|<br />
* {{cite web |url=http://www.opensubscriber.com/message/flightgear-devel@flightgear.org/958955.html |title="material" animation (and the bo105 as an example) |first=Melchior |last=Franz |date=22 March 2005 |work=FlightGear-devel mailinglist }}<br />
* {{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg01546.html |title=flash animation |first=Frederic |last=Bouvier |date=22 Feb 2006 |work=FlightGear-devel mailinglist }}<br />
}}<br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[MP Fallback models]]<br />
* [[Howto:Animate gear scissors]]<br />
* [[Howto:Animate helicopters]]<br />
* [[Howto:Creating 3D instruments]]<br />
<br />
=== Forum topics ===<br />
* {{forum link|t=37353|title=3d models, how to produce them in an understandable way}} (April 2020-) - Touches on the subject of not using LOD range animations in scenery models.<br />
* {{forum link|t=36545|title=speedo Drum settings}} (November 2019) - Animating a mechanical multi-digit drum counter<br />
<br />
[[Category:Aircraft enhancement|Animate models]]<br />
[[Category:Howto|Animate models]]<br />
[[Category:Modeling|Animate models]]<br />
[[Category:Scenery enhancement|Animate models]]</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=Video_encoding&diff=134524Video encoding2022-01-25T21:48:39Z<p>Cgdae: </p>
<hr />
<div>== Overview ==<br />
<br />
Flightgear on next (the development branch) has support for video encoding of the main window. This requires that ffmpeg/libav libraries are available at build time.<br />
<br />
* Videos are generated in the current directory. This can be changed by setting property '''/sim/video/directory'''.<br />
* Video files are called '''fgvideo-<aircraft>-YYYYMMDD-HHMMSS.<container>''', for example '''fgvideo-harrier-gr3-20211209-234105.mp4'''.<br />
* A convenience link is created that points to the latest video, called '''fgvideo-<aircraft>.<container>''', for example '''fgvideo-harrier-gr3.mp4''' -> '''fgvideo-harrier-gr3-20211209-234105.mp4'''.<br />
<br />
== Limitations ==<br />
<br />
* As of 2021-12-12, only Unix builds of Flightgear include support for video encoding by default.<br />
** On other platforms, if ffmpeg libraries are installed on the system, Flightgear's cmake might pick them up automatically and enable video encoding, but this hasn't been tested.<br />
* We do not (yet) record sound.<br />
* Prior to 2021-12-19, fixed-dt only worked in [[SimpleTime]] mode (see menu '''File/Time Mode''' and/or property '''/sim/time/simple-time/enabled''').<br />
<br />
== Building ==<br />
<br />
On Unix, we require these libraries and their header files to be available at build time:<br />
<br />
* avcodec<br />
* avuti<br />
* swscale<br />
* avformat<br />
<br />
If these libraries are installed, a standard cmake build should automatically include video encoding support.<br />
<br />
As of 2021-12-27, [[Scripted_Compilation_on_Linux_Debian/Ubuntu|download_and_compile.sh]] installs these libraries automatically.<br />
<br />
On Devuan (and probably other Debian-based distributions), they can be manually installed with:<br />
<br />
sudo apt install libavcodec-dev libavutil-dev libswscale-dev libavformat-dev<br />
<br />
== Creating video of live Flightgear ==<br />
<br />
=== Starting/stopping video encoding ===<br />
<br />
Use menu items '''File/Video Start''' and '''File/Video Stop''' to start/stop video encoding.<br />
<br />
* If an error occurs, for example support for video encoding was not included at build time, Flightgear will show a popup warning message.<br />
<br />
=== Video encoding settings ===<br />
[[File:Video-control dialogue.png|thumb]]<br />
Menu '''File/Video Control''' opens a dialogue that allows control over various settings, including:<br />
<br />
* Container name, such as '''mp4''' or '''ogv'''.<br />
** Radio buttons are provided for common containers.<br />
** Run '''ffmpeg -formats''' in a separate terminal to see what containers are available on your system.<br />
* Codec name, such as '''mpeg2video''', '''libx264''', '''libx265'''.<br />
** Radio buttons are provided for common codecs.<br />
** Run '''ffmpeg -codecs''' in a separate terminal to see what codecs are available on your system.<br />
* Encoding quality in range '''0..1'''. Use '''-1''' for codec's default.<br />
* Encoding speed in range '''0..1'''. Use '''-1''' for codec's default.<br />
* Encoding target bitrate in bits per second. Use '''0''' for codec's default.<br />
<br />
== Creating video from Flightgear recordings ==<br />
<br />
Flightgear can automatically generate a video when replaying a recording file, stopping video encoding when we reach the end of the recording.<br />
<br />
Usually one would use a Continuous recording for this, as they contain full information regardless of the recording duration.<br />
<br />
* From within Flightgear:<br />
** In the '''Load Flight Recorder Tape''' dialogue, set the '''Auto-create video''' checkbox.<br />
** Optionally also set '''Fixed dt''' (see below).<br />
<br />
* With the command line '''--load-tape''' option:<br />
** Also specify '''--load-tape-create-video'''.<br />
** Optionally specify '''--load-tape-fixed-dt=...''' (see below).<br />
<br />
=== Using '''fixed-dt''' ===<br />
<br />
Setting '''fixed-dt''' to a non-zero value forces Flightgear to increment the FDM time in seconds by the specified amount each frame, instead of by the elapsed real-world time between frames. For example using a value of 0.04 will force a frame rate of 25fps.<br />
<br />
This allows creation of high quality videos from recordings, regardless of the rendering settings or speed of the host, at the expense of potentially taking longer than real time to create the recording.<br />
<br />
=== Command line examples ===<br />
<br />
Create a high quality video of a recording by running Flightgear with these command-line args:<br />
<br />
'''--load-tape=... --load-tape-create-video=1 --prop:bool:/sim/time/simple-time/enabled=true --load-tape-fixed-dt=0.04 --graphics-preset=high-quality'''<br />
<br />
Also fix video settings by setting the relevant properties:<br />
<br />
'''--load-tape=... --load-tape-create-video=1 --prop:bool:/sim/time/simple-time/enabled=true --load-tape-fixed-dt=0.04 --graphics-preset=high-quality --prop:/sim/video/container=mp4 --prop:/sim/video/codec=libx265 --prop:/sim/video/quality=0.75 --prop:/sim/video/speed=1'''<br />
<br />
=== Example video ===<br />
<br />
This 5 minute video flying around Manhattan with high rendering settings was created on a fairly slow laptop, taking about an hour to replay and encode: http://op59.net/fgvideo-harrier-gr3-20211206-230342-manhattan.mp4</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=Video_encoding&diff=134523Video encoding2022-01-25T20:53:05Z<p>Cgdae: /* Video encoding settings */</p>
<hr />
<div>== Overview ==<br />
<br />
Flightgear on next has support for video encoding of the main window. This requires that ffmpeg/libav libraries are available at build time.<br />
<br />
Videos are generated in the current directory. This can be changed by setting property '''/sim/video/directory'''.<br />
<br />
== Limitations ==<br />
<br />
* As of 2021-12-12, only Unix builds of Flightgear include support for video encoding by default.<br />
** On other platforms, if ffmpeg libraries are installed on the system, Flightgear's cmake might pick them up automatically and enable video encoding, but this hasn't been tested.<br />
* We do not (yet) record sound.<br />
* Prior to 2021-12-19, fixed-dt only worked in [[SimpleTime]] mode (see menu '''File/Time Mode''' and/or property '''/sim/time/simple-time/enabled''').<br />
<br />
== Building ==<br />
<br />
On Unix, we require these libraries and their header files to be available at build time:<br />
<br />
* avcodec<br />
* avuti<br />
* swscale<br />
* avformat<br />
<br />
If these libraries are installed, a standard cmake build should automatically include video encoding support.<br />
<br />
As of 2021-12-27, [[Scripted_Compilation_on_Linux_Debian/Ubuntu|download_and_compile.sh]] installs these libraries automatically.<br />
<br />
On Devuan (and probably other Debian-based distributions), they can be manually installed with:<br />
<br />
sudo apt install libavcodec-dev libavutil-dev libswscale-dev libavformat-dev<br />
<br />
== Creating video of live Flightgear ==<br />
<br />
=== Starting/stopping video encoding ===<br />
<br />
Use menu items '''File/Video Start''' and '''File/Video Stop''' to start/stop video encoding.<br />
<br />
* Videos files are called '''fgvideo-<aircraft>-YYYYMMDD-HHMMSS.<container>''', for example '''fgvideo-harrier-gr3-20211209-234105.mp4'''.<br />
* A convenience link is created that points to the latest video, called '''fgvideo-<aircraft>.<container>''', for example '''fgvideo-harrier-gr3.mp4''' -> '''fgvideo-harrier-gr3-20211209-234105.mp4'''.<br />
* If an error occurs, for example support for video encoding was not included at build time, Flightgear will show a popup warning message.<br />
<br />
=== Video encoding settings ===<br />
[[File:Video-control dialogue.png|thumb]]<br />
Menu '''File/Video Control''' opens a dialogue that allows control over various settings, including:<br />
<br />
* Container name, such as '''mp4''' or '''ogv'''.<br />
** Radio buttons are provided for common containers.<br />
** Run '''ffmpeg -formats''' in a separate terminal to see what containers are available on your system.<br />
* Codec name, such as '''mpeg2video''', '''libx264''', '''libx265'''.<br />
** Radio buttons are provided for common codecs.<br />
** Run '''ffmpeg -codecs''' in a separate terminal to see what codecs are available on your system.<br />
* Encoding quality in range '''0..1'''. Use '''-1''' for codec's default.<br />
* Encoding speed in range '''0..1'''. Use '''-1''' for codec's default.<br />
* Encoding target bitrate in bits per second. Use '''0''' for codec's default.<br />
<br />
== Creating video from Flightgear recordings ==<br />
<br />
Flightgear can automatically generate a video when replaying a recording file, stopping video encoding when we reach the end of the recording.<br />
<br />
Usually one would use a Continuous recording for this, as they contain full information regardless of the recording duration.<br />
<br />
* From within Flightgear:<br />
** In the '''Load Flight Recorder Tape''' dialogue, set the '''Auto-create video''' checkbox.<br />
** Optionally also set '''Fixed dt''' (see below).<br />
<br />
* With the command line '''--load-tape''' option:<br />
** Also specify '''--load-tape-create-video'''.<br />
** Optionally specify '''--load-tape-fixed-dt=...''' (see below).<br />
<br />
=== Using '''fixed-dt''' ===<br />
<br />
Setting '''fixed-dt''' to a non-zero value forces Flightgear to increment the FDM time in seconds by the specified amount each frame, instead of by the elapsed real-world time between frames. For example using a value of 0.04 will force a frame rate of 25fps.<br />
<br />
This allows creation of high quality videos from recordings, regardless of the rendering settings or speed of the host, at the expense of potentially taking longer than real time to replay the recording.<br />
<br />
<br />
=== Command line examples ===<br />
<br />
Create a high quality video of a recording by running Flightgear with these command-line args:<br />
<br />
'''--load-tape=... --load-tape-create-video=1 --prop:bool:/sim/time/simple-time/enabled=true --load-tape-fixed-dt=0.04 --graphics-preset=high-quality'''<br />
<br />
Also fix video settings by setting the relevant properties:<br />
<br />
'''--load-tape=... --load-tape-create-video=1 --prop:bool:/sim/time/simple-time/enabled=true --load-tape-fixed-dt=0.04 --graphics-preset=high-quality --prop:/sim/video/container=mp4 --prop:/sim/video/codec=libx265 --prop:/sim/video/quality=0.75 --prop:/sim/video/speed=1'''<br />
<br />
=== Example video ===<br />
<br />
This 5 minute video flying around Manhattan with high rendering settings was created on a fairly slow laptop, taking about an hour to replay and encode: http://op59.net/fgvideo-harrier-gr3-20211206-230342-manhattan.mp4</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=Video_encoding&diff=134522Video encoding2022-01-25T20:49:49Z<p>Cgdae: /* Building */</p>
<hr />
<div>== Overview ==<br />
<br />
Flightgear on next has support for video encoding of the main window. This requires that ffmpeg/libav libraries are available at build time.<br />
<br />
Videos are generated in the current directory. This can be changed by setting property '''/sim/video/directory'''.<br />
<br />
== Limitations ==<br />
<br />
* As of 2021-12-12, only Unix builds of Flightgear include support for video encoding by default.<br />
** On other platforms, if ffmpeg libraries are installed on the system, Flightgear's cmake might pick them up automatically and enable video encoding, but this hasn't been tested.<br />
* We do not (yet) record sound.<br />
* Prior to 2021-12-19, fixed-dt only worked in [[SimpleTime]] mode (see menu '''File/Time Mode''' and/or property '''/sim/time/simple-time/enabled''').<br />
<br />
== Building ==<br />
<br />
On Unix, we require these libraries and their header files to be available at build time:<br />
<br />
* avcodec<br />
* avuti<br />
* swscale<br />
* avformat<br />
<br />
If these libraries are installed, a standard cmake build should automatically include video encoding support.<br />
<br />
As of 2021-12-27, [[Scripted_Compilation_on_Linux_Debian/Ubuntu|download_and_compile.sh]] installs these libraries automatically.<br />
<br />
On Devuan (and probably other Debian-based distributions), they can be manually installed with:<br />
<br />
sudo apt install libavcodec-dev libavutil-dev libswscale-dev libavformat-dev<br />
<br />
== Creating video of live Flightgear ==<br />
<br />
=== Starting/stopping video encoding ===<br />
<br />
Use menu items '''File/Video Start''' and '''File/Video Stop''' to start/stop video encoding.<br />
<br />
* Videos files are called '''fgvideo-<aircraft>-YYYYMMDD-HHMMSS.<container>''', for example '''fgvideo-harrier-gr3-20211209-234105.mp4'''.<br />
* A convenience link is created that points to the latest video, called '''fgvideo-<aircraft>.<container>''', for example '''fgvideo-harrier-gr3.mp4''' -> '''fgvideo-harrier-gr3-20211209-234105.mp4'''.<br />
* If an error occurs, for example support for video encoding was not included at build time, Flightgear will show a popup warning message.<br />
<br />
=== Video encoding settings ===<br />
[[File:Video-control dialogue.png|thumb]]<br />
Menu '''File/Video Control''' opens a dialogue that allows control over various settings, including:<br />
<br />
* Container name, such as '''mp4''' or '''ogv'''.<br />
** Radio buttons are provided for common containers.<br />
** Run '''ffmpeg -formats''' in a separate terminal to see available containers.<br />
* Codec name, such as '''mpeg2video''', '''libx264''', '''libx265'''.<br />
** Radio buttons are provided for common codecs.<br />
** Run '''ffmpeg -codecs''' in a separate terminal to see available codecs.<br />
* Encoding quality in range '''0..1'''. Use '''-1''' for codec's default.<br />
* Encoding speed in range '''0..1'''. Use '''-1''' for codec's default.<br />
* Encoding target bitrate in bits per second. Use '''0''' for codec's default.<br />
<br />
== Creating video from Flightgear recordings ==<br />
<br />
Flightgear can automatically generate a video when replaying a recording file, stopping video encoding when we reach the end of the recording.<br />
<br />
Usually one would use a Continuous recording for this, as they contain full information regardless of the recording duration.<br />
<br />
* From within Flightgear:<br />
** In the '''Load Flight Recorder Tape''' dialogue, set the '''Auto-create video''' checkbox.<br />
** Optionally also set '''Fixed dt''' (see below).<br />
<br />
* With the command line '''--load-tape''' option:<br />
** Also specify '''--load-tape-create-video'''.<br />
** Optionally specify '''--load-tape-fixed-dt=...''' (see below).<br />
<br />
=== Using '''fixed-dt''' ===<br />
<br />
Setting '''fixed-dt''' to a non-zero value forces Flightgear to increment the FDM time in seconds by the specified amount each frame, instead of by the elapsed real-world time between frames. For example using a value of 0.04 will force a frame rate of 25fps.<br />
<br />
This allows creation of high quality videos from recordings, regardless of the rendering settings or speed of the host, at the expense of potentially taking longer than real time to replay the recording.<br />
<br />
<br />
=== Command line examples ===<br />
<br />
Create a high quality video of a recording by running Flightgear with these command-line args:<br />
<br />
'''--load-tape=... --load-tape-create-video=1 --prop:bool:/sim/time/simple-time/enabled=true --load-tape-fixed-dt=0.04 --graphics-preset=high-quality'''<br />
<br />
Also fix video settings by setting the relevant properties:<br />
<br />
'''--load-tape=... --load-tape-create-video=1 --prop:bool:/sim/time/simple-time/enabled=true --load-tape-fixed-dt=0.04 --graphics-preset=high-quality --prop:/sim/video/container=mp4 --prop:/sim/video/codec=libx265 --prop:/sim/video/quality=0.75 --prop:/sim/video/speed=1'''<br />
<br />
=== Example video ===<br />
<br />
This 5 minute video flying around Manhattan with high rendering settings was created on a fairly slow laptop, taking about an hour to replay and encode: http://op59.net/fgvideo-harrier-gr3-20211206-230342-manhattan.mp4</div>Cgdaehttps://wiki.flightgear.org/w/index.php?title=Video_encoding&diff=134521Video encoding2022-01-25T19:12:54Z<p>Cgdae: /* Limitations */</p>
<hr />
<div>== Overview ==<br />
<br />
Flightgear on next has support for video encoding of the main window. This requires that ffmpeg/libav libraries are available at build time.<br />
<br />
Videos are generated in the current directory. This can be changed by setting property '''/sim/video/directory'''.<br />
<br />
== Limitations ==<br />
<br />
* As of 2021-12-12, only Unix builds of Flightgear include support for video encoding by default.<br />
** On other platforms, if ffmpeg libraries are installed on the system, Flightgear's cmake might pick them up automatically and enable video encoding, but this hasn't been tested.<br />
* We do not (yet) record sound.<br />
* Prior to 2021-12-19, fixed-dt only worked in [[SimpleTime]] mode (see menu '''File/Time Mode''' and/or property '''/sim/time/simple-time/enabled''').<br />
<br />
== Building ==<br />
<br />
On Unix, we require these libraries and their header files to be available at build time:<br />
<br />
* avcodec<br />
* avuti<br />
* swscale<br />
* avformat<br />
<br />
If these libraries are installed, a standard cmake build should automatically include video encoding support.<br />
<br />
As of 2021-12-27, download_and_compile.sh installs these libraries automatically.<br />
<br />
On Devuan (and probably other Debian-based distributions), they can be manually installed with:<br />
<br />
sudo apt install libavcodec-dev libavutil-dev libswscale-dev libavformat-dev<br />
<br />
== Creating video of live Flightgear ==<br />
<br />
=== Starting/stopping video encoding ===<br />
<br />
Use menu items '''File/Video Start''' and '''File/Video Stop''' to start/stop video encoding.<br />
<br />
* Videos files are called '''fgvideo-<aircraft>-YYYYMMDD-HHMMSS.<container>''', for example '''fgvideo-harrier-gr3-20211209-234105.mp4'''.<br />
* A convenience link is created that points to the latest video, called '''fgvideo-<aircraft>.<container>''', for example '''fgvideo-harrier-gr3.mp4''' -> '''fgvideo-harrier-gr3-20211209-234105.mp4'''.<br />
* If an error occurs, for example support for video encoding was not included at build time, Flightgear will show a popup warning message.<br />
<br />
=== Video encoding settings ===<br />
[[File:Video-control dialogue.png|thumb]]<br />
Menu '''File/Video Control''' opens a dialogue that allows control over various settings, including:<br />
<br />
* Container name, such as '''mp4''' or '''ogv'''.<br />
** Radio buttons are provided for common containers.<br />
** Run '''ffmpeg -formats''' in a separate terminal to see available containers.<br />
* Codec name, such as '''mpeg2video''', '''libx264''', '''libx265'''.<br />
** Radio buttons are provided for common codecs.<br />
** Run '''ffmpeg -codecs''' in a separate terminal to see available codecs.<br />
* Encoding quality in range '''0..1'''. Use '''-1''' for codec's default.<br />
* Encoding speed in range '''0..1'''. Use '''-1''' for codec's default.<br />
* Encoding target bitrate in bits per second. Use '''0''' for codec's default.<br />
<br />
== Creating video from Flightgear recordings ==<br />
<br />
Flightgear can automatically generate a video when replaying a recording file, stopping video encoding when we reach the end of the recording.<br />
<br />
Usually one would use a Continuous recording for this, as they contain full information regardless of the recording duration.<br />
<br />
* From within Flightgear:<br />
** In the '''Load Flight Recorder Tape''' dialogue, set the '''Auto-create video''' checkbox.<br />
** Optionally also set '''Fixed dt''' (see below).<br />
<br />
* With the command line '''--load-tape''' option:<br />
** Also specify '''--load-tape-create-video'''.<br />
** Optionally specify '''--load-tape-fixed-dt=...''' (see below).<br />
<br />
=== Using '''fixed-dt''' ===<br />
<br />
Setting '''fixed-dt''' to a non-zero value forces Flightgear to increment the FDM time in seconds by the specified amount each frame, instead of by the elapsed real-world time between frames. For example using a value of 0.04 will force a frame rate of 25fps.<br />
<br />
This allows creation of high quality videos from recordings, regardless of the rendering settings or speed of the host, at the expense of potentially taking longer than real time to replay the recording.<br />
<br />
<br />
=== Command line examples ===<br />
<br />
Create a high quality video of a recording by running Flightgear with these command-line args:<br />
<br />
'''--load-tape=... --load-tape-create-video=1 --prop:bool:/sim/time/simple-time/enabled=true --load-tape-fixed-dt=0.04 --graphics-preset=high-quality'''<br />
<br />
Also fix video settings by setting the relevant properties:<br />
<br />
'''--load-tape=... --load-tape-create-video=1 --prop:bool:/sim/time/simple-time/enabled=true --load-tape-fixed-dt=0.04 --graphics-preset=high-quality --prop:/sim/video/container=mp4 --prop:/sim/video/codec=libx265 --prop:/sim/video/quality=0.75 --prop:/sim/video/speed=1'''<br />
<br />
=== Example video ===<br />
<br />
This 5 minute video flying around Manhattan with high rendering settings was created on a fairly slow laptop, taking about an hour to replay and encode: http://op59.net/fgvideo-harrier-gr3-20211206-230342-manhattan.mp4</div>Cgdae