Changes

Jump to: navigation, search

Howto:Shader programming in FlightGear

851 bytes added, 00:59, 13 October 2014
no edit summary
{{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
visibleColor.rgb /= objectColor.rgb /* light.rgb /+ objectEmissive.rgb
Now, we have textures and so we get
visibleColor.rgb = objectColor.rgb * texel.rgb * light.rgb + objectEmissive.rgb + lightMapTexel.rgb
Since we can have the full color information in the texture, objectColor.rgb is usually (1.0,1.0,1.0) because the info is redundant. But if you don't use a texture, of course objectColor.rgb has the actual color value (incidentially, I think we shouldn't texture with monochromatic surfaces at all, it creates a jarring visual impression which can be cured by using even a small texture...)
 
But if you do, the rendering pipeline is set up to compute color.rgb = objectColor * light.rgb in the vertex shader, so the equation we have in the fragment shader is something like
 
visibleColor.rgb = color.rgb * texel.rgb + objectEmissive.rgb + lightMapTexel.rgb
 
and if we add a secondary light like
 
visibleColor.rgb = (color.rgb + secLight.rgb) * texel.rgb
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.
256
edits

Navigation menu