source: OGRE/trunk/ogrenew/Docs/manual/manual_62.html @ 657

Revision 657, 12.6 KB checked in by mattausch, 19 years ago (diff)

added ogre dependencies and patched ogre sources
Line 
1<HTML>
2<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
3<!-- Created on , 28 2005 by texi2html 1.64 -->
4<!--
5Written 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.
9Maintained by: Olaf Bachmann <obachman@mathematik.uni-kl.de>
10Send bugs and suggestions to <texi2html@mathematik.uni-kl.de>
11 
12-->
13<HEAD>
14<TITLE>OGRE Manual v1.0.4: Additive Light Masking</TITLE>
15
16<META NAME="description" CONTENT="OGRE Manual v1.0.4: Additive Light Masking">
17<META NAME="keywords" CONTENT="OGRE Manual v1.0.4: 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="SEC235"></A>
27<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
28<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_61.html#SEC233"> &lt; </A>]</TD>
29<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_58.html#SEC212"> Up </A>]</TD>
30<TD VALIGN="MIDDLE" ALIGN="LEFT">[ &gt; ]</TD>
31<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <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::SEC235::-->
39Additive 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
41As 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_62.html#SEC236">Pass Classification and Vertex Programs</A>). In order to do this technique, Ogre automatically categorises the <A HREF="manual_18.html#SEC35">3.1.2 Passes</A> you define in your materials into 3 types:
42<OL>
43<LI>ambient
44Passes 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.
45<LI>diffuse/specular
46Passes 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).
47<LI>decal
48Passes 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.
49</OL>
50
51In practice, <A HREF="manual_18.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:
52<TABLE><tr><td>&nbsp;</td><td class=example><pre>material TestIllumination
53{
54        technique
55        {
56                pass
57                {
58                        ambient 0.5 0.2 0.2
59                        diffuse 1 0 0 
60                        specular 1 0.8 0.8 15
61                        texture_unit
62                        {
63                                texture grass.png
64                        }
65                }
66        }
67}
68</pre></td></tr></table>
69Ogre will split this into 3 illumination passes, which will be the equivalent of this:
70<TABLE><tr><td>&nbsp;</td><td class=example><pre>material TestIlluminationSplitIllumination
71{
72        technique
73        {
74                // Ambient pass
75                pass
76                {
77                        ambient 0.5 0.2 0.2
78                        diffuse 0 0 0
79                        specular 0 0 0
80                }
81
82                // Diffuse / specular pass
83                pass
84                {
85                        scene_blend add
86                        iteration once_per_light
87                        diffuse 1 0 0 
88                        specular 1 0.8 0.8 15
89                }
90
91                // Decal pass
92                pass
93                {
94                        scene_blend modulate
95                        lighting off
96                        texture_unit
97                        {
98                                texture grass.png
99                        }
100                }
101        }
102}
103</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>
104
105<A NAME="Pass Classification and Vertex Programs"></A>
106<A NAME="SEC236"></A>
107<H3> Pass Classification and Vertex Programs </H3>
108<!--docid::SEC236::-->
109Ogre 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>
110
111In 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>
112
113Note 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>
114
115So 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:
116<TABLE><tr><td>&nbsp;</td><td class=example><pre>// Per-pixel normal mapping Any number of lights, diffuse and specular
117material Examples/BumpMapping/MultiLightSpecular
118{
119
120        technique
121        {
122                // Base ambient pass
123                pass
124                {
125                        // ambient only, not needed for rendering, but as information
126                        // to lighting pass categorisation routine
127                        ambient 1 1 1
128                        diffuse 0 0 0
129                        specular 0 0 0 0
130                        // Really basic vertex program
131                        vertex_program_ref Ogre/BasicVertexPrograms/AmbientOneTexture
132                        {
133                                param_named_auto worldViewProj worldviewproj_matrix
134                                param_named_auto ambient ambient_light_colour
135                        }
136                       
137                }
138                // Now do the lighting pass
139                // NB we don't do decal texture here because this is repeated per light
140                pass
141                {
142                        // set ambient off, not needed for rendering, but as information
143                        // to lighting pass categorisation routine
144                        ambient 0 0 0
145                        // do this for each light
146                        iteration once_per_light
147
148               
149                        scene_blend add
150
151                        // Vertex program reference
152                        vertex_program_ref Examples/BumpMapVPSpecular
153                        {
154                                param_named_auto lightPosition light_position_object_space 0
155                                param_named_auto eyePosition camera_position_object_space
156                                param_named_auto worldViewProj worldviewproj_matrix
157                        }
158
159                        // Fragment program
160                        fragment_program_ref Examples/BumpMapFPSpecular
161                        {
162                                param_named_auto lightDiffuse light_diffuse_colour 0
163                                param_named_auto lightSpecular light_specular_colour 0
164                        }
165                       
166                        // Base bump map
167                        texture_unit
168                        {
169                                texture NMBumpsOut.png
170                                colour_op replace
171                        }
172                        // Normalisation cube map
173                        texture_unit
174                        {
175                                cubic_texture nm.png combinedUVW
176                                tex_coord_set 1
177                                tex_address_mode clamp
178                        }
179                        // Normalisation cube map #2
180                        texture_unit
181                        {
182                                cubic_texture nm.png combinedUVW
183                                tex_coord_set 1
184                                tex_address_mode clamp
185                        }
186                }
187               
188                // Decal pass
189                pass
190                {
191                        lighting off
192                        // Really basic vertex program
193                        vertex_program_ref Ogre/BasicVertexPrograms/AmbientOneTexture
194                        {
195                                param_named_auto worldViewProj worldviewproj_matrix
196                                param_named ambient float4 1 1 1 1
197                        }
198                        scene_blend dest_colour zero
199                        texture_unit
200                        {
201                                texture RustedMetal.jpg
202                        }
203                       
204                }
205        }
206}
207</pre></td></tr></table>
208At present only one shadow technique supports additive light masking: <A HREF="manual_59.html#SEC215">7.1 Stencil Shadows</A> through the use of SHADOWTYPE_STENCIL_ADDITIVE.
209
210<A NAME="SEC237"></A>
211<H3> Static Lighting </H3>
212<!--docid::SEC237::-->
213Despite 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.
214
215
216
217<HR SIZE=1>
218<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
219<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_61.html#SEC233"> &lt; </A>]</TD>
220<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_58.html#SEC212"> Up </A>]</TD>
221<TD VALIGN="MIDDLE" ALIGN="LEFT">[ &gt; ]</TD>
222<TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT"> &nbsp; <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="index.html#SEC_Top">Top</A>]</TD>
223<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_toc.html#SEC_Contents">Contents</A>]</TD>
224<TD VALIGN="MIDDLE" ALIGN="LEFT">[Index]</TD>
225<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_abt.html#SEC_About"> ? </A>]</TD>
226</TR></TABLE>
227<BR> 
228<FONT SIZE="-1">
229This document was generated
230by <I>Steve Streeting</I> on <I>, 28 2005</I>
231using <A HREF="http://www.mathematik.uni-kl.de/~obachman/Texi2html
232"><I>texi2html</I></A>
233
234</BODY>
235</HTML>
Note: See TracBrowser for help on using the repository browser.