Effect Framework

5,486 bytes added, 1 September
no edit summary
The effect framework as per version 2019.1
Effects describe the graphical appearance of 3d objects and scenery in
FlightGear. The main motivation for effects is to support OpenGL
shaders and to provide different implementations for graphics hardware
of varying capabilities. Effects are similar to DirectX effects files
and Ogre3D material scripts.
An effect is a property list. The property list syntax is extended
with new "vec3d" and "vec4d" types to support common computer graphics
values. Effects are read from files with a ".eff" extension or can be
created on-the-fly by FlightGear at runtime. An effect consists of a
"parameters" section followed by "technique" descriptions. The
"parameters" section is a tree of values that describe, abstractly,
the graphical characteristics of objects that use the effect. Techniques
refer to these parameters and use them to set OpenGL state or to set
parameters for shader programs. The names of properties in the
parameter section can be whatever the effects author chooses, although
some standard parameters are set by FlightGear itself. On the other
hand, the properties in the techniques section are all defined by the
=Default Effects in Terrain Materials and Models=
Condition for this A technique can contain a predicate that describes the OpenGLfunctionality required to be support the technique. The firsttechnique with a valid predicate in the list of techniques is usedto set up the graphics state of the effect. If this fails it will try A technique with nopredicate is always assumed to be valid. The predicate is written in alittle expression language that supports the next following primitives: and, or, equal, less, less-equalglversion - returns the version number of OpenGLextension-supported - returns true if an OpenGL extension is supportedproperty - returns the boolean value of a propertyfloat-property - returns the float value of a property, useful inside equal, less or less-equal nodesshader-language - returns the version of GLSL supported, or 0 if there is none. The proper way to test whether to enable a shader-based technique is:<syntaxhighlight lang="xml"> <predicate> <and> <property>/sim/rendering/shader-effects</property> <less-equal> <value type="float">1.0</value> <shader-language/> </less-equal> </and> </predicate></syntaxhighlight> There is also a property set by the user to indicate what is the level of quality desired. This level of quality can be checked in the effectpredicatelike this :<syntaxhighlight lang="xml"> <predicate> <and> <property>/sim/rendering/shader-effects</property> <less-equal> <value type="float">2.0</value> <float-property>/sim/rendering/quality-level</float-property> </less-equal> <!-- other predicate conditions --> </and> </predicate></syntaxhighlight> The range of /sim/rendering/quality-level is [0..5] * 2.0 is the threshold for relief mapping effects, * 4.0 is the threshold for geometry shader usage.
What A technique can consist of several passes. A pass is passed to the shaders/basically an OpenScene Graph StateSet. Ultimately all OpenGL and OSGmodes and stateattributes will be accessable in techniques.State attributes -- that(Not sureis, but think multiple passes technique properties that have children and are possiblenot just booleanmodes -- have an <active> parameter which enables or disables theattribute.)In this way a technique can declare parameters it needs,but not enable the attribute at all if it is not needed; the decisioncan be based on a parameter in the parameters section of theeffect. For example, effects that support transparent and opaquegeometry could have as part of a technique:
Note that entries <syntaxhighlight lang="xml"> <blend> <active><use>blend/active</use></active> <source>src-alpha</source> <destination>one-minus-src-alpha</destination> </blend></syntaxhighlight> So if the blend/active parameter is true blending will be activatedusing the usual blending equation; otherwise blending is disabled. Values are assigned to technique properties in several ways:  * They can appear directly in the techniques section as a constant. For example:<syntaxhighlight lang="xml"> <uniform> <name>ColorsTex</name> <type>sampler-1d</type> <value type="int">2</value> </uniform></syntaxhighlight> * The name of a property in the parameters section can be referenced using a "use " clause. For example, in the technique section:<syntaxhighlight lang="xml"> <material> <ambient><use> tags to enable material/ambient</use></ambient> </material></syntaxhighlight> Then, in the parameters section of the effect:<syntaxhighlight lang="xml"> <parameters> <material> <ambient type="vec4d">0.2 0.2 0.2 1.0</ambient> </material> </parameters></syntaxhighlight> It's worth pointing out that the "material" property in a technique specifies part of OpenGL's state, whereas "material" in the parameters section is just a name, part of a hierarchical namespace.  * A property in the parameters section doesn't need to specify contain a constant value; it can also contain a "use" property. Here the value of the use clause is the name of a node in an external property tree which will be used as the source of a value. If the name begins with '/', the node is in FlightGear's global property tree; otherwise, it is in a local property tree, usually belonging to a model [NOT IMPLEMENTED YET]. For example:<syntaxhighlight lang="xml"> <parameters> <chrome-light><use>/rendering/scene/chrome-light</use></chrome-light> </parameters></syntaxhighlight> The type is determined by what is expected by the technique attribute that will ultimately receive the value. [There is no way to get vector valuesout of the main property system yet; this will be fixed shortly.] Values that are declared this way are dynamically updated if the property node changes.