Changes

Jump to: navigation, search

Howto:Shader programming in FlightGear

3,304 bytes added, 00:35, 13 October 2014
added some cquotes
== General Comments from Forum Discussion ==
 
{{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.
 
So, the lighting equation in tree-haze.frag is indeed
vec4 fragColor = vec4 (gl_Color.xyz,1.0) * texel;
and your change to the light should happen just before that. But you can't do
gl_Color.rgb = gl_Color.rgb + my_light;
because gl_Color.rgb is a varying variable type, and you can't assign new values to them inside the shader, so you need to either make a new variable or just do
vec4 fragColor = vec4 ((gl_Color.rgb + my_light),1.0) * texel;
(note that color.rgb is the same as color.xyz, GLSL doesn't really care which convention you use, but I took a few months to learn that, so early code by myself often uses xyz indexing convention for color vectors as well).<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24226&start=15#p220075
|title=ALS landing lights
|author=Thorsten Renk |date= Tue Oct 07, 2014 12:04 -0700}}</ref>|Thorsten Renk}}
{{cquote|An effect is a container for a series of techniques which are all the possible things you could do with some object.
|title=ALS landing lights
|author=Thorsten Renk |date= Wed Oct 08, 2014 1:58 -0700}}</ref>|Thorsten Renk}}
 
{{cquote|At low water shader quality, water isn't rendered separately from the terrain, i.e. it runs via terrain-default.eff - since you modified that to allow light, light works for water out of the box.
At high water slider, the techniques in water.eff kick in, and only then do you need to modify the specific water shader code. Now, the peculiar thing about water is that there are two effects (water.eff and water_inland.eff) sharing the same shader code (but calling it with somewhat different parameters). So the function not found error was presumably caused by you modifying water.eff whereas the water you were seeing was initiated by water_inland.eff, and in that effect, the secondary_lights.frag wasn't initially in the program section. So if you alter the water shader code, you need to modify two effect files rather than one to pass the right parameters and access the functions you need.
 
..........
..........
 
Adding them _after_ fogging, isn't what you want - you'll see that if visibility is <100 m, everything will go black at night, because fog color is black at night, so finalColor.rgb of a heavily fogged object will also be black, and then when you light it up, you multiply your light value with black and it'll be black. Or, if you add the light value (which you should only do if the object you add it to is a light color itself), then you'll get a featureless grey. You want to add light after texel color and before fogging.<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24226&start=30#p220216
|title=ALS landing lights
|author=Thorsten Renk |date= Wed Oct 08, 2014 11:19 -0700}}</ref>|Thorsten Renk}}
 
 
<references/>
{{WIP|more to follow}}
266
edits

Navigation menu