Normally in mid-November a group of FlightGear enthusiasts participate in [[FSWeekend]] in [https://www.aviodrome.nl/ Aviodrome] at the [https://www.lelystadairport.nl/ Lelystad Airport] in the Netherlands. Over the years this has been a focal point for both finishing existing development/releases and a catalyst for new ideas in FlightGear, as well as an opportunity for FlightGear enthusiasts to share a beer. This year the [https://www.aviodrome.nl/evenementen/flight-simulator/?_gl=1*1hh597t*_up*MQ..&gclid=EAIaIQobChMIhdjmndaLgQMVKpiDBx3wFwOwEAAYASAAEgI64vD_BwE Flight Simulator Weekend] has been re-scheduled to March 16/17 2024.

To keep the spirit alive and repeat the successful execution of the [[Virtual_FSweekend_Hackathon_2020|Virtual FSweekend Hackathon 2020]] and [[Virtual_FSweekend_Hackathon_2021|Virtual FSweekend Hackathon 2021]], we are planning to hold another Virtual FSweekend Hackathon on the weekend of {{{days_string|10/11/12}}} November {{{year|2023}}} (in {{days from now|{{{year|2023}}}|11|10}}).

== Hackathon? ==
For those who have not participated in a hackathon before, the broad idea is to get people from a wide variety of experience and backgrounds together to solve problems over a short period of time - typically 24 or 48 hours. Details vary, but typically at the start of the event, people pitch ideas and groups form organically based on what people are interested in. The groups then work together intensively, often fueled by pizza and caffeine etc. At the end of the hackathon the groups present their work and there are often prizes for the best hacks.

The general idea of virtual FSWeekend hackathons is to encourage existing and new contributors to collaborate over the course of a weekend to create new and exciting features for FlightGear in the broadest sense. The core developers would particularly like to use it as an opportunity to encourage people to get their hands dirty in the core code, so they will be primarily there to help/coach people rather than hacking themselves, but anything is possible :)

No prior development experience is necessary - there might be run some education sessions ahead of the weekend so people can hit the ground running (otherwise you will learn during the hackathon). Also, do not feel you have to commit to coding the entire weekend to the exclusion of all else. We think participants will still get real value if they can just commit to one day and some late evenings.

== Only Core Development? ==
While the core of the hackathon incl. support previously has been dedicated to development in the very core of FlightGear (mostly C++, [[Nasal_scripting_language|Nasal]] and xml), you are also welcome to participate if you are developing stuff, which contributes to the general FlightGear ecosystem (e.g. [[Addon]], visual artwork or [[Osm2city.py|osm2city]]). However, in that case you might need to provide your own support.

== Sign up ==
{{Note|There is space for many participants, so don't be shy. {{{organizer|Rick}}} is happy for people to register right up to the Friday night, but we will not be able to help out with getting builds and git working if you leave it that late!}}

To register your participation, please contact {{{organizer|Rick}}} either on the {{forum link|t=41662|text=forum post}}, by PM on the [https://discord.gg/rzuV2DR FlightGear Discord server] or via the [https://sourceforge.net/p/flightgear/mailman/message/37890811/ devel list].

Confirmed participants (in alphabetical order):

{| class="wikitable"
|-
! Name
! aka.
! Role
! Remarks
|-
|Nia
|[https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=21618 merspieler], Nia on [https://matrix.to/#/#flightgear-jsbsim:hacklab.fi FG Matrix]
|Infra provider, ask if you've got issues with Mattermost or Jitsi
|Can help with osm2city data processing (worldbuild stuff)
|-
|Rick Gruber-Riemer
|[https://forum.flightgear.org/memberlist.php?mode=viewprofile&u=9140 vanosten], HB-VANO on FG Discord
|Organiser/mentor
|Can coach osm2city and OSM data processing
|-
|Stuart Buchanan
|[[User:Stuart|stuart]]
|Mentor
|Can coach on most part of FlightGear. Particularly interested in WS3.0 at the moment.
|-
|Fernando García Liñán
|[[User:Icecode|icecode]]
|Mentor
|Can coach on most of FlightGear, mainly graphics-related stuff. Mainly interested in [[Compositor]] and [[HDR]].
|}

== Ahead of the Hackathon ==
There are a couple of key activities ahead of the weekend in {{{year|2023}}}.

=== Getting started ===
So we can hit the ground running, we really want everyone participating to already have:
* SourceForge credentials
* A working build environment with [[OpenSceneGraph|OSG]], [[PLIB]] etc.
* A Git checkout of simgear/flightgear (cf. [[FlightGear_Git]])
* A Git checkout of fgdata
* Some experience with [https://git-scm.com/ Git]

At the very least you should be able to work with a [[FlightGear_build_server|nightly version]] of FlightGear.

Before the Hackathon consider having a look into the dedicated [[:Category:Hackathon Materials|Hackathon Materials]] category for articles, which might help get you going.

=== Logistics ===
Being completely remote, we need the ability to collaborate in teams as well as video conference as a group.

There will be a [https://mattermost.com/ Mattermost] server for the weekend. We'll be using that for organization, discussion and collaboration.

We'll be using a [https://jitsi.org/ Jitsi] Server for video conferencing and demos.

To use the server, please start the Jitsi calls from within Mattermost (click on that power plug symbol in the top bar next to the search). Preferably use an app or Chrome/Chromium.

=== Ideation ===
The core of the Hackathon! These are the projects, ideas and problems that participants will be working on during the weekend. In the weeks before the Hackathon itself, participants can, and should, propose things to work on. Simply create a wiki page describing your idea, and encourage people to contribute and get interested.

Check out the [[:Category:Hackathon {{{year|2023}}} Ideas|Hackathon {{{year|2023}}} Ideas]] category page for a how-to as well as links to existing proposals.

You can also take a look at proposals from the previous years.

Not having an idea? No problem! Have a look at the proposed ideas, leave a comment on the Discussion page, and add yourself as an Interested Party for those ideas you consider working on during the Hackathon. There is no commitment until the start of the Hackathon on Friday evening.

== Schedule ==
With (hopefully) a world-wide group of participants, and varying real life constraints, at any given time over the weekend there will hopefully be a couple of people active.

We will have two big get-togethers:

=== {{{kick-off-totd-utc|Friday 10th November 2000-2200 UTC.}}} Kick-off ===
* General welcome
* Introductions
* Hack pitches
* Team formation

This is the point at which participants will decide, which Hacks they want to work on. The sponsors of each of the Hacks proposed ahead of time will be invited to give a 5 minutes pitch to the group, with some questions from the audience. Slides/screenshots optional.

After all the Hacks have been pitched, we will have a little break for people to chat and work out which Hack they want to work on.

If a Hack ends up with fewer than 2 people wanting to work on it (including the sponsor), then it will normally be dropped. This is to encourage people to work in groups - larger teams can get more done in the time, and have more opportunities to learn from each other, plus it is more sociable!

=== {{{wrap-up-totd-utc|Sunday 12th November 2000-2200 UTC.}}} Wrap up and demos ===
At the end of the hackathon we will have a get together and have each team present the results of their hack.

Depending on the number of hacks, each team will have 5-15 minutes to demonstrate their hack, describe what they have learned, and what their next steps are.

We will finish with voting for the best hack of the weekend.

== FAQ ==

'''Q''': What is the aim of the Hackathon? 
'''A''': To learn and have fun hacking FlightGear. Encourage people to get their hands dirty and modify code. Try out new ideas. Working with other people. Ultimately to increase the number of core developers.

'''Q''': What can participants expect to get out of the weekend? 
'''A''': The primary goal is for people to learn through experimentation. To try out new ideas and in the process learn about the internals of FlightGear. James, Stuart and Fernando will be be providing coaching over the course of the weekend.

'''Q''': What organization will be provided? 
'''A''': We will provide tools for collaboration, and organize a couple of meetings, but not much more. The idea behind hackathons is that participants largely self organize - teams form around interesting ideas on Friday evening and organize themselves. Participants will need to provide their own computers, pizza, Haribo, beer. The last three are traditional, but optional.

'''Q''': How much time do I need to commit? 
'''A''': The more the better. A traditional hackathon would be 24-48 hours of solid work with sleep optional. That is not realistic for most people, but 20 hours over the weekend would be a good amount to aim for. Certainly if you can only commit to a couple of evenings you may not get much out of Hackathon.

'''Q''': What skills do I need? 
'''A''': It depends on what you want to do. You need to know C/C++ already to be able to hack the core of FlightGear. The Hackathon is not a good place to learn C++ for the first time. However, there are lot of interesting projects using Python, Nasal etc.

'''Q''': I have got a great idea for the Hackathon. What do I do? 
'''A''': Great! Create a wiki page describing it to enthuse other people and collect comments (see [[#Ideation]] section above), and post a link to the Ideation section above so everyone can see it.

[[Category:Hackathon Materials]]
[[Category:Hackathons]]

Effect framework

2023-05-05T04:53:23Z

Icecode:

{{forum|47|Effects & Shaders}}
{{Rendering}}
The '''Effect framework''' as per FlightGear version 2020.3

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
FlightGear.

== Default effects in terrain materials and models ==
Effects for terrain work in this way: for each material type in
materials.xml an effect is created that inherits from a single default
terrain effect, Effects/terrain-default.eff. The parameters section of
the effect is filled in using the ambient, diffuse, specular,
emissive, shininess, and transparent fields of the material. The
parameters image, filter, wrap-s, and wrap-t are also initialized from
the material xml. Seperate effects are created for each texture
variant of a material.

Model effects are created by walking the OpenSceneGraph scene graph
for a model and replacing nodes (osg::Geode) that have state sets with
node that uses an effect instead. Again, a small effect is created
with parameters extracted from OSG objects; this effect inherits, by
default, from Effects/model-default.eff. A larger set of parameters is
created for model effects than for terrain because there is more
variation possible from the OSG model loaders than from the terrain
system. The parameters created are:

* material active, ambient, diffuse, specular, emissive, shininess, color mode
# blend active, source, destination
# shade-model
# cull-face
* rendering-hint
* texture type, image, filter, wrap-s, wrap-t

== Specifying custom effects ==
You can specify the effects that will be used by FlightGear as the
base effect when it creates terrain and model effects.

In the terrain materials.xml, an "effect" property specifies the name
of the model to use.

Material animations will be implemented by creating a new effect
that inherits from one in a model, overriding the parameters that
will be animated.

== Examples ==
The $FGDATA/Effects directory contains the effects definitions; look there for
examples. Effects/crop.eff is a good example of a complex effect.

== Application ==
To apply an effect to a model or part of a model use:

<syntaxhighlight lang="xml">
<effect>
<inherits-from>Effects/light-cone</inherits-from>
<object-name>Cone</object-name>
</effect>
</syntaxhighlight>

where <inherits-from> </inherits-from> contains the path to the effect you want to apply.
The effect does not need the file extension.

=== Parameters in model file ===

Parameters can be put into the model files effect application as well. But only bool, int, float, string can be used there.

=== Chrome old usage ===

Chrome, although now implemented as an effect, still retains the old method of application:

<syntaxhighlight lang="xml">
<animation>
<type>shader</type>
<shader>chrome</shader>
<texture>glass_shader.png</texture>
<object-name>windscreen</object-name>
</animation>
</syntaxhighlight>

in order to maintain backward compatibility.

== Reload effects at runtime ==
To reload an effect applied in a model xml file (e.g. some parameters and what it enherits from) just go into debug menu and select Reload Model.

To reload the entire effect framework including eff files, go into menu and debug and configure development extensions and reload shaders. This is broken in 2020.1 though, but works in earlier FG versions.

== The XML tags of an effect ==

=== name ===
The name of the effect

=== inherits-from ===
One feature not fully illustrated in the sample below is that
effects can inherit from each other. The parent effect is listed in
the "inherits-from" form. The child effect's property tree is
overlaid over that of the parent. Nodes that have the same name and
property index -- set by the "n=" attribute in the property tag --
are recursively merged. Leaf property nodes from the child have
precedence. This means that effects that inherit from the example
effect below could be very short, listing just new
parameters and adding nothing to the techniques section;
alternatively, a technique could be altered or customized in a
child, listing (for example) a different shader program. An example
showing inheritance Effects/crop.eff, which inherits some if its
values from Effects/terrain-default.eff.

FlightGear directly uses effects inheritance to assign effects to 3D
models and terrain. As described below, at runtime small effects are
created that contain material and texture values in a "parameters"
section. These effects inherit from another effect which references
those parameters in its "techniques" section. The derived effect
overrides any default values that might be in the base effect's
parameters section.

=== parameters ===
Custom parameters that controls the effect.

Note that parameters can use the <use> tags to enable properties to specify the values.

=== generate ===

Often shader effects need tangent vectors to work properly. These
tangent vectors, usually called tangent and binormal, are computed
on the CPU and given to the shader as vertex attributes. These
vectors are computed on demand on the geometry using the effect if
the 'generate' clause is present in the effect file.

Example :

<syntaxhighlight lang="xml">
<generate>
<tangent type="int">6</tangent>
<binormal type="int">7</binormal>
<normal type="int">8</normal>
</generate>
</syntaxhighlight>

Valid subnodes of 'generate' are 'tangent', 'binormal' or 'normal'.
The integer value of these subnode is the index of the attribute
that will hold the value of the vec3 vector.

Normal is really redundant and should not be used, as that is already generated from loading the mesh.

The generate clause is located under PropertyList in the xml file.

In order to be available for the vertex shader, these data should
be bound to an attribute in the program clause, like this :

<syntaxhighlight lang="xml">
<program>
<vertex-shader>my_vertex_shader</vertex-shader>
<attribute>
<name>my_tangent_attribute</name>
<index>6</index>
</attribute>
<attribute>
<name>my_binormal_attribute</name>
<index>7</index>
</attribute>
</program>
</syntaxhighlight>

attribute names are whatever the shader use. The index is the one
declared in the 'generate' clause. So because generate/tangent has
value 6 and my_tangent_attribute has index 6, my_tangent_attribute
holds the tangent value for the vertex.

=== technique ===
A certain way of rendering this effect. Different pipelines typically have their own techniques.

==== scheme ====
Used by the [[Compositor]] to choose which implementation of an Effect to render. For example, if a Compositor scene pass specifies the <code>test-scheme</code> scheme, all techniques that use <code>test-scheme</code> will be used to render the pass. If an Effect doesn't contain a technique that implements this scheme, the object will be ignored and not rendered on that pass. Techniques with no scheme are considered ''default'' and will be used by scene passes when no explicit scheme has been provided.

==== predicate ====
A technique can contain a predicate that describes the OpenGL
functionality required to support the technique. The first
technique with a valid predicate in the list of techniques is used
to set up the graphics state of the effect. A technique with no
predicate is always assumed to be valid. The predicate is written in a
little expression language that supports the following primitives:

and, or, equal, less, less-equal
glversion - returns the version number of OpenGL
extension-supported - returns true if an OpenGL extension is supported
property - returns the boolean value of a property
float-property - returns the float value of a property, useful inside equal, less or less-equal nodes
shader-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 predicate
like 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>

</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.

Example:

<syntaxhighlight lang="xml">
<predicate>
<and>
<property>/sim/rendering/shaders/quality-level</property>
<property>/sim/rendering/shaders/model</property>
<or>
<less-equal>
<value type="float">2.0</value>
<glversion/>
</less-equal>
<and>
<extension-supported>GL_ARB_shader_objects</extension-supported>
<extension-supported>GL_ARB_shading_language_100</extension-supported>
<extension-supported>GL_ARB_vertex_shader</extension-supported>
<extension-supported>GL_ARB_fragment_shader</extension-supported>
</and>
</or>
</and>
</predicate>
</syntaxhighlight>

==== pass ====
A technique can consist of several passes. A pass is basically an Open
Scene Graph StateSet. Ultimately all OpenGL and OSG modes and state
attributes will be accessable in techniques. State attributes -- that
is, technique properties that have children and are not just boolean
modes -- have an <active> parameter which enables or disables the
attribute. In this way a technique can declare parameters it needs,
but not enable the attribute at all if it is not needed; the decision
can be based on a parameter in the parameters section of the
effect. For example, effects that support transparent and opaque
geometry could have as part of a technique:

<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 activated
using 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>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 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 values out 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.

===== lighting =====
true or false

===== material =====
children: active, ambient, ambient-front, ambient-back, diffuse,
diffuse-front, diffuse-back, specular, specular-front,
specular-back, emissive, emissive-front, emissive-back, shininess,
shininess-front, shininess-back, color-mode

===== blend =====
Children: active, source, destination, source-rgb, source-alpha, destination-rgb, destination-alpha

Children values: dst-alpha, dst-color, one, one-minus-dst-alpha, one-minus-dst-color, one-minus-src-alpha, one-minus-src-color, src-alpha, src-alpha-saturate, src-color, constant-color, one-minus-constant-color, constant-alpha, one-minus-constant-alpha, zero

Example:
<syntaxhighlight lang="xml">
<blend>
<active>true</active>
<source>one-minus-dst-alpha</source>
<destination>src-alpha-saturate</destination>
</blend>
</syntaxhighlight>

===== blend (simple) =====
A blend tag with 0 will do nothing.
A blend tag with 1 will do the same as source-alpha: one-minus-dst-alpha, in other words it will enable z transparency using alpha from the fragment shader.

Example:
<syntaxhighlight lang="xml">
<blend>1</blend>
</syntaxhighlight>

===== shade-model =====
flat or smooth

===== cull-face =====
front, back, front-back, off

===== texture-unit =====
unit: integer denoting which unit it is

image: the texture path

images: multiple texture paths

type: 2d, noise, cubemap, 3d (3d was added in 2020.1 and is used for layers of 2d textures defining a volumetric 3d texture)

filter: linear, linear-mipmap-linear, linear-mipmap-nearest", nearest, nearest-mipmap-linear, nearest-mipmap-nearest

mag-filter: linear, linear-mipmap-linear, linear-mipmap-nearest", nearest, nearest-mipmap-linear, nearest-mipmap-nearest

wrap: repeat, clamp-to-edge, clamp-to-border, clamp, mirror

internal-format: normalized

environment: mode, color
:mode: add,blend,decal,modulate,replace
:color: rgba

texenv-combine: replace, modulate, add, add-signed, interpolate, subtract, dot3-rgb, dot3-rgba

texenv-combine: combine-rgb, combine-alpha, source0-rgb, source1-rgb, source2-rgb, source0-alpha, source1-alpha,source2-alpha,operand0-rgb,operand1-rgb,operand2-rgb,operand0-alpha,operand1-alpha,operand2-alpha,scale-rgb,scale-alpha

point-sprite: true, false

mipmap-control functions: auto, average, sum, product, min, max

texgen:
:mode: object-linear, eye-linear, sphere-map, normal-map, reflection-map
:planes: s, t, r, q as doubles

Example:

<syntaxhighlight lang="xml">
<texture-unit>
<unit>3</unit>
<image>Textures/Terrain/void.png</image>
<type>2d</type>
<filter>linear-mipmap-linear</filter>
<mag-filter>linear-mipmap-linear</mag-filter>
<wrap-s>repeat</wrap-s>
<wrap-t>repeat</wrap-t>
<wrap-r>repeat</wrap-r>
<internal-format>normalized</internal-format>
<mipmap-control>
<function-r>average</function-r>
<function-g>min</function-g>
<function-b>sum</function-b>
<function-a>product</function-a>
</mipmap-control>
<environment>
<mode>decal</mode>
<color>0.0 0.1 0.6 1.0</color>
</environment>
<point-sprite>true</point-sprite>
<texenv-combine>operand0-rgb</texenv-combine>
<texgen>
<mode>S</mode>
<planes>0.075, 0.0, 0.0, 0.5</planes>
</texgen>
</texture-unit>
</syntaxhighlight>

Textures of type 3d has to be packed on the x axis. Here is an example: [https://raw.githubusercontent.com/sebh/TileableVolumeNoise/master/Examples/noiseErosionPacked.jpg noiseErosionPacked.jpg]

===== vertex-program-two-side =====
true or false

===== polygon-mode =====
children: front, back

Valid values: fill, line, point

===== vertex-program-point-size =====
true, false

===== uniform =====
Data accessible by shaders.

name: the name

type: bool, int, float, float-vec3, float-vec4, sampler-1d, sampler-2d, sampler-3d, sampler-1d-shadow, sampler-2d-shadow, sampler-cube

===== alpha-test =====

active: true, false

comparison: never, less, equal, lequal, greater, notequal, gequal, always

reference: 0 to 1

===== render-bin =====
Sent to OSG.

bin-number: This is an integer defining the order stuff will be rendered in, it can be negative also.

bin-name: RenderBin, DepthSortedBin

===== rendering-hint =====
Sent to OSG.

default, opaque, transparent

This basically just sets Renderbin:

opaque = bin 10, depthsortedbin

transparent = bin 0, renderbin

default = inherit renderbin details from parent node

===== depth =====

* function: Specifies the depth comparison function. Equivalent to [https://registry.khronos.org/OpenGL-Refpages/gl4/html/glDepthFunc.xhtml <tt>glDepthFunc</tt>].
* near, far: Specify the mapping of depth values from normalized device coordinates to window coordinates. Equivalent to [https://registry.khronos.org/OpenGL-Refpages/gl4/html/glDepthRange.xhtml <tt>glDepthRange</tt>]
* write-mask: Whether to write to the depth buffer or not.
* enabled: Whether depth testing is enabled or not.

===== program =====
* vertex-shader
* geometry-shader
* fragment-shader
* attribute
* geometry-vertices-out: integer, max number of vertices emitted by geometry shader
* geometry-input-type: points, lines, lines-adjacency, triangles, triangles-adjacency
* geometry-output-type: points, line-strip, triangle-strip
* uniform-block-binding: has name and index (since 2020.1)

example:

<syntaxhighlight lang="xml">
<program>
<vertex-shader n="0">Shaders/lcd.vert</vertex-shader>
<fragment-shader n="0">Shaders/lcd.frag</fragment-shader>
<fragment-shader n="1">Shaders/noise.frag</fragment-shader>
<fragment-shader n="2">Shaders/filters-ALS.frag</fragment-shader>
</program>
</syntaxhighlight>

example for clustered lightning in compositor:

<syntaxhighlight lang="xml">
<program>
<vertex-shader n="0">Shaders/lcd.vert</vertex-shader>
<fragment-shader n="0">Shaders/lcd.frag</fragment-shader>
<fragment-shader n="1">Shaders/noise.frag</fragment-shader>
<fragment-shader n="2">Shaders/filters-ALS.frag</fragment-shader>
<fragment-shader n="3">Shaders/ALS/clustered-include.frag</fragment-shader>
<uniform-block-binding>
<name>PointLightBlock</name>
<index>5</index>
</uniform-block-binding>
<uniform-block-binding>
<name>SpotLightBlock</name>
<index>6</index>
</uniform-block-binding>
</program>
</syntaxhighlight>

See this page for more about shaders: [[Howto:Shader programming in FlightGear]]

== Uniforms passed to shaders outside the XML effect framework ==

{| class="wikitable"
!Name
!Type
!Purpose
|-
|<tt>fg_ViewMatrix</tt>
|<tt>mat4</tt>
|In fullscreen pass only, view matrix used to transform from world to view space. Same as osg_ViewMatrix, but for fullscreen pass.
|-
|<tt>fg_ViewMatrixInverse</tt>
|<tt>mat4</tt>
|In fullscreen pass only, view matrix inverse used to transform from view to world space. Same as osg_ViewMatrixInverse but for fullscreen pass.
|-
|<tt>fg_ProjectionMatrixInverse</tt>
|<tt>mat4</tt>
|In fullscreen pass only, projection matrix inverse
|-
|<tt>fg_CameraPositionCart</tt>
|<tt>vec3</tt>
|Position of the camera in world space, expressed in cartesian coordinates
|-
|<tt>fg_CameraPositionGeod</tt>
|<tt>vec3</tt>
|Position of the camera in world space, expressed in geodesic coordinates (longitude in radians, latitude in radians, elevation in meters)
|-
|<tt>fg_SunAmbientColor</tt>
|<tt>vec4</tt>
|For fullscreen pass only, sun information as lightsource[0] is not available in fullscreen pass.
|-
|<tt>fg_SunDiffuseColor</tt>
|<tt>vec4</tt>
|For fullscreen pass only, sun information as lightsource[0] is not available in fullscreen pass.
|-
|<tt>fg_SunSpecularColor</tt>
|<tt>vec4</tt>
|For fullscreen pass only, sun information as lightsource[0] is not available in fullscreen pass.
|-
|<tt>fg_SunDirection</tt>
|<tt>vec3</tt>
|For fullscreen pass only, sun information as lightsource[0] is not available in fullscreen pass.
|-
|<tt>fg_FogColor</tt>
|<tt>vec4</tt>
|
|-
|<tt>fg_FogDensity</tt>
|<tt>float</tt>
|
|-
|<tt>fg_ShadowNumber</tt>
|<tt>int</tt>
|
|-
|<tt>fg_ShadowDistances</tt>
|<tt>vec4</tt>
|
|-
|<tt>fg_DepthInColor</tt>
|<tt>bool</tt>
|Tells if the depth is stored in a depth texture or a color texture
|-
|<tt>fg_Planes</tt>
|<tt>vec3</tt>
|Used to convert the value of the depth buffer to a depth that can be used to compute the eye space position of the fragment
|-
|<tt>fg_BufferSize</tt>
|<tt>vec2</tt>
|Dimensions of the buffer, used to convert gl_FragCoord into the range [0..1][0..1]
|-
|<tt>osg_ViewMatrix</tt>
|<tt>mat4</tt>
|Defined by OSG, used only when working on actual geometry. Transforms from world to view space.
|-
|<tt>osg_ViewMatrixInverse</tt>
|<tt>mat4</tt>
|Defined by OSG, used only when working on actual geometry. Transforms from view to world space.
|-
|<tt>osg_SimulationTime</tt>
|<tt>float</tt>
|Defined by OSG
|-
|<tt>osg_FrameTime</tt>
|<tt>float</tt>
|Defined by OSG
|-
|<tt>osg_DeltaFrameTime</tt>
|<tt>float</tt>
|Defined by OSG
|-
|<tt>osg_FrameTime</tt>
|<tt>float</tt>
|Defined by OSG
|-
|<tt>osg_FrameNumber</tt>
|<tt>int</tt>
|Defined by OSG
|}

== Related content ==
=== Forum topics ===
* {{forum link|t=37364|title=Application of effects}} - Testing which kind of groups an effect can be applied to and when

[[Category:Shader development]]

GlTF

2023-04-24T02:48:24Z

Icecode:

'''glTF''' (derivative short form of '''Graphics Language Transmission Format''' or '''GL Transmission Format''') is a standard file format for three-dimensional scenes and models. A glTF file uses one of two possible file extensions, .gltf (JSON/ASCII) or .glb (binary). See the [https://en.wikipedia.org/wiki/GlTF Wikipedia article] on the subject for more information. In FlightGear glTF can be used in place of the [[AC3D file format]] to load 3D models.

== glTF vs. AC3D ==

glTF does not deprecate the AC3D file format as both can be used interchangeably, although each one has its own advantages and disadvantages. Choosing which one to use for your project will depend on your requirements.

The main advantage of glTF is that PBR materials are handled automatically. glTF files contain PBR material information that is used by FlightGear to avoid messing with [[Effects]] manually like in the case of AC3D files. This allows 3D models to have a consistent look across all software, i.e. what you see in [[Blender]] is exactly what you will see in FlightGear. However, this advantage can also be a disadvantage. The glTF specification is quite specific about how a material is defined, so it's not possible to add custom Effects to glTF models. If your project uses custom shaders or requires special effects that cannot be handled by the standard PBR scheme (albedo/metalness/roughness), then you should be using AC3D files with custom Effects.

== Unsupported Features ==

The [https://github.com/KhronosGroup/glTF/tree/master/specification/2.0 glTF 2.0 specification] is the best resource when it comes to glTF. All parameters and their default values are very well defined. FlightGear tries to adhere to the specification as much as possible, but there are some exceptions:

* Embedded textures are not loaded, so all textures must be saved to external files.
* All parameters related to animations are ignored. This includes skinning information like joints and weights, as well as the animation keyframes themselves. FlightGear provides its own system for animating objects, see [[Howto:Animate models]].
* Instanced geometry is not supported.
* Cameras and punctual lights are not supported.
* When no material has been specified for a mesh, the glTF spec suggests using a 50% emissive grey material. FlightGear uses a different default material, which is specified in {{fgdata file|Effects/model-pbr.eff}}.

== Usage notes for content developers ==

In XML you can treat glTF models the same way you treat AC3D, with a few exceptions. As described earlier, Effects can't be assigned to glTF models because they use a predefined Effect that implements the material description of the glTF specification. [[Howto:Animate models#Material animation|Material animations]] don't work either for the same reason. If you want to change the material parameters, you should do so in your 3D modelling software of choice (or manually editing the glTF file).

=== Blender ===

[[File:Blender glTF export menu.png|thumb|Blender glTF exporter menu location.]]
[[File:Blender glTF exporter example settings.png|thumb|Example settings for exporting a glTF model in Blender.]]

The latest versions of Blender support glTF out of the box. You need to use a Principled BSDF to setup your materials so they can displayed correctly by FlightGear. All textures attached to this node will also be exported correctly. See the [https://docs.blender.org/manual/en/2.80/addons/io_scene_gltf2.html reference documentation] in the Blender manual for more information about Blender and glTF.

Some important settings for the exporter include:

; Format
: <tt>glTF Separate (.gltf + .bin + textures)</tt> has to be selected because FlightGear does not support loading embedded assets.
; Textures
: Optional directory where textures will be placed. If none is selected, the textures will be in the same directory as the <tt>.gltf</tt> file.
; Limit to
: These parameters can be used to select which objects of your Blender scene will be exported.
; Data
: FlightGear does not support glTF cameras or punctual light sources, so you can disable eveything here.
; +Y up
: Make sure to keep this '''OFF'''. Blender uses a +Z up convention like FlightGear, so we do not adhere to the glTF standard (+Y up).
; Apply Modifiers
: If you have any unapplied modifiers (like a Subdivision Surface Modifier), they will applied before exporting.
; UVs
: Whether to export UV texture coordinates or not. You should keep this '''ON'''.
; Normals
: Whether to export normals or not. You should keep this '''ON''' as disabling them will force FlightGear to calculate them at runtime.
; Tangents
: Whether to export the tangent vectors or not. You should keep this '''OFF''' as FlightGear will calculate the tangent and binormal vectors at runtime anyway.
; Vertex Colors
: Whether to export the vertex colors or not. FlightGear will use the PBR information of the Principled BSDF to light the model, so vertex colors will be ignored by most Compositor pipelines. You can keep this '''OFF''' in most cases.
; Attributes
: You can keep this '''OFF'''.
; Materials
: Whether to export materials or not. You should keep this on <tt>Export</tt>.
; Images
: <tt>Automatic</tt> will automatically choose between PNG and JPEG when saving textures. <tt>JPEG format (.jpg)</tt> will force saving as JPEG for every texture. In general JPEG provides a decent save in storage space at the cost of a negligible quality loss, so you should be using JPEG whenever possible (transparency requires PNG). Keep in mind that JPEG textures are lossy though, so you might want to keep a lossless copy for development purposes in PNG or XCF format.
; PBR Extensions
: You can keep this '''OFF'''.
; Lighting
: Does not matter what you choose here as FlightGear completely ignores glTF lights.
; Animation
: Disable everything here as FlightGear completely ignores glTF animations.

== Related content ==

* [[HDR Pipeline]]
* [[AC3D file format]]