Effects
| This article is a stub. You can help the wiki by expanding it. |
|
|
Typically, shaders will be made acccessible through "effects", for that, see $FG_ROOT/Docs/README.effects
In FlightGear, many shaders are used through the so called "effects" framework, to learn more about that, see $FG_ROOT/Docs/README.effects
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