Howto:Shader programming in FlightGear: Difference between revisions

m
m (→‎A Practical Application in Flightgear: +syntax highlighting and formatting)
Line 703: Line 703:
{{cquote|In principle, we always do the same steps in the fragment shaders to determine the color of a pixel:
{{cquote|In principle, we always do the same steps in the fragment shaders to determine the color of a pixel:


texel color - what is the base color of the pixel fully lit and unfogged
* texel color - what is the base color of the pixel fully lit and unfogged
lighting - how is this color changed by the light falling onto that pixel, usually the relation is something like fragColor equals texel * light
* lighting - how is this color changed by the light falling onto that pixel, usually the relation is something like fragColor equals texel * light
fogging - how much is the color hidden by haze, usually the relation is something like gl_FragColor equals mix(fragColor, hazeColor, transmission_factor);
* fogging - how much is the color hidden by haze, usually the relation is something like gl_FragColor equals mix(fragColor, hazeColor, transmission_factor);
what is displayed on the screen in the end is whatever gl_FragColor is set to
what is displayed on the screen in the end is whatever gl_FragColor is set to
But the location where this happens isn't always obvious - often (part) of the light is computed in the vertex shader already, in which case it typically enters the fragment shader as gl_Color.
But the location where this happens isn't always obvious - often (part) of the light is computed in the vertex shader already, in which case it typically enters the fragment shader as gl_Color.