Effects

This article is a stub. You can help the wiki by expanding it.

This article may require cleanup to meet the quality standards of the wiki. Please improve this article if you can.

See shaders for the main article about this subject.

Caution  For the record, we strongly object against aircraft in FGAddon overriding the predicate section of effects - it's there for a reason. This may (appear to) work now, but please understand that it's neither future-proof nor harmless - any maintenance on effects on fgdata has the potential to cause rather subtle and difficult to understand breakage. We have always aimed at keeping any development of effects backward-compatible (i.e. aircraft maintainers don't need to take action, effects with added features always default to the known behavior) - thus, breaking this is a path forward. Thus, favor a proper implementation FGData-side, but if that's not an option, copies of the relevant effects and shaders completely residing aircraft-side would be harmless as far as breakage is concerned and would 'freeze' the current state of the effect for teh What's really bad is overriding the FGData-side effect selection scheme scheme aircraft-side because that can cause unexpected breakage when FGData changes. If it's all completely aircraft-side, FGData maintenance doesn't affect it.

Effects in FlightGear, regardless if they are generic, ALS, or Rembrandt; are contained in two directories: FGDATA/Shaders and FGDATA/Effects. Probably, this is a constrain of FlightGear; we have three different renderers (four, if you count the "unofficial" osgearth), and all of them save effect files in the same directories. Some of the effects are shared between all renderers, such as the model-combined effect.

Effects are responsible for all three frameworks, so by nature they have to be shared (the contain the logic which rendering framework is used) - the ALS-relevant sections are usually denoted by a comment and marked by the test in the predicate section. All ALS shaders have the string *-ALS* somewhere in the filename (and usually the filename is descriptive as far as object and quality level are concerned - so terrain-ALS-base.frag handles terrain on base quality level, water-ALS-high.frag handles water at high quality level

An effect is a container for a series of techniques which are all the possible things you could do with some object. The <predicate> section inside each effect determines which of the techniques we actually run. Typically the predicate section contains conditionals on a) rendering framework properties b) OpenGL extension support and c) quality level properties. The renderer searches the effects from lowest to highest technique number and uses the first one that fits the bill (which is why high quality levels precede low quality levels). The rendering itself is specified as <pass> - each pass runs the renderer over the whole scene. We may sometimes make a quick first pass to fill the depth buffer or a stencil buffer, but usually we render with a single pass. Techniques may not involve a shader at all, for instance 12 in terrain-default is a pure fixed pipeline fallback technique, but all the rendering you're interested in use a shader, which means they have a <program> section which determines what actual code is supposed to run. If you run a shader, that needs parameters specified as <uniform>, and textures which need to be assigned to a texture unit _and_ be declared as a uniform sampler. In addition, each technique contains a host of parameter configuring the fixed pipeline elements, like alpha tests before the fragment stage, or depth buffer writing/reading, alpha blending,... you can ignore them on the first go. So if you want to look at which shader code is executed when you call the water effect at a certain quality level, you need to work your way through the predicate sections of the techniques from lowest to highest till you find the one that matches, and then look into the program section of that technique. Now, to make matters more complicated, all the parameters and textures that are assigned to uniforms and texture units in the techniques need to be declared and linked to properties were applicable in the <parameters> section heading each effect declaration. So a texture you want to use has to appear three times - in the parameters section heading the effect, inside the technique assigned to a texture unit and assigned to a uniform sampler. Now, inheritance moves all the declared parameters and techniques from one effect to the one inheriting. In the case of water, that means the technique is actually _not_ inherited because terrain-default.eff doesn't contain a technique 1 at all, but the general <parameters> section is inherited. So you don't need to declare the additions to <parameters> again, but you do need to make the changes to the <programs> and the <uniform> sections.

If you are into the really heavy eye-candy, then you'll probably want to look at using FlightGear effects, which are plain XML files, see $FG_ROOT/Docs/README.effects.

And then, the final -and most powerful option- is obviously creating custom GLSL shaders: http://wiki.flightgear.org/Shader The latter will involve programming obviously, and does require a strong mathematical background though - or at least familiarity with 3D graphics and the necessary maths involved.

We only have a handful of people developing shaders here. While that doesn't involve any C++ programming or rebuilding FG from source, most of the shader developers here are in one way or another either professional software developers and long-term FG contributors with at least a master's degree, or have other degrees in related fields such as mathematics, physics or computer science/software engineering.

A very basic introduction to shader programming is available here: http://wiki.flightgear.org/Howto:Shader ... FlightGear Numerous pointers on more complex topics are provided here: http://wiki.flightgear.org/GLSL_Shader_ ... _Resources And we even have our own sub forum for "eye candy developers" here: viewforum.php?f=47

Typically, shaders will be made acccessible through "effects", for that, see $FG_ROOT/Docs/README.effects

To learn more about the shader compilation process, see: http://forum.flightgear.org/viewtopic.php?f=47&t=24226&p=228095&hilit=README.effects#p228095

In FlightGear, many shaders are used through the so called "effects" framework, to learn more about that, see $FG_ROOT/Docs/README.effects

GLSL shaders are compiled 'as needed' - a bit simplified, the very frame an object using a shader (at your current quality level setting) comes into view the shader is compiled.

(Which, incidentially, is why definitions are repeated in any shader - each shader must be a standalone object because it can't rely on other shaders being compiled or running or exchanging information. GLSL is basically the most parallel processing environment you can thing of where no part of the ongoing computation talks much to any other - one pixel doesn't know what any other pixel does)

effects can be used, edited and customized even without understanding GLSL - those are just XML files, see README.effects in $FG_ROOT/Docs GLSL is a different thing obviously. But the syntax is mostly ANSI C - so the main challenge is not knowing the language, but the way GPUs work, and how different types of shaders work in terms of having a dynamic/configurable "pipeline". Even that is not necessarily rocket science - as Thorsten has shown over and over again: shader development is primarily about understanding fairly involved maths and physics, not about the language itself, or even about the run-time environment.

To learn more about effects, and shaders, I'd suggest these resources:

$FG_ROOT/Docs/README.effects $FG_ROOT/Docs/README.materials http://wiki.flightgear.org/Shaders http://wiki.flightgear.org/Howto:Shader ... FlightGear http://wiki.flightgear.org/GLSL_Shader_ ... _Resources

Once you've read these, you should have a better understanding of how effects and shaders hang together, and what *.frag/*.vert files are doing, and how they're generally structured. Note that these articles will usually contain additional pointers - while familiarity with programming (especially in C/C++) will come in handy, GLSL is primarily about 3D math - so you need a strong background in math to understand more sophisticated coding examples/snippets.

When it comes to shader programming, people with a strong background in maths and physics will find it much easier to make working modifications than people who "just" have a strong programming background. but lacking the math skills

all effects/shaders are optional, it's just that the standard settings assume that shader support is available.

While you can certainly change a few numbers here and there to see how that affects the final outcome, you'll find that understanding the underlying maths will be very helpful - for that, see the links that Thorsten posted, or those that you can find inside those shader files.

so called "shaders" that will be normally run by your GPU: http://en.wikipedia.org/wiki/OpenGL_Shading_Language To give you some background on shaders in FlightGear, please see: http://wiki.flightgear.org/Shaders These are plain text files that are compiled by your GPU's driver, transparently in the background.

To understand a few basics such as the differences between FRAGMENT and VERTEX shaders, see http://wiki.flightgear.org/Howto:Shader_Programming_in_FlightGear

the mechanism for such "post-processing" are so called "effects" (see $FG_ROOT/Docs/README.effects) and shaders: http://wiki.flightgear.org/Shader

But for that to be supported, you need to render to an offscreen rendering target (aka a texture/memory buffer) - Rembrandt basically consists basically of multiple such buffers chained together in a cascaded fashion.

By default, the standard rendering pipeline will not do this currently. However, to some extent, custom cameras can be used to emulate this: http://wiki.flightgear.org/Howto:Configure_camera_view_windows

For example, here's Chris Calef's custom camera setup for his "SkyBox server": http://wiki.flightgear.org/Howto:Configure_camera_view_windows#Required_changes_in_preferences.xml

These cameras can also be rendered to a buffer/texture [1]: http://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Docs/README.multiscreen

The FlightGear effects framework is documented in $FG_ROOT/Docs/README.effects.

FlightGear effects are stored in $FG_ROOT/Effects. FlightGear shaders are stored in $FG_ROOT/Shaders.

Also, the FlightGear wiki contains some more pointers on shader programming:

   * http://wiki.flightgear.org/index.php/Ho ... FlightGear
   * http://wiki.flightgear.org/index.php/GL ... _Resources

References

References