574
edits
Howto:Shader programming in FlightGear: Difference between revisions
Jump to navigation
Jump to search
m
Howto:Shader programming in FlightGear (view source)
Revision as of 20:56, 1 September 2019
, 1 September 2019→Effects file: added link to new page
(→Practical application in FlightGear: Heading hack) |
m (→Effects file: added link to new page) |
||
| (7 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
{{forum|47|Effects & Shaders}} | {{forum|47|Effects & Shaders}} | ||
{{Rendering}} | |||
<!-- | |||
{{WIP|More to follow}} | {{WIP|More to follow}} | ||
--> | |||
This is meant to become an introduction to '''shader programming in FlightGear''', for the time being (03/2010), this is work in progress, please feel free to ask questions or suggest topics. | This is meant to become an introduction to '''shader programming in FlightGear''', for the time being (03/2010), this is work in progress, please feel free to ask questions or suggest topics. | ||
| Line 65: | Line 67: | ||
User defined functions are supported, and a wide variety of commonly used functions are provided built-in as well. This allows the graphics card manufacturer the ability to optimize these built-in functions at the hardware level if they are inclined to do so. Many of these functions are similar to those found in the math library of the C programming language such as <code>exp()</code> and <code>abs()</code> while others are specific to graphics programming such as <code>smoothstep()</code> and <code>texture2D()</code>. | User defined functions are supported, and a wide variety of commonly used functions are provided built-in as well. This allows the graphics card manufacturer the ability to optimize these built-in functions at the hardware level if they are inclined to do so. Many of these functions are similar to those found in the math library of the C programming language such as <code>exp()</code> and <code>abs()</code> while others are specific to graphics programming such as <code>smoothstep()</code> and <code>texture2D()</code>. | ||
== Error Reports, Debugging, Troubleshooting == | |||
Shaders are compiled at FG startup. | |||
Shader compilation errors can be found in the fgfs.log file. More about the [[Commonly_used_debugging_tools#fgfs.log|fgfs.log here]]. | |||
As of FG 2016.4.4, shaders do not seem to recompile upon Debug/Reload Aircraft Model or File/Reset. So the only option to re-compile/test a shader is to quit a re-start FG altogether. | |||
== Shader types == | == Shader types == | ||
| Line 78: | Line 88: | ||
In FlightGear, these files can be found in the <code>Shaders</code> subdirectory of the base package, in essence <code>$FG_ROOT/Shaders</code>. | In FlightGear, these files can be found in the <code>Shaders</code> subdirectory of the base package, in essence <code>$FG_ROOT/Shaders</code>. | ||
For a list of currently available shaders, you may want to take a look at: | For a list of currently available shaders, you may want to take a look at: {{fg root file|Shaders}}. | ||
So, shaders generally go around in pairs - one shader (the ''vertex shader'') is a short program that takes in one vertex from the main CPU and produces one vertex that is passed on to the GPU rasterizer which uses the vertices to create triangles - which it then chops up into individual pixel-sized fragments. | So, shaders generally go around in pairs - one shader (the ''vertex shader'') is a short program that takes in one vertex from the main CPU and produces one vertex that is passed on to the GPU rasterizer which uses the vertices to create triangles - which it then chops up into individual pixel-sized fragments. | ||
| Line 86: | Line 96: | ||
=== Vertex shaders === | === Vertex shaders === | ||
{{FGCquote | |||
|The vertex shader doesn't know anything about the mesh it renders, it just knows one single vertex at a time and all the info that is attached to the vertex (normals, tangents, binormals, color,...) And the vertex shader doesn't really draw anything, it just takes care of all the things which have to do with 'where in space' you are. | |||
The way this works is that for all the vertices of an object you want to render, the position of the object gets attached to all vertices (currently in the color spot). The vertex shader then just adds the offset vector to the vertex coordinate with respect to the origin. | |||
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32326487/ | |||
|title=<nowiki>Re: [Flightgear-devel] cities in FG & how to move forward</nowiki> | |||
|author=<nowiki>Renk Thorsten</nowiki> | |||
|date=<nowiki>2014-05-11</nowiki> | |||
}} | |||
}} | |||
{| class="wikitable" | {| class="wikitable" | ||
! Input | ! Input | ||
| Line 144: | Line 164: | ||
=== Fragment shaders === | === Fragment shaders === | ||
{{FGCquote | |||
|the fragment shader basically knows only the pixel it is about to render and whatever information is passed from the vertex shader. Based on 'where' the vertex shader says the pixel is, the rasterizer stage determines what the texture for the pixel should be. | |||
But there are techniques to do this in a different way, for instance the water depth map uses world coordinates to look up a world texture, and the gardens would have to be drawn in a similar way. | |||
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32326487/ | |||
|title=<nowiki>Re: [Flightgear-devel] cities in FG & how to move forward</nowiki> | |||
|author=<nowiki>Renk Thorsten</nowiki> | |||
|date=<nowiki>2014-05-11</nowiki> | |||
}} | |||
}} | |||
{| class="wikitable" | {| class="wikitable" | ||
! Input | ! Input | ||
| Line 413: | Line 443: | ||
=== Effects file === | === Effects file === | ||
The effects file is the mechanism we use to combine and manipulate all the necessary data to create stunning visual effects. It's the link between the data contained and produced in Nasal, XML and the property tree and the graphics rendering pipeline. It's there to allow us to create these affects without having to know or use the C++ code base. Its flexible framework allows for an almost infinite range of sophisticated effects. | The effects file is the mechanism we use to combine and manipulate all the necessary data to create stunning visual effects. It's the link between the data contained and produced in Nasal, XML and the property tree and the graphics rendering pipeline. It's there to allow us to create these affects without having to know or use the C++ code base. Its flexible framework allows for an almost infinite range of sophisticated effects. | ||
See this page for more details: [[Effect Framework]] | |||
==== Parameters ==== | ==== Parameters ==== | ||