FlightGear wiki - User contributions [en]

Force feedback

2014-04-06T17:31:19Z

Zan: Added description of current system, and how to use

Development of '''force feedback''' (also called haptic) support for [[FlightGear]] started in December 2011.

==Repository==
The development is currently happening at [http://gitorious.org/fg-haptic/ FG-Haptic on Gitorious]. It is tested on Linux only, as the author (Zan) has no build environment on Windows. Testers wanted!

No built modules yet available. Only source code and nasal/xml scripts. Requires SDL 2.0 to function (might also work with 1.3 or later, but is tested with 2.0).

==Installation and how to use==
===Building===
# You need to have SDL 2.0 development libraries installed
# Edit Makefile for the library paths if necessary
# Type '''make''' and it should build
# Done

===Installation===
# Copy '''ff-protocol.xml''' to '''Protocols/''' in FG data directory.
# Copy '''force-feedback.nas''' to '''Nasal/''' in FG data directory.
# Copy '''force-feedback.xml''' to '''gui/dialogs/''' in FG data directory.

===Using===
# Run '''fg-haptic''' or '''fg-haptic.exe'''
# Launch flightgear with following command line: '''fgfs --telnet=5401 --generic=socket,out,20,localhost,5402,tcp,ff-protocol'''
# If menu bar is not visible, press '''F10'''
# In flightgear's '''Help->Force feedback options''' you can configure force settings
# Enjoy

==Features==
[[File:Fgfs-haptic-settings.png|thumb|270px|The options dialog.]]
===General features===
* In-sim options dialog
* Support for multiple devices simultaneously
* Devices do not need to be the same ones that are used as inputs
* Devices can have different effects applied on them
* Add-on, can be installed on older FlightGear versions too

===Effects===
* Stick shaker when about to stall
* Stick pusher
* Control surface forces ([[JSBSim]] support, no [[YASim]] or others yet, but to be done)
* Pilot G forces

==Technical details==
===System description===
Fg-haptic uses two communication methods with FG; telnet and general protocol. Telnet is used to send force-feedback device info to FG during intialisation, and later on it is used to fetch device configuration. General protocol is used to send force details from FG (one way communication). Telnet is quite slow, update of device configuration may take up to 10 seconds, while general protocol sends data currently 20 times per second.

All properties used by fg-haptic currently reside under '''/haptic/'''. All effects are directly under that (like '''stick-force/''') and each device is below '''/haptic/device[X]/''', showing device info and configuration.

Generic protocol, '''ff-protocol''', uses following format:
<nowiki>reconfigure_request|aileron|elevator|rudder|pilot_x|pilot_y|pilot_z|stick_shaker_trigger|ground_rumble_period</nowiki>

===Force calculations===
Stick forces are based on the following equation, which represents force caused by air flowing towards a surface: 
'''F=0.5*airspeed^2*density*area*Cd''', where Cd is drag coefficient and area is perpendicular to airflow.

Since the surfaces can turn, the effective area is: 
'''effective_area=area*sin(angle)''', where angle is the deflection angle, and it should take angle of attack into account: 
'''angle=deflection_angle-AoA''', since that is the real direction of air flow with relation to the surface. For rudder, we use slip angle instead of AoA.

Also slip may be taken into account, if the air flows from side, it has less effect on the surface, thus giving: 
'''effective_area_2=effective_area*(1-sin(slip_angle))'''.

Another thing we take into account is stall and deep stall. If AoA is over the stall limit, or over deep stall limit, forces acting on elevator and aileron are quickly ramped to zero, representing separated airflow.

In this implementation, multiplication by 0.5, Cd and area are combined to a single coefficient for aileron, elevator and rudder, that are aircraft specific. Coefficients should be set so that the force does not exceed 1.0 (maximum value) in normal operation, and they can also be set to 0 or other value to represent fly-by-wire systems. Also slip coefficients can be defined to fine tune the stick feeling. A good starting value to try for each coefficient is: 
'''coeff=1.0/((Vne^2)*sin(max_deflection)*0.00257)''', where Vne is the maximum (never exceed) speed in knots, max deflection is the maximum deflection of the control surface and 0.00257 is standard air density (slugs/ft3). This value can then be fine tuned.

===Force feedback===
TBD

== External links ==
* [http://gitorious.org/fg-haptic/ Official FG-Haptic repository] (Gitorious)
* [http://sourceforge.net/projects/hapticsforfg/ hapticsforfg] (SourceForge)

[[Category:Hardware]]

Blender and BTG

2012-12-13T18:29:42Z

Zan:

{{Infobox Software
|title = Blender and BTG
|logo =
|image =
|developedby = Lauri Peltonen
|initialrelease =
|latestrelease = Export: 31 Jan 2009 Import: 07 Mar 2011
|writtenin = Python
|os =
|platform =
|developmentstatus =
|type =
|license =
|website =
}}
With the use of a special import&export script, '''[[BTG file format|BTG files]] can be opened in, and exported from [[Blender]]'''. This makes it possible to edit [[FlightGear]]'s terrain and specifically [[airport]]s in a visual editor.

== User documentation ==
=== Installation ===
Download the two scripts:
* [https://docs.google.com/open?id=0B17bx8FT2teqQmtpVGRuNkF6WFE Import script]
* [https://docs.google.com/open?id=0B17bx8FT2teqQmtpVGRuNkF6WFE Export script]

Place both files in your Blender's <tt>.blender/scripts/</tt> directory. Common locations are:
* Windows: <tt>C:/Program Files/Blender Foundation/Blender/.blender/scripts</tt>

Make sure to correct the [[$FG_ROOT]] setting in the import file, if needed. Default setting is:
FG_ROOT = "/usr/local/share/flightgear/"

Scripts should work with Blender 2.4, they are not tested with version 2.6.

=== Usage ===
==== Import ====
Import via <tt>File > Import > Simgear (.btg) v7</tt>.

'''Note:''' rename the <tt>[ICAO].btg.gz</tt> file of an airport, to its corresponding <tt>[tileid].btg.gz</tt>, in order to import it correctly. For importing [[KSFO]], we need to rename <tt>KSFO.btg.gz</tt> to <tt>942050.btg.gz</tt>, for example.

==== Export ====
Export to a file with a .btg.gz extension, via <tt>File > Export > Simgear (.btg)</tt>. Make sure to enter the correct coordinates and radius, as displayed in the console (you can copy&paste from that one) and/or screen on import.

== Known issues ==
* Textures are not applied automatically in Blender, altough they are loaded.
* Imported meshes are shrinked because Blender does/did not support huge enough models (they are loaded correctly, but you cannot zoom out enough to see the whole tile).
* Sometimes exported triangle has its texture coordinates in wrong order which leads to weird looking textures (e.g. on a runway).

[[Category:Modeling]]
[[Category:Scenery enhancement]]

Talk:Blender and BTG

2012-12-13T18:25:38Z

Zan:

== Download links ==
The download links are pointing to nirvana. Can someone update nor upload 'em somewhere else? That'd be genial! --[[User:Kai Burghardt|Kays]] 08:56, 20 October 2012 (EDT)
: Hi Kai,
: I've contacted the author of the scripts. He will re-upload (an updated version of) the scripts next week. ;-) Thanks for notifying!
: [[User:Gijs|Gijs]] 05:21, 22 October 2012 (EDT)
:: Hm, unfortunately in a week is some weeks ago, and the links are still the same. --[[User:Kai Burghardt|Kays]] 18:36, 12 December 2012 (EST)
::: Yo, sorry. I was on vacation when Gijs contacted me and I completely forgot this matter. I have the new versions here: [https://docs.google.com/open?id=0B17bx8FT2teqcVpvZHlhOGlkLUk importer] [https://docs.google.com/open?id=0B17bx8FT2teqQmtpVGRuNkF6WFE exporter]. I hope Gijs can find a better place for those files, maybe upload them to the wiki? Iirc the blender version for these was 2.4, I'm not sure if they work with the latest version, nor have I tested these in a while anyways... [[User:Zan|Zan]] 13:25, 13 December 2012 (EST)

Pixel testing in effects

2012-07-31T20:13:48Z

Zan: Start documenting pixel testing operations possible in effects

== Pixel testing in effect files ==
=== Introduction ===
In opengl, and thus in FlightGear's effect files, one can define several tests for each pixel. The tests are executed for every pixel to-be-rendered on screen, and if all tests pass, the shaders (if defined) are executed and pixel ends up on screen.

=== Test queue ===
{|
|-
| Incoming pixel --> || Alpha test --> || Stencil test --> || Shaders/colouring --> || Color mask --> || Screen
|-
| || V || V || V || ||
|-
| || Discard || Discard || Discard || || ||
|}

In every pass, a pixel can be discarded, and no other tests will be executed. If all tests pass, pixel will be drawn on screen.

==== Alpha test ====
With alpha test you can check if the pixel to be written is transparent or not. It can be used to discard or only draw opaque geometry instead of transparent or vice versa. '''Note! I'm not sure how this works if shader writes to alpha channel!'''

Alpha test can be enabled by specifying <alpha-test> in effect <pass>. Possible attributes are:

* <comparison>
:less: Pass if pixel's alpha is less than <value>
:lequal: Pass if pixel's alpha is less or equal to <value>
:equal: Pass if pixel's alpha is equal to <value>
:gequal: Pass if pixel's alpha is greater or equal to <value>
:greater: Pass if pixel's alpha is greater than <value>
* <value>
:Floating point value against which the pixel's alpha is tested
:'''Is it possible to use properties?'''

==== Stencil test ====
Stencil test can do several things. First, it can discard pixels depending on what is already in the stencil buffer. Second, it can update stencil buffer depending on whether pixel passes z-test or not (i.e. is behind other pixels or not).

{|
|-
| Incoming pixel --> || Stencil test --> (update s-buffer) || Z-test --> (update s-buffer) || Pass --> (update s-buffer)
|-
| || V || V ||
|-
| || Discard (update s-buffer) || Discard (update s-buffer) ||
|}

Stencil test can be enabled by adding <stencil> tags to <pass> in effect.
* <function>: How the stencil-test is done
:never: Pixel is always discarded
:less: Pixel passes if s-buffer contains value less than <value>
:equal: Pixel passes if s-buffer contains value equal to <value>
:less-or-equal: Pixel passes if s-buffer contains value less or equal to <value>
:greater: Pixel passes if s-buffer contains value greater than <value>
:not-equal: Pixel passes if s-buffer contains value not equal to <value>
:greater-or-equal: Pixel passes if s-buffer contains value greater or equal to <value>
:always: Pixel always passes
* <value>
* <stencil-fail>
:keep: Keep the old value currently in s-buffer
:zero: Zero the s-buffer value
:replace: Replace s-buffer value with <value>
:increase: Increase s-buffer value '''with 1 or <value>?'''
:decrease: Decrease s-buffer value '''---"---'''
:increase-wrap: Increase and wrap to zero if overflows
:decrease-wrap: Decrease and wrap to maximum if goes below zero
:invert: Bitwise invert the value in s-buffer
* <z-fail>
* <pass>
* <mask>

==== Color mask ====

Howto talk:Use a Camera View in an Instrument

2012-02-22T17:35:21Z

Zan: /* od_gauge */ new section

== Forum topic about the same subject ==
Omega, did you see http://flightgear.org/forums/viewtopic.php?f=6&t=13798?

Cheers [[User:Gijs|Gijs]] 10:04, 22 February 2012 (EST)

== What is the file name stuff all about? ==
Normally, you'd just render the camera view to a dynamically created texture, then use a visitor to replace the OSG texture with the dynamically created one. The od_gauge instrument would then get instantiated by referencing the new instrument type (such "camera-view") in the XML code. The od_gauge would handle setting up the texture stuff, the update() method would need to update the camera view (based on the view configuration specified in the property tree) and update the texture.--[[User:Hooray|Hooray]] 10:21, 22 February 2012 (EST)

== od_gauge ==

I sent you a message, but I also added a short section about how to use od_gauge in this system. Hope this helps, just ask if you need more info!

[[User:Zan|Zan]] 12:35, 22 February 2012 (EST)

Howto:Use a Camera View in an Instrument

2012-02-22T17:33:46Z

Zan: note about allocRT

=Background=
This was inspired by the ongoing effort to create a realistic 787 for FlightGear, including support for rendering external camera views on instruments: [[Boeing 787-8 Dreamliner#Camera.2FVideo Surveillance Instrument]]. The "Tail Camera" is also a feature found on the [[A380]].

=Objective=

To create a 2D instrument which shows a camera view. Write C++ code, preferably an instrument that renders a Camera View (i.e. from the property tree) to a texture.

The steps involved in creating such an instrument would be:*

* create a new topic branch: [[FlightGear and Git#Local_Branch]]
* Add a new set of cxx/hxx files to $FG_SRC/Instrumentation/ (e.g. camera-texture.cxx and camera-texture.hxx): to get started quickly, just copy and customize the gyro.* files
* implement the SGSubsystem interface for the new subsystem [http://simgear.sourceforge.net/doxygen/classSGSubsystem.html]
* add the new files to the CMake build system: [[Developing using CMake#Adding_new_files_to_the_build]]
* add the new subsystem to the instrument_mgr (FGInstrumentMgr::build method)[http://gitorious.org/fg/flightgear/blobs/next/src/Instrumentation/instrument_mgr.cxx#line127]
* implement the interface for the od_gauge instrument [http://gitorious.org/fg/flightgear/blobs/next/src/Instrumentation/od_gauge.cxx] to dynamically create a texture and display update it as a cockpit instrument
* implement SGPropertyChangeListener to process property tree events and updates [http://simgear.sourceforge.net/doxygen/classSGPropertyChangeListener.html]
* Render a property-driven camera view to the created texture (Zan has already code doing this sort of thing [http://flightgear.org/forums/viewtopic.php?f=6&t=13798])
* Write an XML 2D Instrument file that displays the texture

There are obviously more steps involved here, some of which covered here [[Howto: Create a 2D drawing API for FlightGear]].

=Pre-Requisites=

The following are required before we continue...
* To be able to build FlightGear from Source (with or without an IDE)
* To be able to create new instruments (that would be taking a simple one like gyro, copying it's files and changing the content)
* A Gitorious account to be able to clone the Flightgear Repository
* Basic Knowledge of FlightGear and XML

=Part 1: Rendering a Camera View to Texture=

There're probably many ways to do that, you could do it the way the ground radar instrument does, or how you take a screenshot etc. A very nice guide on OpenSceneGraph Rendering is available at http://www.palomino3d.com/pal_com/openscenegraph/ or http://sourceforge.net/apps/mediawiki/delta3d/index.php?title=Tutorial_Render_To_Texture

==Screenshot Method==

This is a very simple method and is used normally for taking screen-shots.

'''OpenSceneGraph C++ Code:'''

<syntaxhighlight lang="cpp">
osg::Image* shot = new osg::Image();
shot->allocateImage(width, height, 24, GL_RGB, GL_UNSIGNED_BYTE);
camera->attach(osg::Camera::COLOR_BUFFER, shot);
osgDB::writeImageFile(*shot,"image_file.png");
</syntaxhighlight>

==FlightGear code==
FlighGear already has an "Owner Drawn instrument" in flightgear/src/Instrumentation/od_gauge.cxx and .hxx. It already sets up a pre-render camera and a texture for it, and has a visitor to replace model's texture with the custom texture.

Using it would be something like this:

* Create a custom instrument which inherits od_gauge. class CameraInstrument : public FGODGauge { ... }
* Implement the init and update functions, whatever instrument manager requires.
* In init set up proper texture sizes and call allocRT().
* NOTE: od_gauge does NOT add camera to render the scenery, but a custom model. One needs to modify od_gauge so that allocRT calls globals()->get_renderer()->addCamera(camera.get(), '''true''');
* In update function update camera position according to viewer->getAbsolutePosition(...).
* Add the custom instrument to instrument_mgr.cxx.

=Part 2: Getting that texture into an instrument=

This part doesn't require any C++ coding, just a simple XML script to use that texture in an instrument.

<syntaxhighlight lang="xml">
<?xml version="1.0"?>

<PropertyList>
<name>Camera Instrument</name>
<w-base>512</w-base>
<h-base>512</h-base>

<layers>
<layer>
<name>camera</name>
<texture>
<path>image_file.png</path> 
<x1>0</x1>
<y1>0</y1>
<x2>1</x2>
<y2>1</y2>
</texture>
<emissive>1</emissive>
<w>512</w>
<h>512</h>
</layer>
</layers>

</syntaxhighlight>

''You could create more layers for more cameras/different views or even have a sprite or something on the view. Or we could also add transformations or conditions to the layer to give some function to the instrument other than just show a camera view.''

<syntaxhighlight lang="xml">
<transformation>
<type>y-shift</type>
<property>/instrumentation/camera/y_shift</property>
<scale>2</scale>
</transformation>
</syntaxhighlight>

=Creating the CamView as a hard coded instrument=

==Header File: cam_display.hxx==

The header file is used to simply initialize a new class that contains all functions related to this instrument. The Functions are just constructed here, the contents are put in the ''cam_display.cxx'' file.

<syntaxhighlight lang="cpp">
// cam_display.hxx - simple function to render view to texture

#ifndef __INSTRUMENTATION_CAMVIEW_HXX
#define __INSTRUMENTATION_CAMVIEW_HXX

#include <simgear/props/props.hxx>
#include "od_gauge.hxx"

class CamView : public SGPropertyChangeListener, public FGODGauge
{
public:
static const int TextureHalfSize = 256;
CamView(SGPropertyNode* node);
virtual ~CamView();
void updateTexture();
virtual void valueChanged(SGPropertyNode*);

protected:
void createTexture(const char* texture_name);

};

#endif // __INSTRUMENTATION_CAMVIEW_HXX
</syntaxhighlight>

= Related =
* [http://flightgear.org/forums/viewtopic.php?f=6&t=13798 Zan's work on improved camera config options]

[[Category:GSoC]]

Howto:Use a Camera View in an Instrument

2012-02-22T17:29:38Z

Zan: Correct list formatting

=Background=
This was inspired by the ongoing effort to create a realistic 787 for FlightGear, including support for rendering external camera views on instruments: [[Boeing 787-8 Dreamliner#Camera.2FVideo Surveillance Instrument]]. The "Tail Camera" is also a feature found on the [[A380]].

=Objective=

To create a 2D instrument which shows a camera view. Write C++ code, preferably an instrument that renders a Camera View (i.e. from the property tree) to a texture.

The steps involved in creating such an instrument would be:*

* create a new topic branch: [[FlightGear and Git#Local_Branch]]
* Add a new set of cxx/hxx files to $FG_SRC/Instrumentation/ (e.g. camera-texture.cxx and camera-texture.hxx): to get started quickly, just copy and customize the gyro.* files
* implement the SGSubsystem interface for the new subsystem [http://simgear.sourceforge.net/doxygen/classSGSubsystem.html]
* add the new files to the CMake build system: [[Developing using CMake#Adding_new_files_to_the_build]]
* add the new subsystem to the instrument_mgr (FGInstrumentMgr::build method)[http://gitorious.org/fg/flightgear/blobs/next/src/Instrumentation/instrument_mgr.cxx#line127]
* implement the interface for the od_gauge instrument [http://gitorious.org/fg/flightgear/blobs/next/src/Instrumentation/od_gauge.cxx] to dynamically create a texture and display update it as a cockpit instrument
* implement SGPropertyChangeListener to process property tree events and updates [http://simgear.sourceforge.net/doxygen/classSGPropertyChangeListener.html]
* Render a property-driven camera view to the created texture (Zan has already code doing this sort of thing [http://flightgear.org/forums/viewtopic.php?f=6&t=13798])
* Write an XML 2D Instrument file that displays the texture

There are obviously more steps involved here, some of which covered here [[Howto: Create a 2D drawing API for FlightGear]].

=Pre-Requisites=

The following are required before we continue...
* To be able to build FlightGear from Source (with or without an IDE)
* To be able to create new instruments (that would be taking a simple one like gyro, copying it's files and changing the content)
* A Gitorious account to be able to clone the Flightgear Repository
* Basic Knowledge of FlightGear and XML

=Part 1: Rendering a Camera View to Texture=

There're probably many ways to do that, you could do it the way the ground radar instrument does, or how you take a screenshot etc. A very nice guide on OpenSceneGraph Rendering is available at http://www.palomino3d.com/pal_com/openscenegraph/ or http://sourceforge.net/apps/mediawiki/delta3d/index.php?title=Tutorial_Render_To_Texture

==Screenshot Method==

This is a very simple method and is used normally for taking screen-shots.

'''OpenSceneGraph C++ Code:'''

<syntaxhighlight lang="cpp">
osg::Image* shot = new osg::Image();
shot->allocateImage(width, height, 24, GL_RGB, GL_UNSIGNED_BYTE);
camera->attach(osg::Camera::COLOR_BUFFER, shot);
osgDB::writeImageFile(*shot,"image_file.png");
</syntaxhighlight>

==FlightGear code==
FlighGear already has an "Owner Drawn instrument" in flightgear/src/Instrumentation/od_gauge.cxx and .hxx. It already sets up a pre-render camera and a texture for it, and has a visitor to replace model's texture with the custom texture.

Using it would be something like this:

* Create a custom instrument which inherits od_gauge. class CameraInstrument : public FGODGauge { ... }
* Implement the init and update functions, whatever instrument manager requires.
* In init set up proper texture sizes and call allocRT().
* In update function update camera position according to viewer->getAbsolutePosition(...).
* Add the custom instrument to instrument_mgr.cxx.

=Part 2: Getting that texture into an instrument=

This part doesn't require any C++ coding, just a simple XML script to use that texture in an instrument.

<syntaxhighlight lang="xml">
<?xml version="1.0"?>

<PropertyList>
<name>Camera Instrument</name>
<w-base>512</w-base>
<h-base>512</h-base>

<layers>
<layer>
<name>camera</name>
<texture>
<path>image_file.png</path> 
<x1>0</x1>
<y1>0</y1>
<x2>1</x2>
<y2>1</y2>
</texture>
<emissive>1</emissive>
<w>512</w>
<h>512</h>
</layer>
</layers>

</syntaxhighlight>

''You could create more layers for more cameras/different views or even have a sprite or something on the view. Or we could also add transformations or conditions to the layer to give some function to the instrument other than just show a camera view.''

<syntaxhighlight lang="xml">
<transformation>
<type>y-shift</type>
<property>/instrumentation/camera/y_shift</property>
<scale>2</scale>
</transformation>
</syntaxhighlight>

=Creating the CamView as a hard coded instrument=

==Header File: cam_display.hxx==

The header file is used to simply initialize a new class that contains all functions related to this instrument. The Functions are just constructed here, the contents are put in the ''cam_display.cxx'' file.

<syntaxhighlight lang="cpp">
// cam_display.hxx - simple function to render view to texture

#ifndef __INSTRUMENTATION_CAMVIEW_HXX
#define __INSTRUMENTATION_CAMVIEW_HXX

#include <simgear/props/props.hxx>
#include "od_gauge.hxx"

class CamView : public SGPropertyChangeListener, public FGODGauge
{
public:
static const int TextureHalfSize = 256;
CamView(SGPropertyNode* node);
virtual ~CamView();
void updateTexture();
virtual void valueChanged(SGPropertyNode*);

protected:
void createTexture(const char* texture_name);

};

#endif // __INSTRUMENTATION_CAMVIEW_HXX
</syntaxhighlight>

= Related =
* [http://flightgear.org/forums/viewtopic.php?f=6&t=13798 Zan's work on improved camera config options]

[[Category:GSoC]]

Howto:Use a Camera View in an Instrument

2012-02-22T17:27:58Z

Zan: Short introduction to od_gauge

=Background=
This was inspired by the ongoing effort to create a realistic 787 for FlightGear, including support for rendering external camera views on instruments: [[Boeing 787-8 Dreamliner#Camera.2FVideo Surveillance Instrument]]. The "Tail Camera" is also a feature found on the [[A380]].

=Objective=

To create a 2D instrument which shows a camera view. Write C++ code, preferably an instrument that renders a Camera View (i.e. from the property tree) to a texture.

The steps involved in creating such an instrument would be:*

* create a new topic branch: [[FlightGear and Git#Local_Branch]]
* Add a new set of cxx/hxx files to $FG_SRC/Instrumentation/ (e.g. camera-texture.cxx and camera-texture.hxx): to get started quickly, just copy and customize the gyro.* files
* implement the SGSubsystem interface for the new subsystem [http://simgear.sourceforge.net/doxygen/classSGSubsystem.html]
* add the new files to the CMake build system: [[Developing using CMake#Adding_new_files_to_the_build]]
* add the new subsystem to the instrument_mgr (FGInstrumentMgr::build method)[http://gitorious.org/fg/flightgear/blobs/next/src/Instrumentation/instrument_mgr.cxx#line127]
* implement the interface for the od_gauge instrument [http://gitorious.org/fg/flightgear/blobs/next/src/Instrumentation/od_gauge.cxx] to dynamically create a texture and display update it as a cockpit instrument
* implement SGPropertyChangeListener to process property tree events and updates [http://simgear.sourceforge.net/doxygen/classSGPropertyChangeListener.html]
* Render a property-driven camera view to the created texture (Zan has already code doing this sort of thing [http://flightgear.org/forums/viewtopic.php?f=6&t=13798])
* Write an XML 2D Instrument file that displays the texture

There are obviously more steps involved here, some of which covered here [[Howto: Create a 2D drawing API for FlightGear]].

=Pre-Requisites=

The following are required before we continue...
* To be able to build FlightGear from Source (with or without an IDE)
* To be able to create new instruments (that would be taking a simple one like gyro, copying it's files and changing the content)
* A Gitorious account to be able to clone the Flightgear Repository
* Basic Knowledge of FlightGear and XML

=Part 1: Rendering a Camera View to Texture=

There're probably many ways to do that, you could do it the way the ground radar instrument does, or how you take a screenshot etc. A very nice guide on OpenSceneGraph Rendering is available at http://www.palomino3d.com/pal_com/openscenegraph/ or http://sourceforge.net/apps/mediawiki/delta3d/index.php?title=Tutorial_Render_To_Texture

==Screenshot Method==

This is a very simple method and is used normally for taking screen-shots.

'''OpenSceneGraph C++ Code:'''

<syntaxhighlight lang="cpp">
osg::Image* shot = new osg::Image();
shot->allocateImage(width, height, 24, GL_RGB, GL_UNSIGNED_BYTE);
camera->attach(osg::Camera::COLOR_BUFFER, shot);
osgDB::writeImageFile(*shot,"image_file.png");
</syntaxhighlight>

==FlightGear code==
FlighGear already has an "Owner Drawn instrument" in flightgear/src/Instrumentation/od_gauge.cxx and .hxx. It already sets up a pre-render camera and a texture for it, and has a visitor to replace model's texture with the custom texture.

Using it would be something like this:
- Create a custom instrument which inherits od_gauge. class CameraInstrument : public FGODGauge { ... }
- Implement the init and update functions, whatever instrument manager requires.
- In init set up proper texture sizes and call allocRT().
- In update function update camera position according to viewer->getAbsolutePosition(...).
- Add the custom instrument to instrument_mgr.cxx.

=Part 2: Getting that texture into an instrument=

This part doesn't require any C++ coding, just a simple XML script to use that texture in an instrument.

<syntaxhighlight lang="xml">
<?xml version="1.0"?>

<PropertyList>
<name>Camera Instrument</name>
<w-base>512</w-base>
<h-base>512</h-base>

<layers>
<layer>
<name>camera</name>
<texture>
<path>image_file.png</path> 
<x1>0</x1>
<y1>0</y1>
<x2>1</x2>
<y2>1</y2>
</texture>
<emissive>1</emissive>
<w>512</w>
<h>512</h>
</layer>
</layers>

</syntaxhighlight>

''You could create more layers for more cameras/different views or even have a sprite or something on the view. Or we could also add transformations or conditions to the layer to give some function to the instrument other than just show a camera view.''

<syntaxhighlight lang="xml">
<transformation>
<type>y-shift</type>
<property>/instrumentation/camera/y_shift</property>
<scale>2</scale>
</transformation>
</syntaxhighlight>

=Creating the CamView as a hard coded instrument=

==Header File: cam_display.hxx==

The header file is used to simply initialize a new class that contains all functions related to this instrument. The Functions are just constructed here, the contents are put in the ''cam_display.cxx'' file.

<syntaxhighlight lang="cpp">
// cam_display.hxx - simple function to render view to texture

#ifndef __INSTRUMENTATION_CAMVIEW_HXX
#define __INSTRUMENTATION_CAMVIEW_HXX

#include <simgear/props/props.hxx>
#include "od_gauge.hxx"

class CamView : public SGPropertyChangeListener, public FGODGauge
{
public:
static const int TextureHalfSize = 256;
CamView(SGPropertyNode* node);
virtual ~CamView();
void updateTexture();
virtual void valueChanged(SGPropertyNode*);

protected:
void createTexture(const char* texture_name);

};

#endif // __INSTRUMENTATION_CAMVIEW_HXX
</syntaxhighlight>

= Related =
* [http://flightgear.org/forums/viewtopic.php?f=6&t=13798 Zan's work on improved camera config options]

[[Category:GSoC]]

Talk:Project Rembrandt

2012-01-15T20:58:02Z

Zan:

Hi.

Like I mentioned in my email, I have made modifications to CameraGroup to allow much more camera options in preferences.xml. Currently supporting: multiple cameras & render orders, render to texture, multiple render targets, binding of render target textures for other cameras, floating point textures, post processing & chaining of effects.

So basically I think most your stuff could be handled with this system (though it still has some bugs and seems to cause crashes in libGL...)

Anyways, when you think you have the system running well enough, so that it would be time for cleanup, please give me a message and let's see if this work can be combined. Meanwhile, if you're interested, my git repo is at [https://gitorious.org/~zan/fg/zans-flightgear/commits/newcameras gitorious repository].

What I wonder about your work, is how you handle the separation of geometry, i.e. that the geometry pass does not draw transparent objects like clouds? I was trying to add this to my system, and got it to sort of work (via pre-render callbacks) but it was ugly. I'm going to add an option in preferences.xml to select, which geometry (either render bin numbers or transparent/opaque etc) to render, which would allow multiple lights easily.

[[User:Zan|Zan]] 04:36, 20 December 2011 (EST)
:: Also see [http://flightgear.org/forums/viewtopic.php?f=6&t=13798&p=140379&hilit=#p140299 here] (forum thread).--[[User:Hooray|Hooray]] 07:13, 20 December 2011 (EST)

The cloud and the sky were removed from the main scenegraph (in renderer.cxx) and added as simple group nodes in the lighting camera (the stage before the display stage) before applying the ambient pass. I put banners in CameraGroup so it is easy to spot the different structures for each stage (CameraGroup::BuildGBufferCamera - a bit misnamed now).

Also don't forget most of state attributes are set in terrain-default.eff and model-default.eff

--[[User:Fredb|Fredb]] 16:01, 20 December 2011 (EST)

You write about the transparent objects: ''In a cull callback attached to the Geometry camera, after the scenegraph traversal, the transparent bins are removed from the render stage and saved in a temporary collection.'' I have to tell you, when I made my modifications to the cameras, I was also thinking about deferred shader, and ended up with the exactly same method what you seem to be using! I just never found time to correctly implement it. I'm impressed that we both separately ended up with this same method!
[[User:Zan|Zan]] 15:58, 15 January 2012 (EST)

== Models modification log ==
{{cquote|Change KSFO_light.xml to apt-light.xml|Fredb}}
Why that? KSFO_light.xml is a special model, made for KSFO by Don Lavelle. Just like EHAM also has custom light poles. And EDDF. There are quite some actually...

[[User:Gijs|Gijs]] 15:04, 3 January 2012 (EST)

: Hi Gijs. Could you explain in what they are different and why there are only ten of then while there are more than 50 apt-light in KSFO ?
:--[[User:Fredb|Fredb]] 15:30, 3 January 2012 (EST)

:: They are two completely different models. Just compare them in Blender (or whatever editor). The KSFO_light ones match better with the real ones at KSFO (one of the differences is that the KSFO ones are grey/brown, rather than red/white striped). I don't know why only a few are placed, the red/white ones should be replaced (will talk to Jon on IRC in a minute).
:: Now that you're working on spot lights, it's important to realize that we (will) have many light pole models, simply because there are many variants in real life... ;)
:: [[User:Gijs|Gijs]] 17:42, 3 January 2012 (EST)

Because of this: "Add a spot light animation" - testing real lights now?
That would be great!

--[[User:HHS|HHS]] 15:09, 3 January 2012 (EST)

Force feedback

2011-12-25T16:03:41Z

Zan: third person

Force feedback

2011-12-25T11:38:33Z

Zan: Created page with "=Force feedback= As of december 2011 I started developing force feedback (also called haptic) support for Flightgear. ==Repository== The development is currently happening here:..."

=Force feedback=
As of december 2011 I started developing force feedback (also called haptic) support for Flightgear.

==Repository==
The development is currently happening here: [http://gitorious.org/fg-haptic/ FG-Haptic] . It is tested on Linux only, as I have no build environment on Windows. Testers wanted!

No built modules yet available. Only source code and nasal/xml scripts. Requires SDL 1.3 to function.

==Features==
===General features===
* In-sim options dialog
* Support for multiple devices simultaneously (currently 4)
* Devices do not need to be the same ones that are used as inputs
* Devices can have different effects applied on them
* Add-on, can be installed on older FG versions too

===Effects===
* Stick shaker when about to stall
* TODO: Stick pusher
* Control surface forces (JSBSim preliminary support, no YASim or others yet)
* Pilot G forces

==Technical details==
Pilot G forces and control surface forces are currently handled as constant force effects, and updated 10 times a second. Sometimes they feel a bit shaky, so they might need some tuning...

Stick shaker is a simple rumble effect.

==Screenshot==
[http://users.tkk.fi/~lapelto2/fgfs/fgfs-haptic-settings.png I don't know yet how to add this as an image...]

==TODO==
* Test using spring condition for control surface force loading. This requires some magic to figure out the maximum forces and ramp speeds, as we cannot use the forces calculated by FDM directly. This way the force would be much smoother than with constant force

Talk:Project Rembrandt

2011-12-20T09:36:40Z

Zan: Created page with "Hi. Like I mentioned in my email, I have made modifications to CameraGroup to allow much more camera options in preferences.xml. Currently supporting: multiple cameras & render ..."

Coordinate systems

2011-10-10T09:40:19Z

Zan: Added light sources and forest

==Introduction==
This page describes the various reference frames for coordinates used in flightgear. This is mostly targeted at shader development, for cartesian/geodetic etc. systems, we have other pages.

==Disclaimer==
I wrote these from my memory, if you notice some is wrong, please fix it! :)

==Coordinates in shader programs==
===Vertex program===
Vertex program handles every vertex of a model. It is executed for every vertex only, and can use attributes like vertex position, color, normal etc. Vertex program's purpose is to transform vertices to screen space (i.e. calculate their position on the display).

gl_Vertex has the vertex in object's reference frame.
After multiplying by gl_ModelViewMatrix, we get the vertex coordinate with relation to camera (eye point). We call this later on the eye frame.
Further multiplying this with gl_ProjectionMatrix (or with the combined gl_ModelViewProjectionMatrix) we get a screen space coordinate. We call this later screen or view frame.

===Fragment program===
Fragment program handles all pixels that are on the screen. It cannot change pixel's position, but only calculate its color and transparency. It gets parameters from a vertex shader, and interpolates between the values at those points.

You can access the screen coordinate with gl_FragCoord and gl_FragDepth.

===Light sources===
FlightGear uses gl_LightSource[0] to represent the sun.

In GLSL (fixed function i.e. not using uniforms or similar to pass the coordinates), light sources are defined in '''eye space'''. It means, that to take e.g. dot product of the light source's and normal's direction, you need to use dot('''gl_NormalMatrix*gl_Normal''', gl_LightSource[0].position).

==Coordinate reference frames==
===Terrain===
Terrain is referenced with origo (0,0,0) being at the center of the tile, lying on the mean sea level.
Reference frame is z = up, x and y are in lat and lon directions.

Every tile's frame is in relation to that tile, so the z is always up on that tile's center point.

===Objects===
Objects depend a bit on the modeller, but usually origo is at the bottom of the building, in the center.
Z is up, x and y most likely are lat and lon, since usually people use some reference images underneath. But not always, x and y might be to any direction depending on the modeller.

===Clouds===
Clouds/cloudlets have origo at the center of the cloud. gl_Color has the center of each cloudlet with relation to origo.
Z is up, x and y are lat/lon direction.

Cloud layer used to be flat, so that z is same way on all clouds, but I think this got fixed and now the layers are curved. I don't know if z is relative to that position or not.

===Skydome===
Skydome is always centered on the camera, so that origo is under the view, at mean sea level.
Z is up, x and y are rotated so that x (or y...) axis points towards the sun. That way the sunset effects are easier to do.

===Forests===
Forests are rendered with a block of trees in one draw. Origo is somewhere in the center of that block. Also, iirc a vertex attribute defines the tree's location on the terrain, so gl_Vertex is center of the forest, and that attribute must be added to it to find the correct position.
Z is up, x and y are probably lat/lon? Might also be in any direction, depending on how the block is rotated to be Z upwards.

[[Category:Shader development]]

Coordinate systems

2011-10-02T10:53:09Z

Zan:

==Introduction==
This page describes the various reference frames for coordinates used in flightgear. This is mostly targeted at shader development, for cartesian/geodetic etc. systems, we have other pages.

==Disclaimer==
I wrote these from my memory, if you notice some is wrong, please fix it! :)

==Coordinates in shader programs==
===Vertex program===
Vertex program handles every vertex of a model. It is executed for every vertex only, and can use attributes like vertex position, color, normal etc. Vertex program's purpose is to transform vertices to screen space (i.e. calculate their position on the display).

gl_Vertex has the vertex in object's reference frame.
After multiplying by gl_ModelViewMatrix, we get the vertex coordinate with relation to camera (eye point). We call this later on the eye frame.
Further multiplying this with gl_ProjectionMatrix (or with the combined gl_ModelViewProjectionMatrix) we get a screen space coordinate. We call this later screen or view frame.

===Fragment program===
Fragment program handles all pixels that are on the screen. It cannot change pixel's position, but only calculate its color and transparency. It gets parameters from a vertex shader, and interpolates between the values at those points.

You can access the screen coordinate with gl_FragCoord and gl_FragDepth.

==Coordinate reference frames==
===Terrain===
Terrain is referenced with origo (0,0,0) being at the center of the tile, lying on the mean sea level.
Reference frame is z = up, x and y are in lat and lon directions.

Every tile's frame is in relation to that tile, so the z is always up on that tile's center point.

===Objects===
Objects depend a bit on the modeller, but usually origo is at the bottom of the building, in the center.
Z is up, x and y most likely are lat and lon, since usually people use some reference images underneath. But not always, x and y might be to any direction depending on the modeller.

===Clouds===
Clouds/cloudlets have origo at the center of the cloud. gl_Color has the center of each cloudlet with relation to origo.
Z is up, x and y are lat/lon direction.

Cloud layer used to be flat, so that z is same way on all clouds, but I think this got fixed and now the layers are curved. I don't know if z is relative to that position or not.

===Skydome===
Skydome is always centered on the camera, so that origo is under the view, at mean sea level.
Z is up, x and y are rotated so that x (or y...) axis points towards the sun. That way the sunset effects are easier to do.

Coordinate systems

2011-10-02T10:04:32Z

Zan:

==Introduction==
This page describes the various reference frames for coordinates used in flightgear. This is mostly targeted at shader development, for cartesian/geodetic etc. systems, we have other pages.

==Coordinates in shader programs==
===Vertex program===
Vertex program handles every vertex of a model. It is executed for every vertex only, and can use attributes like vertex position, color, normal etc. Vertex program's purpose is to transform vertices to screen space (i.e. calculate their position on the display).

gl_Vertex has the vertex in object's reference frame.
After multiplying by gl_ModelViewMatrix, we get the vertex coordinate with relation to camera (eye point). We call this later on the eye frame.
Further multiplying this with gl_ProjectionMatrix (or with the combined gl_ModelViewProjectionMatrix) we get a screen space coordinate. We call this later screen or view frame.

===Fragment program===
Fragment program handles all pixels that are on the screen. It cannot change pixel's position, but only calculate its color and transparency. It gets parameters from a vertex shader, and interpolates between the values at those points.

You can access the screen coordinate with gl_FragCoord and gl_FragDepth.

==Coordinate reference frames==
===Terrain===
Terrain is referenced with origo (0,0,0) being at the center of the tile, lying on the mean sea level.
Reference frame is z = up, x and y are in lat and lon directions.

===Clouds===
Clouds/cloudlets have origo at the center of the cloud. gl_Color has the center of each cloudlet with relation to origo.

Coordinate systems

2011-10-02T10:00:33Z

Zan: Created page with "==Introduction== This page describes the various reference frames for coordinates used in flightgear. This is mostly targeted at shader development, for cartesian/geodetic etc. s..."

==Introduction==
This page describes the various reference frames for coordinates used in flightgear. This is mostly targeted at shader development, for cartesian/geodetic etc. systems, we have other pages.

==Coordinates in shader programs==
===Vertex program===
Vertex program handles every vertex of a model. It is executed for every vertex only, and can use attributes like vertex position, color, normal etc. Vertex program's purpose is to transform vertices to screen space (i.e. calculate their position on the display).

gl_Vertex has the vertex in object's reference frame.
After multiplying by gl_ModelViewMatrix, we get the vertex coordinate with relation to camera (eye point). We call this later on the eye frame.
Further multiplying this with gl_ProjectionMatrix (or with the combined gl_ModelViewProjectionMatrix) we get a screen space coordinate. We call this later screen or view frame.

===Fragment program===
Fragment program handles all pixels that are on the screen. It cannot change pixel's position, but only calculate its color and transparency. It gets parameters from a vertex shader, and interpolates between the values at those points.

You can access the screen coordinate with gl_FragCoord and/or gl_FragDepth.

Blender and BTG

2011-05-04T14:42:49Z

Zan: Link to newer version of the import script

With the use of a special import&export script, '''[[BTG file format|BTG files]] can be opened in and exported from [[Blender]]'''. This makes it possible to edit [[FlightGear]]'s terrain and specifically [[airport]]s in a visual editor.

== User documentation ==
=== Installation ===
Download the two scripts:
* [http://users.tkk.fi/~lapelto2/fgfs/import_btg_v7.py Import script]
* [http://users.tkk.fi/~lapelto2/fgfs/export_btg.py Export script]

Place both files in your Blender's <tt>.blender/scripts/</tt> directory. Common locations are:
* Windows: <tt>C:/Program Files/Blender Foundation/Blender/.blender/scripts</tt>

=== Usage ===
==== Import ====
Import via <tt>File > Import > Simgear (.btg)</tt>.

==== Export ====
# Export to a file without extension, via <tt>File > Export > Simgear (.btg)</tt>. Make sure to enter the correct coordinates and radius, as displayed in the console and screen on import.
# Package/zip the created file to a .btg.gz file. This one can be loaded into FlightGear.

== Known issues ==
* Textures are not applied automatically in Blender.
* No textures at all on terrain import. Terrain is imported as one big mesh, despite various materials.
* Terrain is not lined up with the axis, making it hard to edit correctly.
* Airport lights are not imported.
* Imported meshes are shrinked.

[[Category:Modeling]]
[[Category:Scenery enhancement]]

FlightGear Newsletter April 2011

2011-04-20T20:47:05Z

Zan: /* Atmospheric scattering shader */

{{newsletter}}
{{TOC_right|limit=2}}

''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

== Development news ==
=== Atmospheric scattering shader ===
Zan has been working very hard on an experimental atmospheric scattering [[shader]]. The shaders makes use of [http://sponeil.net/ Sean O'Neil's algorithm]. Altough there are some issues with the shader, it looks like it will have a promising future! Some screenshots are available at the forum thread [http://www.flightgear.org/forums/viewtopic.php?f=47&t=11274#p117813].

The shader does some simplifications, but basically tries to recreate physical phenomenom, so the look could be easily modified depending on environmental conditions. But since the values are not so easy to figure out, some testing would be needed for creating nice looking sky for misty weather, rainy weather, cold winter etc. After that, proper equations could be written to transform weather values to scattering parameters.

The shader is not production ready, it has some bugs and terrain (especially fog at horizon) does not match the looks of the skydome. This is a work in process, but might take some times, because the terrain shader is much harder than the skydome shader.

== Nasal for newbies ==
== New software tools and projects ==

== FlightGear addons and mods ==
== In the hangar ==
=== New instruments ===
The [[Boeing 777-200ER]]'s chronometer has been moved to the generic instruments directory (<tt>Aircraft/Instruments-3d/chronometer</tt>). This allows aircraft developers to easily implement this clock in their aircraft. All related Nasal code was included in the model xml file, so there's really just one file to be linked to! Some aircraft already make use of this clock, including the [[Boeing 747-400]] and [[Boeing 757-200|757-200]].

There are several advantages in moving instruments to the generic directory, some of which are:
* Easy to be re-used in other aircraft, all you need to do is link to (and position) the model and on some instruments link to a Nasal file.
* If someone extents the functionality of a generic instrument, it will be automatically extended in all the aircraft that use it.

=== New aircraft ===
=== Vostok-1 ===
[[Image:Vostok-1-Carrier-News.png|thumb|Vostok-1 Carrier]]
[[Image:Vostok-1-News.png|thumb|Vostok-1 Spacecraft]]
[[Image:Vostok-1-Interior-News.png|thumb|Vostok-1 Interior]]
To celebrate Yury Gagarin's historical flight, [[Vostok-1]] carrier and spacecraft were added to FlightGear. In heavy development still, it already allows full orbital flight from lift-off to landing, making it perform the first spaceflight in FlightGear.

Things that make it possible:
*[[JSBSim]] centrifugal force addition made the whole flight available.
*JSBSim property driven point masses, tanks and engines, and aerodynamic coefficients implementation allow stages changing. Each single stage of the flight has an independent mass scheme, propulsion system, and aerodynamics reactions, so simulation is more or less realistic.
*Datcom+ with "little wing" approach resolves carrier and spacecraft aerodynamics accurately enough to make flights on real fuel and oxidizer capacities with real g forces, orbit and deorbit paths.
*[[FlightGear Newsletter April 2011#Atmospheric scattering shader|Zan's shader]] makes the earth look pretty enough from high altitudes.
*FG improvement shifted practical flight ceiling from 80 to 160 kilometers.

In real life, the first human spaceflight was fully automated. In FlightGear, instead controls are completely manual to make it interesting, and to make you understand how it really works.

Authors and developers, since orbital flight is possible in FlightGear from now on, you are invited to make a FlightGear driven Mercury-Atlas project. Low earth orbit flights can be more exact and eyecandy in FlightGear than in any current simulator. And you can be sure it will be free for you and users in any case.

=== Doctor Who TARDIS ===
[[Image:Tardis colour.png|thumb|Doctor Who TARDIS]]
Vinura has started work on developing a [http://en.wikipedia.org/wiki/TARDIS#The_Doctor.27s_TARDIS Doctor Who TARDIS] for FlightGear. The exterior model is almost complete in SketchUp. Click [http://www.flightgear.org/forums/viewtopic.php?f=4&t=11738 here] for the development thread.

Currently, I still need to get the TARDIS colours right as I am only allowed to use 'Named Colours' from Google SketchUp as they can't claim copyright on colours.

=== Updated aircraft ===

=== Liveries ===
[[Image:Fgfs-screen-089.png|thumb|SriLankan Airlines' Boeing 767]]
Some [http://liveries.flightgear.org/airlines.php?id=231 SriLankan Airlines] liveries have been made by Vinura for the [[Boeing 767]] and [[Airbus A320]].

== Scenery corner ==

=== New terrain ===
New third-party scenery for the USA's Pacific Northwest (Seattle and Portland, OR) and Rio de Janeiro is now available for download at http://www.stattosoftware.com/flightgear

=== New buildings ===
Once again, there are new Eastern Asian buildings !

* Saigon Center - Ho Chi Minh City - Vietnam
* Mode Gakuen Coccoon Tower - Tokyo - Japan
* Trade Tower - Seoul - South Korea
* Koryo Hotel - Pyongyang - North Korea
* The Center - Hong Kong - China
* Central Plaza - Hong Kong - China

=== Airports ===
The generic Concourse C at KDEN was recently replaced with a much better, realistic working model featuring animated jetways. Please enjoy.

== Aircraft of the month ==
== Airport of the month ==
== Screenshot of the month ==
SriLankan Airlines livery on an Airbus A320 taken at dusk.

[[File:Fgfs-screen-085.png|600px]]

== Suggested flights ==
Departing from Brisbane International Airport and heading towards Sydney International Airport at a heading of about 203, you will come across some beautiful scenery.
<gallery>
Image:Fgfs-screen-020.png
Image:Fgfs-screen-016.png
Image:Fgfs-screen-012.png
</gallery>

== Aircraft reviews ==

=== '''''The Good old Cessna Citation X''''' ===
I hope to do a monthly review of a specific aircraft. I can't guarantee that I will get to do it every month though because I do have other stuff to attend to.

The [[Cessna Citation X]] is by far one of my favourite little planes! Its reaction time is quite quick. The rudder control is very responsive, even the slightest move of your rudder pedals or the mouse and the aircraft's rudder moves. It accelerates quite fast down the runway, building up momentum and then, you lift your joystick up slightly and the nose lifts up just like you want it to.

Regarding the animations, they are extraordinary. They function quite well like for example the flaps, spoilers or the landing gear. The cockpit is quite well designed and has a lot of instruments, just like a real Citation would.

It has a tutorial system built in for people wanting to fly one. '''''This was the first jet plane that I could actually land properly in.''''' It also has several nice camera views, including views from the passenger seats.

<gallery>
Image:Cessna Citation X Cockpit.png
Image:Cessna Citation X Passenger View 1.png
Image:Cessna Citation X Passenger View 2.png
Image:Cessna Citation X - Screenshot 2.png
</gallery>

'''Recommendation:'''

I would recommend this plane to people who have already flown planes like the [[Cessna C172P]] or the [[Piper J3 Cub]] and want to progress into Jet aviation. This is a GREAT little starter plane to get you going.

This has to be one of the best planes that I have ever used in FlightGear!

Thanks for reading! :D

'''''Review By: Vinura'''''

== Wiki updates ==
===New articles===
<DynamicArticleList>
type=new
count=10
</DynamicArticleList>
===New aircraft articles===
<DynamicArticleList>
type=new
count=10
categoryRoot=Aircraft
</DynamicArticleList>
===Most popular newsletters===
<DynamicArticleList>
type=hot
count=5
categoryRoot=FlightGear Newsletter
</DynamicArticleList>

== Community news ==
=== FlightGear on youtube ===

=== Forum news ===
=== Multiplayer ===
=== Virtual airlines ===
=== FlightGear events ===
==== FlyingClub Mayday 1 ====
The FGFC '''"Mayday 1: Manitoba Rescue"''' operation was held April 2nd, 2011 at CYAV, Winnipeg/St.Andrews, with seven pilots participating. The scenario stated two of Manitoba's major rivers were flooding, and people were stranded along both, so STOL and helicopter pilots were mustered at CYAV, received assignments from ATC, planned their flights, and notified ATC when they were ready to proceed. A total of twenty missions were assigned, sixteen of which were successfully completed in the space of three hours.

The scenario was based around the idea that pilots should have basic skills in addition to merely flying with an autopilot, and was designed to test both their actual flying ability by not having airports at their destinations, and providing no actual navigational data beyond a map or two. They were required to map their routes in territory unknown to them, then fly those routes in their chosen aircraft, land, report in, then return to CYAV to complete a "cycle." Points were awarded for cycle completion, and points deducted for aircraft crashes. FG Seg faults were not penalized.

Comments back about the operation from pilots have so far been positive. Watch the [http://www.flightgear.org/forums/viewforum.php?f=10&sid=381d9860a9183d143cd2fa8aee16099d Multiplayer Forums] for the next one; there will be one, but at this writing, it has not yet been decided.

* [[FlightGear Flying Club]]
* [http://flightgearfans.wordpress.com/about/ FGFC WordPress Site ]
* [http://www.flightgear.org/forums/viewtopic.php?f=10&t=11551 Mayday 1 Forum Pages]

== Useful links ==
== And finally ... ==
=== Contributing ===
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common misconception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.

For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].

=== Call for volunteers ===
* The [[OpenRadar]] project is looking for a new maintainer.
* The [[FGFSPM]] (FlightGear Package Manager) is looking for a new maintainer.

=== Did you know ===
*...that you can fly backwards in a UFO? While holding the brake button down on your joystick or keyboard, increase engine throttle and you should start to fly backwards. A short video can be seen at [http://www.youtube.com/watch?v=F7U1bsO7g-EYouTube]

[[Category:FlightGear Newsletter|2011 04]]

Next Generation Scenery

2011-04-03T18:25:10Z

Zan: typo...

These are some ideas for new scenery and new scenery engine for FlightGear.

== Why? ==
We would like to show more detailed scenery that's visible farther away, for a better VFR experience all around. Specifically, more detail makes the near-ground experience more realistic, especially for helicopter or VFR flight; scenery that truly extends to the visible horizon would make high-altitude flight more interesting. In addition, it's fun to fly around a richly detailed world.

==== Disclaimer ====

* Most of these items have been collected from various places without reasonable evaluation. Thus, they might simply represent peoples random ideas without any warranty about a) making sense in the given context nor b) aligning with the plans of those who are actually driving FlightGear's Scenery development. So, read this with a grain of salt ....

=== Ideas ===

* ability to dynamically enable/disable certain scenery features ([http://sourceforge.net/tracker/index.php?func=detail&aid=1905510&group_id=583&atid=350583])

* Provide the foundation to eventually facilitate runtime-based creation of airport features (i.e. runways and taxiways), so that changes to the underlying data files (apt.dat.gz) could be immediately honored at runtime without having to recompile scenery tiles

* Ability to cut in polygon models of airports. [http://www.andesengineering.com/Projects/TDS/]

* Ability to page terrain / textures so continuous flights around the world are still possible.

* Ability to populate the world with arbitrary additional 3d objects. Note that our current ability to populate the world with random objects would not work with the new scheme. We'd need to completely overhaul that functionality to work in a photo texture drapped, LOD terrain world.

* Care should be taken with object vertical placement so the terrain LOD doesn't move the 3d objects up and down noticable. And also so it doesn't noticably bury objects or float objects when the terrain LOD changes.

* I assume all the current 2d polygon data would go away since this would be better represented by the photo texture overlay anyway.

* LOD algorithm/system (with adjustable radius for high and low end users) The current irregular grid mesh works but it's not very efficient and we could get much better framerates with a nice LOD system. Alternatively much higher elevation resolution with similar framerates.

* Texture overlays - FG scenery engine does the chopping and texture co-ord generation. (I won't go into details but this would greatly simplify LOD algorithms)

* The ability to drape the textures at differing resolutions at different locations in the scenery. (ie. higher res data immediately adjacent to airports where the pilot is generally closer to the ground and to give good definition on final approach).

* Some sort of fix or workaround for the stretched-textures-on-cliff faces problem that draped textures suffer from in mountainous regions - possibly the ability to cut in textured polygons on steep faces.

=== Data sources ===
Here is a list of possible data sources for better scenery.
==== Elevation data ====
* [http://srtm.csi.cgiar.org/ SRTM Data] - 30m resolution for North America, 90m for most other world. Data goes up to about 60 degrees north and 56 degrees south. This should be public domain so can be used directly.
* [http://www.ersdac.or.jp/GDEM/E/index.html ASTER GDEM] Aster data, 30m resolution for the whole world, from 83 degrees north to 83 degrees south. License is limited, might be able to get the data and use, but redistribute with non-GPL license.
* [http://www.viewfinderpanoramas.org/dem3.html Mountain data] Personal work of Jonathan for filling&fixing SRTM data for mountain areas. Mostly 90m resolution, but some areas are 30m. Also has some data for north eurasia not available in SRTM. Data should be free to use, but not sure about the GPL compatibility.

==== Shapefile data ====
Some sources for shapefiles, some of these are already available, the ones with links might not be yet.
* GSHHS
* VMAP0 & 1
* OSM
* TIGER
* [http://www.eea.europa.eu/publications/COR0-landcover Corine] landcover use data for Europe, the ones I have seen are 25m resolution. License is free, but might not be GPL compatible.

==== Photo data ====
To be defined, we might soon get a photo scenery support, so this section is reserved for acquiring free high resolution images for it.

=== Related mailing list discussions ===

* [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18530.html Scenery engine features (collective brainstorming about desired features for a new engine, 4yrs old)]
* [http://baron.flightgear.org/pipermail/flightgear-devel/2004-September/030853.html UK Photo Scenery]
* [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg29480.html alternative terrain engine integration]
* [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg26831.html Landsat 7 data for FlightGear]
* [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg30439.html What happened to the new terrain engine?]
* [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg30777.html normal maps for flightgear]
* [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg27985.html When can we have roads like this]
* [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg07688.html Virtual Cities]
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11499.html
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11325.html Overlay Plane]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13123.html FlightGear Terrain Engine]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg14312.html]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15122.html]
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg00783.html

=== Related Projects/Efforts ===
* [http://fgsd.sourceforge.net FGSD-FlightGear Scenery Designer ]
* [http://taxidraw.sourceforge.net TaxiDraw ]
* [http://www.custom-scenery.org/ FlightGear World Custom Scenery ]
* [http://mapserver.flightgear.org/ FlightGear mapserver ]

[[Category:RFC]]
[[Category:Scenery enhancement]]

Next Generation Scenery

2011-04-03T18:24:43Z

Zan: Added data source links for next generation scenery

These are some ideas for new scenery and new scenery engine for FlightGear.

== Why? ==
We would like to show more detailed scenery that's visible farther away, for a better VFR experience all around. Specifically, more detail makes the near-ground experience more realistic, especially for helicopter or VFR flight; scenery that truly extends to the visible horizon would make high-altitude flight more interesting. In addition, it's fun to fly around a richly detailed world.

==== Disclaimer ====

* Most of these items have been collected from various places without reasonable evaluation. Thus, they might simply represent peoples random ideas without any warranty about a) making sense in the given context nor b) aligning with the plans of those who are actually driving FlightGear's Scenery development. So, read this with a grain of salt ....

=== Ideas ===

* ability to dynamically enable/disable certain scenery features ([http://sourceforge.net/tracker/index.php?func=detail&aid=1905510&group_id=583&atid=350583])

* Provide the foundation to eventually facilitate runtime-based creation of airport features (i.e. runways and taxiways), so that changes to the underlying data files (apt.dat.gz) could be immediately honored at runtime without having to recompile scenery tiles

* Ability to cut in polygon models of airports. [http://www.andesengineering.com/Projects/TDS/]

* Ability to page terrain / textures so continuous flights around the world are still possible.

* Ability to populate the world with arbitrary additional 3d objects. Note that our current ability to populate the world with random objects would not work with the new scheme. We'd need to completely overhaul that functionality to work in a photo texture drapped, LOD terrain world.

* Care should be taken with object vertical placement so the terrain LOD doesn't move the 3d objects up and down noticable. And also so it doesn't noticably bury objects or float objects when the terrain LOD changes.

* I assume all the current 2d polygon data would go away since this would be better represented by the photo texture overlay anyway.

* LOD algorithm/system (with adjustable radius for high and low end users) The current irregular grid mesh works but it's not very efficient and we could get much better framerates with a nice LOD system. Alternatively much higher elevation resolution with similar framerates.

* Texture overlays - FG scenery engine does the chopping and texture co-ord generation. (I won't go into details but this would greatly simplify LOD algorithms)

* The ability to drape the textures at differing resolutions at different locations in the scenery. (ie. higher res data immediately adjacent to airports where the pilot is generally closer to the ground and to give good definition on final approach).

* Some sort of fix or workaround for the stretched-textures-on-cliff faces problem that draped textures suffer from in mountainous regions - possibly the ability to cut in textured polygons on steep faces.

=== Data sources ===
Here is a list of possible data sources for better scenery.
==== Elevation data ====
* [http://srtm.csi.cgiar.org/ SRTM Data] - 30m resolution for North America, 90m for most other world. Data goes up to about 60 degrees north and 56 degrees south. This should be public domain so can be used directly.
* [http://www.ersdac.or.jp/GDEM/E/index.html ASTER GDEM] Aster data, 30m resolution for the whole world, from 83 degrees north to 83 degrees south. License is limited, might be able to get the data and use, but redistribute with non-GPL license.
* [http://www.viewfinderpanoramas.org/dem3.html Mountain data] Personal work of Jonathan for filling&fixing SRTM data for mountain areas. Mostly 90m resolution, but some areas are 30m. Also has some data for north eurasia not available in SRTM. Data should be free to use, but not sure about the GPL compatibility.

==== Shapefile data ====
Some sources for shapefiles, some of these are already available, the ones with links might not be yet.
* GSHHS
* VMAP0 & 1
* OSM
* TIGER
* [http://www.eea.europa.eu/publications/COR0-landcover Corine] landcover use data for Europe, the ones I have seen are 25m resolution. License is free, but might not be GPL compatible.

==== Photo data ===
To be defined, we might soon get a photo scenery support, so this section is reserved for acquiring free high resolution images for it.

=== Related mailing list discussions ===

* [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18530.html Scenery engine features (collective brainstorming about desired features for a new engine, 4yrs old)]
* [http://baron.flightgear.org/pipermail/flightgear-devel/2004-September/030853.html UK Photo Scenery]
* [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg29480.html alternative terrain engine integration]
* [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg26831.html Landsat 7 data for FlightGear]
* [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg30439.html What happened to the new terrain engine?]
* [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg30777.html normal maps for flightgear]
* [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg27985.html When can we have roads like this]
* [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg07688.html Virtual Cities]
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11499.html
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11325.html Overlay Plane]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13123.html FlightGear Terrain Engine]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg14312.html]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15122.html]
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg00783.html

=== Related Projects/Efforts ===
* [http://fgsd.sourceforge.net FGSD-FlightGear Scenery Designer ]
* [http://taxidraw.sourceforge.net TaxiDraw ]
* [http://www.custom-scenery.org/ FlightGear World Custom Scenery ]
* [http://mapserver.flightgear.org/ FlightGear mapserver ]

[[Category:RFC]]
[[Category:Scenery enhancement]]

Talk:TerraGear texmapped line data

2011-01-28T09:18:56Z

Zan:

This looks great and is something I intended to do earlier, but never really got into it.

I wonder how you managed to make the clipper honour the texture coordinates, as that was the step where I let the project be?
Whenever the roads are crossing, you should probably create a new polygon (quad maybe?) there and assign it a "crossroad" material. Of course then you'd need to have different textures for T cross or X cross etc, this is hard.

I also suggest you to use OSM data instead of the line data. As you modified to code generating the wider polygons, I guess it should be quite straightforward to generate the line graph with correct width from OSM xml files and then polygons from those. That way you could get also lane information etc.

I'd like to see how you did this, if you could upload a diff somewhere so I could check? I have some ideas of adding extra parameters and this code of yours might help in the process.

Oh, and I don't think it matters if the "already textured" polygons are added as single triangles or fans or strips. As long as the texture coordinates are preserved :)

[[User:Zan|Zan]] 09:02, 26 January 2011 (UTC)

: Freeways in the Netherlands (and most other 'Western' countries) have [http://en.wikipedia.org/wiki/Interchange_(road) interchanges], rather than [http://en.wikipedia.org/wiki/Intersection_(road) intersections]. So for freeways the current look is fine (except for the z-ordering issue), but for primary/secundary roads Zan's idea would be nice to have...
: [[User:Gijs|Gijs]] 04:10, 26 January 2011 (EST)

: I've been working within a local git repository, and committing very small steps to keep a log of the mods I've made. I'll upload a diff somewhere soon.

: I'm not calculating texture coordinates until after triangulation. In clipper, I still have a texture parameter for each polygon. whenever a polygon is intersected or differenced, the new poly just receives the same tex param. The problem I'm having right now, is polys are unioned into an accumulator. I need to keep this from happening for texmapped line data, so I'm looking at changing how the accumulator works. This isn't as big a deal for OSM data, as I've been looking at keeping OSM z_orders on separate priority levels. (Giving accurate overpasses / underpasses).

: The next hurdle was passing in the trieles to the triangulate library. It currently only takes 1 parameter (the texture type). I combine this with an index into an array of texture parameters, so when the triangles come back, I can then calculate the texture parameters for each triangle based on the indexed texparam. I think I'd rather have the triangle library take the parameters separately, but I haven't looked at the code for that much.

: I've been thinking about interchanges, and such. I think a lot of this should be done with a tool other than ogrdecode. we should have a specialized road decoder (for freeways, primary roads, railways, etc) That can handle OSM data, and optimize/simplify it (I saw a link on some of the research somewhere) and handle merge lanes, intersections and bridges. Lot's of new materials required.
: --[[User:Psadro gm|Psadro gm]] 12:14, 27 January 2011 (EST)

:: I guess you mean this page [http://www.custom-scenery.org/Line-data-simpl.275.0.html] that talks about line simplification.
:: -- [[User:Zan|Zan]] 04:18, 28 January 2011 (EST)

Talk:TerraGear texmapped line data

2011-01-26T09:02:30Z

Zan:

Talk:TerraGear texmapped line data

2011-01-26T08:58:41Z

Zan: Created page with "This looks great and is something I intended to do earlier, but never really got into it. I wonder how you managed to make the clipper honour the texture coordinates, as that was..."

Howto talk:Illuminate faces

2011-01-26T08:51:05Z

Zan: /* Night texture is wrong! */

Hi Gijs, in the new section I'm using code that is understood as a wiki tag: <nowiki><center></nowiki>. It disappears and causes the following bit to be centered. Can you change that and make the center appear as the rest of the code?

Thanks
David [[User:D-79|D-79]] 17:15, 17 August 2009 (EDT)
:David, you can easily make the <nowiki><center></nowiki> tag visible by adding nowiki tags around it (edit page to see how I've done it). This works with all kind of tags (even <nowiki>'''bold'''</nowiki> and <nowiki>[[link]]</nowiki>).
:Regards, [[User:Gijs|Gijs]] 04:30, 18 August 2009 (EDT)

Hi Gijs, thanks for the help! 
David [[User:D-79|D-79]] 05:01, 18 August 2009 (EDT)

== Night texture is wrong! ==

In the section '''Switch to another part of texture if illuminated''' the example texture is wrong. Since the lighting depends on the angle of the sun to the surface, the day-texture will be (almost) totally dark during the night so you don't need the dark night texture. Now, since there is some angle-of-the-sun property which is used to change the night texture, the switch is clearly visible and horribly unrealistic.

Instead, I suggest using either different objects for the windows and using the emissive animation as described earlier, or make the night texture the same as the day texture, but with the windows lit.

I think we might want to use a separate material parameter (is there any that is not yet used?) to control the "night emissivity" and then use that to light the windows etc in a shader.

Any comments?

::Attaching some images to show the issue, pay attention to the time.
::[[File:Fgfs-evening-shot1.png]]
::[[File:Fgfs-evening-shot2.png]]
:: - Zan

File:Fgfs-evening-shot2.png

2011-01-26T08:50:23Z

Zan: KSFO terminal with night textures, compare to the previous shot which was taken about three minutes earlier.

KSFO terminal with night textures, compare to the previous shot which was taken about three minutes earlier.

File:Fgfs-evening-shot1.png

2011-01-26T08:49:40Z

Zan: KSFO Terminal with day textures, few minutes before strange things happen...

KSFO Terminal with day textures, few minutes before strange things happen...

User:Zan

2011-01-26T08:47:25Z

Zan: Created page with "Zan is a wannabe developer."

Zan is a wannabe developer.

Talk:Rendering system improvements

2011-01-25T19:29:05Z

Zan: Added comments

== Suggestions ==
If we rendered it to just render where the camera is pointing, couldn't we get faster frame rates, because it seems like useless rendering to render absolutely everything (even if you're not looking at it).

::Yes, of course the parts of scenery not visible should not be rendered, and that's one thing that OSG does for us. It's called view frustrum culling, and if I remember correctly, the cull thread takes most time per frame in flightgear.
:: - Zan

I'm not absolutely sure how to go about this one, but (I'm sorry for being such an X-Plane fan) couldn't we do sort of like what X-Plane does? So you'd only have to render high quality graphics a close distance to the plane, and further out, the pixels could be a little blurry, but since no one's able to clearly see it that far away, you might as well make it a little bit more blurry. I think that a lot of what Austin (lead developer of X-Plane) says on his "What's New" page is very useful information, and maybe we should take some advice from it.

::This is called level of detail or LOD. We have some kind of LOD schemes currently in flightgear (like trees are visible only when near etc) but better LOD would indeed give better performance and looks. With clouds for example, it could mean using smaller textures farther away, and for terrain, using one baked texture for whole scenery tile insted of different materials. I think there have been some discussion about LOD before, I could search for them and link them up, as it is an important aspect.
::Also, should probably use simpler shaders when objects are far away... even though that itself brings LOD since there is less pixels to render.
::And the new X-Plane screenshots indeed look great. [http://www.x-plane.com/pg_news.html]
:: - Zan

Talk:Shader requests

2011-01-20T12:21:27Z

Zan: Created page with "Water shader link is broken, leads to a topic about "RSS Feed""

Water shader link is broken, leads to a topic about "RSS Feed"

Howto talk:Illuminate faces

2011-01-19T11:29:31Z

Zan: /* Night texture is wrong! */ new section