Changes

Jump to: navigation, search

Howto:Shader programming in FlightGear

3,322 bytes added, 00:14, 13 October 2014
no edit summary
=== Effects File ===
{{Note|need link to Effects Doc hereto explain the details of the effects file}}
==== Parameters ====
Parameter entries defined in the Effect file correspond to a property tree data container (static or variable). They will contain the data needed by the shader program to perform its magic. The type of information contained in the property tree might be program control data or variable/static data that the shader program can manipulate prior to sending on to render.
Some of this data may play a duel role inside the shader program. In other words it might be used to control other functions in addition to ALS Lights.
There will also be other parameter entries that have nothing to do with ALS Lights. They might be used for other actions or effects the shader is handling.
==== Technique ====In general, the shader program and the uniforms are handled in between the technique tags. The technique is
==== Shader Program ====
Next comes the entry to define what Shader Program the parameters data is going to be passed to.
This is where you specify what shader code is to be used by the technique. ALS has the lowest techniques, with higher quality preceding lower quality.
<program>
<fragment-shader>Shaders/tree-ALS.frag</fragment-shader>
In the case of ALS Lights, so far we only have to deal with the fragment shader.
The program section of the effect file is a nifty method used to allow users to add shaders to [[Flightgear]] without having to add code at C level language base. The C level base is programed to recognize the XML tag pair of <program></program> and thus incorporate the GLSL program files pointed to between the tags. Otherwise you would have to add the GLSL program calls in the base C requiring a completely different set of programming skills and also the necessity of compiling [[Flightgear]] everytime you want to add new shaders. It can work this way because shader programs are compiled at run-time.
We'll describe the contents of the shader programs below. For now, suffice it to say tree-ALS.frag contains the main program and secondary_lights.frag has functions that are passed uniform data that is manipulated and returned to main for processing.
==== Uniforms ====
The uniforms section is used
=== Shader Program ===
** adds uniforms (technique 2)
== General Comments from Forum Discussion ==
 
{{cquote|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.<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24226&start=15#p220152
|title=ALS landing lights
|author=Thorsten Renk |date= Wed Oct 08, 2014 1:58 -0700}}</ref>|Thorsten Renk}}
{{WIP|more to follow}}
266
edits

Navigation menu