Effects: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 16: Line 16:
   |script_version = 0.40  
   |script_version = 0.40  
   }}</ref>
   }}</ref>
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 <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35389912/
  |title  =  <nowiki> Re: [Flightgear-devel] SR71-BlackBird updates </nowiki>
  |author =  <nowiki> Thorsten Renk </nowiki>
  |date  =  Sep 25th, 2016
  |added  =  Sep 25th, 2016
  |script_version = 0.40
  }}</ref>
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.<ref>{{cite web
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.<ref>{{cite web
   |url    =  https://sourceforge.net/p/flightgear/mailman/message/35389912/  
   |url    =  https://sourceforge.net/p/flightgear/mailman/message/35389912/  

Revision as of 08:35, 25 September 2016

This article is a stub. You can help the wiki by expanding it.
Cleanup.png This article may require cleanup to meet the quality standards of the wiki. Please improve this article if you can.

1rightarrow.png 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.[1] 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 [2]

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.[3]


effects in FlightGear, regardless if they are generic, ALS or Rembrandt, are all together 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. [4]


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[5]


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
  1. Thorsten Renk  (Sep 24th, 2016).  Re: [Flightgear-devel] SR71-BlackBird updates .
  2. Thorsten Renk  (Sep 25th, 2016).  Re: [Flightgear-devel] SR71-BlackBird updates .
  3. Thorsten Renk  (Sep 25th, 2016).  Re: [Flightgear-devel] SR71-BlackBird updates .
  4. ludomotico  (Sep 19th, 2016).  Re: Colour Temperature .
  5. Thorsten  (Sep 19th, 2016).  Re: Colour Temperature .