source: OGRE/trunk/ogrenew/Docs/manual/manual_19.html @ 692

Revision 692, 25.7 KB checked in by mattausch, 18 years ago (diff)

adding ogre 1.2 and dependencies
Line 
1<HTML>
2<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
3<!-- Created on , 12 2006 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.2.0 ('Dagon'): Using Vertex and Fragment Programs in a Pass</TITLE>
15
16<META NAME="description" CONTENT="OGRE Manual v1.2.0 ('Dagon'): Using Vertex and Fragment Programs in a Pass">
17<META NAME="keywords" CONTENT="OGRE Manual v1.2.0 ('Dagon'): Using Vertex and Fragment Programs in a Pass">
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="SEC99"></A>
27<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
28<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_18.html#SEC85"> &lt; </A>]</TD>
29<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_14.html#SEC23"> Up </A>]</TD>
30<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_20.html#SEC106"> &gt; </A>]</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<H3> 3.1.5 Using Vertex and Fragment Programs in a Pass </H3>
38<!--docid::SEC99::-->
39<P>
40
41Within a pass section of a material script, you can reference a vertex and / or a fragment program which is been defined in a .program script (See section <A HREF="manual_18.html#SEC85">3.1.4 Declaring Vertex and Fragment Programs</A>). The programs are defined separately from the usage of them in the pass, since the programs are very likely to be reused between many separate materials, probably across many different .material scripts, so this approach lets you define the program only once and use it many times.<BR><BR>
42</P><P>
43
44As well as naming the program in question, you can also provide parameters to it. Here's a simple example:
45<TABLE><tr><td>&nbsp;</td><td class=example><pre>vertex_program_ref myVertexProgram
46{
47        param_indexed_auto 0 worldviewproj_matrix
48        param_indexed      4 float4  10.0 0 0 0
49}
50</pre></td></tr></table>In this example, we bind a vertex program called 'myVertexProgram' (which will be defined elsewhere) to the pass, and give it 2 parameters, one is an 'auto' parameter, meaning we do not have to supply a value as such, just a recognised code (in this case it's the world/view/projection matrix which is kept up to date automatically by Ogre). The second parameter is a manually specified parameter, a 4-element float. The indexes are described later.<BR><BR>
51</P><P>
52
53The syntax of the link to a vertex program and a fragment program are identical, the only difference is that 'fragment_program_ref' is used instead of 'vertex_program_ref'.
54<A NAME="Program Parameter Specification"></A>
55<A NAME="SEC100"></A>
56<H3> Parameter specification </H3>
57<!--docid::SEC100::-->
58Parameters can be specified using one of 4 commands as shown below. The same syntax is used whether you are defining a parameter just for this particular use of the program, or when specifying the <A HREF="manual_18.html#SEC86">Default Program Parameters</A>. Parameters set in the specific use of the program override the defaults.
59<UL>
60<LI><A HREF="manual_19.html#SEC101">param_indexed</A>
61<LI><A HREF="manual_19.html#SEC102">param_indexed_auto</A>
62<LI><A HREF="manual_19.html#SEC103">param_named</A>
63<LI><A HREF="manual_19.html#SEC104">param_named_auto</A>
64</UL>
65<P>
66
67<A NAME="param_indexed"></A>
68<A NAME="SEC101"></A>
69<H3> param_indexed </H3>
70<!--docid::SEC101::-->
71This command sets the value of an indexed parameter. <BR><BR>
72<P>
73
74format: param_indexed &#60;index&#62; &#60;type&#62; &#60;value&#62;<BR><BR>
75example: param_indexed 0 float4 10.0 0 0 0<BR><BR>
76</P><P>
77
78The 'index' is simply a number representing the position in the parameter list which the value should be written, and you should derive this from your program definition. The index is relative to the way constants are stored on the card, which is in 4-element blocks. For example if you defined a float4 parameter at index 0, the next index would be 1. If you defined a matrix4x4 at index 0, the next usable index would be 4, since a 4x4 matrix takes up 4 indexes.<BR><BR>
79</P><P>
80
81The value of 'type' can be float4, matrix4x4, float&#60;n&#62;, int4, int&#60;n&#62;. Note that 'int' parameters are only available on some more advanced program syntaxes, check the D3D or GL vertex / fragment program documentation for full details. Typically the most useful ones will be float4 and matrix4x4. Note that if you use a type which is not a multiple of 4, then the remaining values up to the multiple of 4 will be filled with zeroes for you (since GPUs always use banks of 4 floats per constant even if only one is used).<BR><BR>
82</P><P>
83
84'value' is simply a space or tab-delimited list of values which can be converted into the type you have specified.
85</P><P>
86
87<A NAME="param_indexed_auto"></A>
88<A NAME="SEC102"></A>
89<H3> param_indexed_auto </H3>
90<!--docid::SEC102::-->
91<P>
92
93This command tells Ogre to automatically update a given parameter with a derived value. This frees you from writing code to update program parameters every frame when they are always changing.<BR><BR>
94</P><P>
95
96format: param_indexed_auto &#60;index&#62; &#60;value_code&#62; &#60;extra_params&#62;<BR><BR>
97example: param_indexed_auto 0 worldviewproj_matrix<BR><BR>
98</P><P>
99
100'index' has the same meaning as <A HREF="manual_19.html#SEC101">param_indexed</A>; note this time you do not have to specify the size of the parameter because the engine knows this already. In the example, the world/view/projection matrix is being used so this is implicitly a matrix4x4.<BR><BR>
101</P><P>
102
103'value_code' is one of a list of recognised values:<BR>
104<DL COMPACT>
105<DT>world_matrix
106<DD>The current world matrix.
107<DT>inverse_world_matrix
108<DD>The inverse of the current world matrix.
109<DT>transpose_world_matrix
110<DD>The transpose of the world matrix
111<DT>inverse_transpose_world_matrix
112<DD>The inverse transpose of the world matrix
113<P>
114
115<DT>world_matrix_array_3x4
116<DD>An array of world matrices, each represented as only a 3x4 matrix (3 rows of 4columns) usually for doing hardware skinning. You should make enough entries available in your vertex program for the number of bones in use, ie an array of numBones*3 float4's.
117<P>
118
119<DT>view_matrix
120<DD>The current view matrix.
121<DT>inverse_view_matrix
122<DD>The inverse of the current view matrix.
123<DT>transpose_view_matrix
124<DD>The transpose of the view matrix
125<DT>inverse_transpose_view_matrix
126<DD>The inverse transpose of the view matrix
127<P>
128
129<DT>projection_matrix
130<DD>The current projection matrix.
131<DT>inverse_projection_matrix
132<DD>The inverse of the projection matrix
133<DT>transpose_projection_matrix
134<DD>The transpose of the projection matrix
135<DT>inverse_transpose_projection_matrix
136<DD>The inverse transpose of the projection matrix
137<P>
138
139<DT>worldview_matrix
140<DD>The current world and view matrices concatenated.
141<DT>inverse_worldview_matrix
142<DD>The inverse of the current concatenated world and view matrices.
143<DT>transpose_worldview_matrix
144<DD>The transpose of the world and view matrices
145<DT>inverse_transpose_worldview_matrix
146<DD>The inverse transpose of the current concatenated world and view matrices.
147<P>
148
149<DT>viewproj_matrix
150<DD>The current view and projection matrices concatenated.
151<DT>inverse_viewproj_matrix
152<DD>The inverse of the view &#38; projection matrices
153<DT>transpose_viewproj_matrix
154<DD>The transpose of the view &#38; projection matrices
155<DT>inverse_transpose_viewproj_matrix
156<DD>The inverse transpose of the view &#38; projection matrices
157<P>
158
159<DT>worldviewproj_matrix
160<DD>The current world, view and projection matrices concatenated.
161<DT>inverse_worldviewproj_matrix
162<DD>The inverse of the world, view and projection matrices
163<DT>transpose_worldviewproj_matrix
164<DD>The transpose of the world, view and projection matrices
165<DT>inverse_transpose_worldviewproj_matrix
166<DD>The inverse transpose of the world, view and projection matrices
167<P>
168
169<DT>render_target_flipping
170<DD>The value use to adjust transformed y position if bypassed projection matrix transform. It's -1 if the render target requires texture flipping, +1 otherwise.
171<P>
172
173<DT>light_diffuse_colour
174<DD>The diffuse colour of a given light; this requires an index in the 'extra_params' field, and relates to the 'nth' closest light which could affect this object (ie 0 refers to the closest light - note that directional lights are always first in the list and always present). NB if there are no lights this close, then the parameter will be set to black.
175<DT>light_specular_colour
176<DD>The specular colour of a given light; this requires an index in the 'extra_params' field, and relates to the 'nth' closest light which could affect this object (ie 0 refers to the closest light). NB if there are no lights this close, then the parameter will be set to black.
177<DT>light_attenuation
178<DD>A float4 containing the 4 light attenuation variables for a given light. This requires an index in the 'extra_params' field, and relates to the 'nth' closest light which could affect this object (ie 0 refers to the closest light). NB if there are no lights this close, then the parameter will be set to all zeroes. The order of the parameters is range, constant attenuation, linear attenuation, quadric attenuation.
179<DT>light_position
180<DD>The position of a given light in world space. This requires an index in the 'extra_params' field, and relates to the 'nth' closest light which could affect this object (ie 0 refers to the closest light). NB if there are no lights this close, then the parameter will be set to all zeroes. Note that this property will work with all kinds of lights, even directional lights, since the parameter is set as a 4D vector. Point lights will be (pos.x, pos.y, pos.z, 1.0f) whilst directional lights will be (-dir.x, -dir.y, -dir.z, 0.0f). Operations like dot products will work consistently on both.
181<DT>light_direction
182<DD>The direction of a given light in world space. This requires an index in the 'extra_params' field, and relates to the 'nth' closest light which could affect this object (ie 0 refers to the closest light). NB if there are no lights this close, then the parameter will be set to all zeroes. DEPRECATED - this property only works on directional lights, and we recommend that you use light_position instead since that returns a generic 4D vector.
183<DT>light_position_object_space
184<DD>The position of a given light in object space (ie when the object is at (0,0,0)). This requires an index in the 'extra_params' field, and relates to the 'nth' closest light which could affect this object (ie 0 refers to the closest light). NB if there are no lights this close, then the parameter will be set to all zeroes.  Note that this property will work with all kinds of lights, even directional lights, since the parameter is set as a 4D vector. Point lights will be (pos.x, pos.y, pos.z, 1.0f) whilst directional lights will be (-dir.x, -dir.y, -dir.z, 0.0f). Operations like dot products will work consistently on both.
185<DT>light_direction_object_space
186<DD>The direction of a given light in object space (ie when the object is at (0,0,0)). This requires an index in the 'extra_params' field, and relates to the 'nth' closest light which could affect this object (ie 0 refers to the closest light). NB if there are no lights this close, then the parameter will be set to all zeroes.  DEPRECATED, except for spotlights - for directional lights we recommend that you use light_position_object_space instead since that returns a generic 4D vector.
187<DT>light_position_view_space
188<DD>The position of a given light in view space (ie when the camera is at (0,0,0)). This requires an index in the 'extra_params' field, and relates to the 'nth' closest light which could affect this object (ie 0 refers to the closest light). NB if there are no lights this close, then the parameter will be set to all zeroes.  Note that this property will work with all kinds of lights, even directional lights, since the parameter is set as a 4D vector. Point lights will be (pos.x, pos.y, pos.z, 1.0f) whilst directional lights will be (-dir.x, -dir.y, -dir.z, 0.0f). Operations like dot products will work consistently on both.
189<DT>light_direction_view_space
190<DD>The direction of a given light in view space (ie when the camera is at (0,0,0)). This requires an index in the 'extra_params' field, and relates to the 'nth' closest light which could affect this object (ie 0 refers to the closest light). NB if there are no lights this close, then the parameter will be set to all zeroes.  DEPRECATED, except for spotlights - for directional lights we recommend that you use light_position_view_space instead since that returns a generic 4D vector.
191<DT>light_power
192<DD>The 'power' scaling for a given light, useful in HDR rendering. This requires an index in the 'extra_params' field, and relates to the 'nth' closest light which could affect this object (ie 0 refers to the closest light).
193<DT>ambient_light_colour
194<DD>The colour of the ambient light currently set in the scene.
195<DT>fog_colour
196<DD>The colour of the fog currently set in the scene.
197<DT>fog_params
198<DD>The parameters of the fog currently set in the scene. Packed as (exp_density, linear_start, linear_end, 1.0 / (linear_end - linear_start)).
199<DT>camera_position
200<DD>The current cameras position in world space.
201<DT>camera_position_object_space
202<DD>The current cameras position in object space (ie when the object is at (0,0,0)).
203<DT>time
204<DD>The current time, factored by the optional parameter (or 1.0f if not supplied).
205<DT>time_0_x
206<DD>Single float time value, which repeats itself based on "cycle time" given as an 'extra_params' field
207<DT>costime_0_x
208<DD>Cosine of time_0_x
209<DT>sintime_0_x
210<DD>Sine of time_0_x
211<DT>tantime_0_x
212<DD>Tangent of time_0_x
213<DT>time_0_x_packed
214<DD>4-element vector of time0_x, sintime0_x, costime0_x, tantime0_x
215<DT>time_0_1
216<DD>As time0_x but scaled to [0..1]
217<DT>costime_0_1
218<DD>As costime0_x but scaled to [0..1]
219<DT>sintime_0_1
220<DD>As sintime0_x but scaled to [0..1]
221<DT>tantime_0_1
222<DD>As tantime0_x but scaled to [0..1]
223<DT>time_0_1_packed
224<DD>As time0_x_packed but all values scaled to [0..1]
225<DT>time_0_2pi
226<DD>As time0_x but scaled to [0..2*Pi]
227<DT>costime_0_2pi
228<DD>As costime0_x but scaled to [0..2*Pi]
229<DT>sintime_0_2pi
230<DD>As sintime0_x but scaled to [0..2*Pi]
231<DT>tantime_0_2pi
232<DD>As tantime0_x but scaled to [0..2*Pi]
233<DT>time_0_2pi_packed
234<DD>As time0_x_packed but scaled to [0..2*Pi]
235<DT>frame_time
236<DD>The current frame time, factored by the optional parameter (or 1.0f if not supplied).
237<DT>fps
238<DD>The current frames per second
239<DT>viewport_width
240<DD>The current viewport width in pixels
241<DT>viewport_height
242<DD>The current viewport height in pixels
243<DT>inverse_viewport_width
244<DD>1.0/the current viewport width in pixels
245<DT>inverse_viewport_height
246<DD>1.0/the current viewport height in pixels
247<DT>viewport_size
248<DD>4-element vector of viewport_width, viewport_height, inverse_viewport_width, inverse_viewport_height
249<DT>view_direction
250<DD>View direction vector in object space
251<DT>view_side_vector
252<DD>View local X axis
253<DT>view_up_vector
254<DD>View local Y axis
255<DT>fov
256<DD>Vertical field of view, in radians
257<DT>near_clip_distance
258<DD>Near clip distance, in world units
259<DT>far_clip_distance
260<DD>Far clip distance, in world units (may be 0 for infinite view projection)
261<DT>texture_viewproj_matrix
262<DD>Only applicable to vertex programs which have been specified as the 'shadow receiver' vertex program alternative; this provides details of the view/projection matrix for the current shadow projector.
263<A NAME="pass_number"></A>
264<DT>pass_number
265<DD>Sets the active pass index number in a gpu parameter. The first pass in a technique has an index of 0, the second an index of 1 and so on. This is usefull for multipass shaders (ie fur or blur shader) that need to know what pass it is. By setting up the auto parameter in a <A HREF="manual_18.html#SEC86">Default Program Parameters</A> list in a program definition, there is no requirement to set the pass number parameter in each pass and lose track. (See  <A HREF="manual_16.html#fur_example">fur_example</A>)
266<A NAME="pass_iteration_number"></A>
267<DT>pass_iteration_number
268<DD>Usefull for GPU programs that need to know what the current pass iteration number is. The first iteration of a pass is numbered 0.  The last iteration number is one less than what is set for the pass iteration number.  If a pass has its iteration attribute set to 5 then the last iteration number (5th execution of the pass) is 4.(See section <A HREF="manual_16.html#SEC55">iteration</A>)
269<A NAME="animation_parametric"></A>
270<DT>animation_parametric
271<DD>Useful for hardware vertex animation. For morph animation, sets the parametric value (0..1) representing the distance between the first position keyframe (bound to positions) and the second position keyframe (bound to the first free texture coordinate) so that the vertex program can interpolate between them. For pose animation, indicates a group of up to 4 parametric weight values applying to a sequence of up to 4 poses (each one bound to x, y, z and w of the constant), one for each pose. The original positions are held in the usual position buffer, and the offsets to take those positions to the pose where weight == 1.0 are in the first 'n' free texture coordinates; 'n' being determined by the value passed to includes_pose_animation. If more than 4 simultaneous poses are required, then you'll need more than 1 shader constant to hold the parametric values, in which case you should use this binding more than once, referencing a different constant entry; the second one will contain the parametrics for poses 5-8, the third for poses 9-12, and so on.
272<DT>custom
273<DD>This allows you to map a custom parameter on an individual Renderable (see Renderable::setCustomParameter) to a parameter on a GPU program. It requires that you complete the 'extra_params' field with the index that was used in the Renderable::setCustomParameter call, and this will ensure that whenever this Renderable is used, it will have it's custom parameter mapped in. It's very important that this parameter has been defined on all Renderables that are assigned the material that contains this automatic mapping, otherwise the process will fail.
274</DL>
275<P>
276
277<A NAME="param_named"></A>
278<A NAME="SEC103"></A>
279<H3> param_named </H3>
280<!--docid::SEC103::-->
281This is the same as param_indexed, but uses a named parameter instead of an index. This can only be used with high-level programs which include parameter names; if you're using an assembler program then you have no choice but to use indexes. Note that you can use indexed parameters for high-level programs too, but it is less portable since if you reorder your parameters in the high-level program the indexes will change.<BR><BR>
282format: param_named &#60;name&#62; &#60;type&#62; &#60;value&#62;<BR><BR>
283example: param_named shininess float4 10.0 0 0 0<BR><BR>
284The type is required because the program is not compiled and loaded when the material script is parsed, so at this stage we have no idea what types the parameters are. Programs are only loaded and compiled when they are used, to save memory.
285<P>
286
287<A NAME="param_named_auto"></A>
288<A NAME="SEC104"></A>
289<H3> param_named_auto </H3>
290<!--docid::SEC104::-->
291<P>
292
293This is the named equivalent of param_indexed_auto, for use with high-level programs.<BR><BR>
294Format: param_named_auto &#60;name&#62; &#60;value_code&#62; &#60;extra_params&#62;<BR><BR>
295Example: param_named_auto worldViewProj WORLDVIEWPROJ_MATRIX<BR><BR>
296</P><P>
297
298The allowed value codes and the meaning of extra_params are detailed in <A HREF="manual_19.html#SEC102">param_indexed_auto</A>.
299</P><P>
300
301<A NAME="Shadows and Vertex Programs"></A>
302<A NAME="SEC105"></A>
303<H3> Shadows and Vertex Programs </H3>
304<!--docid::SEC105::-->
305When using shadows (See section <A HREF="manual_62.html#SEC270">7. Shadows</A>), the use of vertex programs can add some additional complexities, because Ogre can only automatically deal with everything when using the fixed-function pipeline. If you use vertex programs, and you are also using shadows, you may need to make some adjustments. <BR><BR>
306<P>
307
308If you use <STRONG>stencil shadows</STRONG>, then any vertex programs which do vertex deformation can be a problem, because stencil shadows are calculated on the CPU, which does not have access to the modified vertices. If the vertex program is doing standard skeletal animation, this is ok (see section above) because Ogre knows how to replicate the effect in software, but any other vertex deformation cannot be replicated, and you will either have to accept that the shadow will not reflect this deformation, or you should turn off shadows for that object. <BR><BR>
309</P><P>
310
311If you use <STRONG>texture shadows</STRONG>, then vertex deformation is acceptable; however, when rendering the object into the shadow texture (the shadow caster pass), the shadow has to be rendered in a solid colour (linked to the ambient colour). You must therefore provide an alternative vertex program, so Ogre provides you with a way of specifying one to use when rendering the caster. Basically you link an alternative vertex program, using exactly the same syntax as the original vertex program link:
312</P><P>
313
314<TABLE><tr><td>&nbsp;</td><td class=example><pre>shadow_caster_vertex_program_ref myShadowCasterVertexProgram
315{
316        param_indexed_auto 0 worldviewproj_matrix
317        param_indexed_auto 4 ambient_light_colour
318}
319</pre></td></tr></table></P><P>
320
321When rendering a shadow caster, Ogre will automatically use the alternate program. You can bind the same or different parameters to the program - the most important thing is that you bind <STRONG>ambiend_light_colour</STRONG>, since this determines the colour of the shadow in modulative texture shadows. If you don't supply an alternate program, Ogre will fall back on a fixed-function material which will not reflect any vertex deformation you do in your vertex program. <BR><BR>
322</P><P>
323
324In addition, when rendering the shadow receivers with shadow textures, Ogre needs to project the shadow texture. It does this automatically in fixed function mode, but if the receivers use vertex programs, they need to have a shadow receiver program which does the usual vertex deformation, but also generates projective texture coordinates. The additional program linked into the pass like this:
325</P><P>
326
327<TABLE><tr><td>&nbsp;</td><td class=example><pre>shadow_receiver_vertex_program_ref myShadowReceiverVertexProgram
328{
329        param_indexed_auto 0 worldviewproj_matrix
330        param_indexed_auto 4 texture_viewproj_matrix
331}
332</pre></td></tr></table></P><P>
333
334For the purposes of writing this alternate program, there is an automatic parameter binding of 'texture_viewproj_matrix' which provides the program with texture projection parameters. The vertex program should do it's normal vertex processing, and generate texture coordinates using this matrix and place them in texture coord sets 0 and 1, since some shadow techniques use 2 texture units. The colour of the vertices output by this vertex program must always be white, so as not to affect the final colour of the rendered shadow. <BR><BR>
335</P><P>
336
337When using additive texture shadows, the shadow pass render is actually the lighting render, so if you perform any fragmene program lighting you also need to pull in a custom fragment program. You use the shadow_receiver_fragment_program_ref for this:
338<TABLE><tr><td>&nbsp;</td><td class=example><pre>shadow_receiver_fragment_program_ref myShadowReceiverFragmentProgram
339{
340        param_named_auto lightDiffuse light_diffuse_colour 0
341}
342</pre></td></tr></table>You should pass the projected shadow coordinates from the custom vertex program. As for textures, texture unit 0 will always be the shadow texture. Any other textures which you bind in your pass will be carried across too, but will be moved up by 1 unit to make room for the shadow texture. Therefore your shadow receiver fragment program is likely to be the same as the bare lighting pass of your normal material, except that you insert an extra texture sampler at index 0, which you will use to adjust the result by (modulating diffuse and specular components).
343</P><P>
344
345<A NAME="Copying Materials"></A>
346<HR SIZE=1>
347<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
348<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_18.html#SEC85"> &lt; </A>]</TD>
349<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_14.html#SEC23"> Up </A>]</TD>
350<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_20.html#SEC106"> &gt; </A>]</TD>
351<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>
352<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_toc.html#SEC_Contents">Contents</A>]</TD>
353<TD VALIGN="MIDDLE" ALIGN="LEFT">[Index]</TD>
354<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="manual_abt.html#SEC_About"> ? </A>]</TD>
355</TR></TABLE>
356<BR> 
357<FONT SIZE="-1">
358This document was generated
359by <I>Steve Streeting</I> on <I>, 12 2006</I>
360using <A HREF="http://www.mathematik.uni-kl.de/~obachman/Texi2html
361"><I>texi2html</I></A>
362
363</BODY>
364</HTML>
Note: See TracBrowser for help on using the repository browser.