[692] | 1 | <HTML> |
---|
| 2 | <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
---|
| 3 | <!-- Created on , 12 2006 by texi2html 1.64 --> |
---|
| 4 | <!-- |
---|
| 5 | Written by: Lionel Cons <Lionel.Cons@cern.ch> (original author) |
---|
| 6 | Karl Berry <karl@freefriends.org> |
---|
| 7 | Olaf Bachmann <obachman@mathematik.uni-kl.de> |
---|
| 8 | and many others. |
---|
| 9 | Maintained by: Olaf Bachmann <obachman@mathematik.uni-kl.de> |
---|
| 10 | Send bugs and suggestions to <texi2html@mathematik.uni-kl.de> |
---|
| 11 | |
---|
| 12 | --> |
---|
| 13 | <HEAD> |
---|
| 14 | <TITLE>OGRE Manual v1.2.0 ('Dagon'): Additive Light Masking</TITLE> |
---|
| 15 | |
---|
| 16 | <META NAME="description" CONTENT="OGRE Manual v1.2.0 ('Dagon'): Additive Light Masking"> |
---|
| 17 | <META NAME="keywords" CONTENT="OGRE Manual v1.2.0 ('Dagon'): Additive Light Masking"> |
---|
| 18 | <META NAME="resource-type" CONTENT="document"> |
---|
| 19 | <META NAME="distribution" CONTENT="global"> |
---|
| 20 | <META NAME="Generator" CONTENT="texi2html 1.64"> |
---|
| 21 | <LINK TYPE="text/css" rel="stylesheet" href="../style.css"> |
---|
| 22 | </HEAD> |
---|
| 23 | |
---|
| 24 | <BODY LANG="" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080" ALINK="#FF0000"> |
---|
| 25 | |
---|
| 26 | <A NAME="SEC293"></A> |
---|
| 27 | <TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0> |
---|
| 28 | <TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_65.html#SEC291"> < </A>]</TD> |
---|
| 29 | <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_62.html#SEC270"> Up </A>]</TD> |
---|
| 30 | <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_67.html#SEC296"> > </A>]</TD> |
---|
| 31 | <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="index.html#SEC_Top">Top</A>]</TD> |
---|
| 32 | <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_toc.html#SEC_Contents">Contents</A>]</TD> |
---|
| 33 | <TD VALIGN="MIDDLE" ALIGN="LEFT">[Index]</TD> |
---|
| 34 | <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_abt.html#SEC_About"> ? </A>]</TD> |
---|
| 35 | </TR></TABLE> |
---|
| 36 | <HR SIZE=1> |
---|
| 37 | <H2> 7.4 Additive Light Masking </H2> |
---|
| 38 | <!--docid::SEC293::--> |
---|
| 39 | Additive light masking is about rendering the scene many times, each time representing a single light contribution whose influence is masked out in areas of shadow. Each pass is combined with (added to) the previous one such that when all the passes are complete, all the light contribution has correctly accumulated in the scene, and each light has been prevented from affecting areas which it should not be able to because of shadow casters. This is an effective technique which results in very realistic looking lighting, but it comes at a price: more rendering passes.<BR><BR> |
---|
| 40 | <P> |
---|
| 41 | |
---|
| 42 | As many technical papers (and game marketing) will tell you, rendering realistic lighting like this requires multiple passes. Being a friendly sort of engine, Ogre frees you from most of the hard work though, and will let you use the exact same material definitions whether you use this lighting technique or not (for the most part, see <A HREF="manual_66.html#SEC294">Pass Classification and Vertex Programs</A>). In order to do this technique, Ogre automatically categorises the <A HREF="manual_16.html#SEC35">3.1.2 Passes</A> you define in your materials into 3 types: |
---|
| 43 | <OL> |
---|
| 44 | <LI>ambient |
---|
| 45 | Passes categorised as 'ambient' include any base pass which is not lit by any particular light, i.e. it occurs even if there is no ambient light in the scene. The ambient pass always happens first, and sets up the initial depth value of the fragments, and the ambient colour if applicable. It also includes any emissive / self illumination contribution. No textures are rendered in this pass. |
---|
| 46 | <LI>diffuse/specular |
---|
| 47 | Passes categorised as 'diffuse/specular' (or 'per-light') are rendered once per light, and each pass contributes the diffuse ans specular colour from that single light as reflected by the diffuse / specular terms in the pass. Areas in shadow from that light are masked and are thus not updated. The resulting masked colour is added to the exisiting colour in the scene. Again, no textures are used in this pass (except for textures used for lighting calculations such as normal maps). |
---|
| 48 | <LI>decal |
---|
| 49 | Passes categorised as 'decal' add the final texture colour to the scene, which is modulated by the accumulated light built up from all the ambient and diffuse/specular passes. |
---|
| 50 | </OL> |
---|
| 51 | <P> |
---|
| 52 | |
---|
| 53 | In practice, <A HREF="manual_16.html#SEC35">3.1.2 Passes</A> rarely fall nicely into just one of these categories. For each Technique, Ogre compiles a list of 'Illumination Passes', which are derived from the user defined passes, but can be split, to ensure that the divisions between illumination pass categories can be maintained. For example, if we take a very simple material definition: |
---|
| 54 | <TABLE><tr><td> </td><td class=example><pre>material TestIllumination |
---|
| 55 | { |
---|
| 56 | technique |
---|
| 57 | { |
---|
| 58 | pass |
---|
| 59 | { |
---|
| 60 | ambient 0.5 0.2 0.2 |
---|
| 61 | diffuse 1 0 0 |
---|
| 62 | specular 1 0.8 0.8 15 |
---|
| 63 | texture_unit |
---|
| 64 | { |
---|
| 65 | texture grass.png |
---|
| 66 | } |
---|
| 67 | } |
---|
| 68 | } |
---|
| 69 | } |
---|
| 70 | </pre></td></tr></table></P><P> |
---|
| 71 | |
---|
| 72 | Ogre will split this into 3 illumination passes, which will be the equivalent of this: |
---|
| 73 | <TABLE><tr><td> </td><td class=example><pre>material TestIlluminationSplitIllumination |
---|
| 74 | { |
---|
| 75 | technique |
---|
| 76 | { |
---|
| 77 | // Ambient pass |
---|
| 78 | pass |
---|
| 79 | { |
---|
| 80 | ambient 0.5 0.2 0.2 |
---|
| 81 | diffuse 0 0 0 |
---|
| 82 | specular 0 0 0 |
---|
| 83 | } |
---|
| 84 | |
---|
| 85 | // Diffuse / specular pass |
---|
| 86 | pass |
---|
| 87 | { |
---|
| 88 | scene_blend add |
---|
| 89 | iteration once_per_light |
---|
| 90 | diffuse 1 0 0 |
---|
| 91 | specular 1 0.8 0.8 15 |
---|
| 92 | } |
---|
| 93 | |
---|
| 94 | // Decal pass |
---|
| 95 | pass |
---|
| 96 | { |
---|
| 97 | scene_blend modulate |
---|
| 98 | lighting off |
---|
| 99 | texture_unit |
---|
| 100 | { |
---|
| 101 | texture grass.png |
---|
| 102 | } |
---|
| 103 | } |
---|
| 104 | } |
---|
| 105 | } |
---|
| 106 | </pre></td></tr></table>So as you can see, even a simple material requires a minimum of 3 passes when using this shadow technique, and in fact it requires (num_lights + 2) passes in the general sense. You can use more passes in your original material and Ogre will cope with that too, but be aware that each pass may turn into multiple ones if it uses more than one type of light contribution (ambient vs diffuse/specular) and / or has texture units. The main nice thing is that you get the full multipass lighting behaviour even if you don't define your materials in terms of it, meaning that your material definitions can remain the same no matter what lighting approach you decide to use.<BR><BR> |
---|
| 107 | </P><P> |
---|
| 108 | |
---|
| 109 | <A NAME="Pass Classification and Vertex Programs"></A> |
---|
| 110 | <A NAME="SEC294"></A> |
---|
| 111 | <H3> Pass Classification and Vertex Programs </H3> |
---|
| 112 | <!--docid::SEC294::--> |
---|
| 113 | Ogre is pretty good at classifying and splitting your passes to ensure that the multipass rendering approach required by additive lighting works correctly without you having to change your material definitions. However, there is one exception; when you use vertex programs, the normal lighting attributes ambient, diffuse, specular etc are not used, becuase all of that is determined by the vertex program. Ogre has no way of knowing what you're doing inside that vertex program, so you have to tell it.<BR><BR> |
---|
| 114 | <P> |
---|
| 115 | |
---|
| 116 | In practice this is very easy. Even though your vertex program could be doing a lot of complex, highly customised processing, it can still be classified into one of the 3 types listed above. All you need to do to tell Ogre what you're doing is to use the pass attributes ambient, diffuse, specular and self_illumination, just as if you were not using a vertex program. Sure, these attributes do nothing (as far as rendering is concerned) when you're using vertex programs, but it's the easiest way to indicate to Ogre which light components you're using in your vertex program. Ogre will then classify and potentially split your programmable pass based on this information - it will leave the vertex program as-is (so that any split passes will respect any vertex modification that is being done). <BR><BR> |
---|
| 117 | </P><P> |
---|
| 118 | |
---|
| 119 | Note that when classifying a diffuse/specular programmable pass, Ogre checks to see whether you have indicated the pass can be run once per light (iteration once_per_light). If so, the pass is left intact, including it's vertex and fragment programs. However, if this attribute is not included in the pass, Ogre tries to split off the per-light part, and in doing so it will disable the fragment program, since in the absence of the 'iteration once_per_light' attribute it can only assume that the fragment program is performing decal work and hence must not be used per light.<BR><BR> |
---|
| 120 | </P><P> |
---|
| 121 | |
---|
| 122 | So clearly, when you use additive light masking as a shadow technique, you need to make sure that programmable passes you use are properly set up so that they can be classified correctly. However, also note that the changes you have to make to ensure the classification is correct does not affect the way the material renders when you choose not to use additive lighting, so the principle that you should be able to use the same material definitions for all lighting scenarios still holds. Here is an example of a programmable material which will be classified correctly by the illumination pass classifier: |
---|
| 123 | <TABLE><tr><td> </td><td class=example><pre>// Per-pixel normal mapping Any number of lights, diffuse and specular |
---|
| 124 | material Examples/BumpMapping/MultiLightSpecular |
---|
| 125 | { |
---|
| 126 | |
---|
| 127 | technique |
---|
| 128 | { |
---|
| 129 | // Base ambient pass |
---|
| 130 | pass |
---|
| 131 | { |
---|
| 132 | // ambient only, not needed for rendering, but as information |
---|
| 133 | // to lighting pass categorisation routine |
---|
| 134 | ambient 1 1 1 |
---|
| 135 | diffuse 0 0 0 |
---|
| 136 | specular 0 0 0 0 |
---|
| 137 | // Really basic vertex program |
---|
| 138 | vertex_program_ref Ogre/BasicVertexPrograms/AmbientOneTexture |
---|
| 139 | { |
---|
| 140 | param_named_auto worldViewProj worldviewproj_matrix |
---|
| 141 | param_named_auto ambient ambient_light_colour |
---|
| 142 | } |
---|
| 143 | |
---|
| 144 | } |
---|
| 145 | // Now do the lighting pass |
---|
| 146 | // NB we don't do decal texture here because this is repeated per light |
---|
| 147 | pass |
---|
| 148 | { |
---|
| 149 | // set ambient off, not needed for rendering, but as information |
---|
| 150 | // to lighting pass categorisation routine |
---|
| 151 | ambient 0 0 0 |
---|
| 152 | // do this for each light |
---|
| 153 | iteration once_per_light |
---|
| 154 | |
---|
| 155 | |
---|
| 156 | scene_blend add |
---|
| 157 | |
---|
| 158 | // Vertex program reference |
---|
| 159 | vertex_program_ref Examples/BumpMapVPSpecular |
---|
| 160 | { |
---|
| 161 | param_named_auto lightPosition light_position_object_space 0 |
---|
| 162 | param_named_auto eyePosition camera_position_object_space |
---|
| 163 | param_named_auto worldViewProj worldviewproj_matrix |
---|
| 164 | } |
---|
| 165 | |
---|
| 166 | // Fragment program |
---|
| 167 | fragment_program_ref Examples/BumpMapFPSpecular |
---|
| 168 | { |
---|
| 169 | param_named_auto lightDiffuse light_diffuse_colour 0 |
---|
| 170 | param_named_auto lightSpecular light_specular_colour 0 |
---|
| 171 | } |
---|
| 172 | |
---|
| 173 | // Base bump map |
---|
| 174 | texture_unit |
---|
| 175 | { |
---|
| 176 | texture NMBumpsOut.png |
---|
| 177 | colour_op replace |
---|
| 178 | } |
---|
| 179 | // Normalisation cube map |
---|
| 180 | texture_unit |
---|
| 181 | { |
---|
| 182 | cubic_texture nm.png combinedUVW |
---|
| 183 | tex_coord_set 1 |
---|
| 184 | tex_address_mode clamp |
---|
| 185 | } |
---|
| 186 | // Normalisation cube map #2 |
---|
| 187 | texture_unit |
---|
| 188 | { |
---|
| 189 | cubic_texture nm.png combinedUVW |
---|
| 190 | tex_coord_set 1 |
---|
| 191 | tex_address_mode clamp |
---|
| 192 | } |
---|
| 193 | } |
---|
| 194 | |
---|
| 195 | // Decal pass |
---|
| 196 | pass |
---|
| 197 | { |
---|
| 198 | lighting off |
---|
| 199 | // Really basic vertex program |
---|
| 200 | vertex_program_ref Ogre/BasicVertexPrograms/AmbientOneTexture |
---|
| 201 | { |
---|
| 202 | param_named_auto worldViewProj worldviewproj_matrix |
---|
| 203 | param_named ambient float4 1 1 1 1 |
---|
| 204 | } |
---|
| 205 | scene_blend dest_colour zero |
---|
| 206 | texture_unit |
---|
| 207 | { |
---|
| 208 | texture RustedMetal.jpg |
---|
| 209 | } |
---|
| 210 | |
---|
| 211 | } |
---|
| 212 | } |
---|
| 213 | } |
---|
| 214 | </pre></td></tr></table></P><P> |
---|
| 215 | |
---|
| 216 | At present only one shadow technique supports additive light masking: <A HREF="manual_63.html#SEC273">7.1 Stencil Shadows</A> through the use of SHADOWTYPE_STENCIL_ADDITIVE. |
---|
| 217 | </P><P> |
---|
| 218 | |
---|
| 219 | <A NAME="SEC295"></A> |
---|
| 220 | <H3> Static Lighting </H3> |
---|
| 221 | <!--docid::SEC295::--> |
---|
| 222 | Despite their power, additive lighting techniques have an additional limitation; they do not combine well with pre-calculated static lighting in the scene. This is because they are based on the principle that shadow is an absence of light, but since static lighting in the scene already includes areas of light and shadow, additive lighting cannot remove light to create new shadows. Therefore, if you use the additive lighting technique you must use it exclusively as your lighting solution (and you can combine it with per-pixel lighting to create a very impressive dynamic lighting solution), you cannot combine it with static lighting. |
---|
| 223 | <P> |
---|
| 224 | |
---|
| 225 | <A NAME="Animation"></A> |
---|
| 226 | <HR SIZE=1> |
---|
| 227 | <TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0> |
---|
| 228 | <TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_65.html#SEC291"> < </A>]</TD> |
---|
| 229 | <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_62.html#SEC270"> Up </A>]</TD> |
---|
| 230 | <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_67.html#SEC296"> > </A>]</TD> |
---|
| 231 | <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="index.html#SEC_Top">Top</A>]</TD> |
---|
| 232 | <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_toc.html#SEC_Contents">Contents</A>]</TD> |
---|
| 233 | <TD VALIGN="MIDDLE" ALIGN="LEFT">[Index]</TD> |
---|
| 234 | <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_abt.html#SEC_About"> ? </A>]</TD> |
---|
| 235 | </TR></TABLE> |
---|
| 236 | <BR> |
---|
| 237 | <FONT SIZE="-1"> |
---|
| 238 | This document was generated |
---|
| 239 | by <I>Steve Streeting</I> on <I>, 12 2006</I> |
---|
| 240 | using <A HREF="http://www.mathematik.uni-kl.de/~obachman/Texi2html |
---|
| 241 | "><I>texi2html</I></A> |
---|
| 242 | |
---|
| 243 | </BODY> |
---|
| 244 | </HTML> |
---|