Jump to: navigation, search

Howto:Shader programming in FlightGear

1,097 bytes added, 00:53, 13 October 2014
no edit summary
{{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* lighting - how is this color changed by the light falling onto that pixel, usually the relation is something like fragColor = texel*light* fogging - how much is the color hidden by haze, usually the relation is something like gl_FragColor = mix(fragColor, hazeColor, transmission_factor);* 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.
|title=ALS landing lights
|author=Thorsten Renk |date= Wed Oct 08, 2014 11:19 -0700}}</ref>|Thorsten Renk}}
{{cquote|So, in old times when rendering textures was slow and complicated, we rendered objects with monochromatic surface colors. Then the (schematic) lighting equation (without specular, and the sum of ambient and diffuse already computed) was
it of course can never recover the color information, because color.rgb is zero at night since you multiplied the actual color with zero sunlight and the texel doesn't carry information for an untextured object.
Since the secondary light is in screen coordinates, it can't appear in the vertex shader, so the solution would be to pass the actual color and light rather than their product to the fragment shader. Which is expensive, because we need another varying vec3, and varying variable types fill memory and need to be computed an interpolated per vertex/per fragment - which is why I'm not sure whether we shouldn't accept the loss of the color...<ref>{{cite web |url=
|title=ALS landing lights
|author=Thorsten Renk |date= Sat Oct 11, 2014 1:28 -0700}}</ref>|Thorsten Renk}}

Navigation menu