heh, there's a hell of a lot more that you can do than just play with the color chanels of the pass variable.
what you guys are all looking at was about four seconds of tinkering, there are all sorts of crap you can do
here is a complete list of suported argumaents for all of the optional strings (listed in order that the optional strings apear)
first off I should explain the block system used
there are a number of
#name_of_block{
}name_of_block
things available, the most important of wich are the
#FLP{
}FLP
and
#ALP{
}ALP
blocks they define what happens in the first lighting pass and additive lighting passes respectively. you see the most lights any hardware can suport is 8, so in order to draw an object with more than 8 lights on it we must add the lighting of the remaining lights. so anything related to lighting should be fine most of the time, but you need to change some things almost all of the time, the alpha blending modes need to be changed, on the first lighting pass you need to usualy use either no alpha blending or alpha chanel alpha blending, on the additive lighting passes you almost always want to use additive alpha blending, also the z_buffer usualy needs to be write disabled, in addition to that any non-lit lelements of a material need to be disabled on the additive lighting passes so glowmaps (and things like them) should be held in a #FLP{}FLP block.there are other blocks not demonstrated in the current material table, they relate to diferent environments, such as nebula, subspace and normal space ("normal","nebula","subspace") in order to use these just put the name in the name_of_block section anything between the start and end block denoters with only be present in the corisponding situation, anything outside the block will be present in all situations
"$Material:" name_of_material
the name of the material, the material used by most objects is glowmapped_diffuse, so if you want to play with this, that is the one you should be experimenting on for the most part.
#instance{
don't screw around with "$Format:" yet, it doesn't realy do anything yet, but it will be used eventualy. but for documentation purposes the available flags are:
pos, norm, uv_1, uv_2, uv_3, uv_4, diffuse, specular.
the diferent uv flags are incompatable with each other, and untill major work is done on the model format only uv_1 will do anything, these coordanants tell how many sets of 2d UV coords each vertex has. but as I said this isn't going to be functional for quite a while, it's unfortunate that the instances get started off with such an intimidateing and confuseing item, just ignore this for now.
#Pass{
"$Z_Buffer:" and "$Alpha:" both have a manual mode, and a preset mode. first, I'll describe the preset modes
"$Z_Buffer:+preset:" suports "full" "none" "read" or "write"
full - is normal zbuffering
none - has no z buffering
read - uses the z buffer for drawing but doesn't change it
write - draws without care of the z buffer but outputs it's depth.
if you set it up manualy there are three opptional strings
+Read: (yes/no)
+Write: (yes/no)
+opp: (none,less,equal,lessequal,greater,notequal,greaterequal,all)
for most situations useing the preset of full is all you will need, if you ar useing additive alpha blending you will probly want to turn it to 'read'. the only advantage to manual setup is you have access to wich comparison opperation is used, read and write as well as the whole "$Z_Buffer:" section are totaly optional, if you don't put something down it will defualt to full z buffering, wich is what you want in most cases.
"$Alpha:"
now this one you can have some real fun with, especaly if you make some multi-pass materials.
the alpha presets are
none (default)
'additive' or 'add' (additive alpha, like thrusters)
alpha_blend (uses the alpha chanel for transparencies)
now the manual mode for this has a lot more opptions, you can do all sorts of crazy ****, like subtract what you'r drawing, though at the moment this'll only realy be visable if you use it for multi-passing effects (because the exe doesn't work very well in game yet)
"+src:" and "+dest:" use the one of the following values (capitalizeation not nesicary anyware): ZERO, ONE, SCR_COL, INV_SRC_COL, SRC_ALPHA, INV_SRC_ALPHA, DEST_ALPHA, INV_DEST_ALPHA, DEST_COL, INT_DEST_COL
"+blend:" hmm, I just noticed I forgot to get this one activated, unfortunately this is one of the more fun parameters to fool around with, well I better tell you what the corect values should be (even though they won't work in the build you all have): ALPHA_ADD, ALPHA_SUB, ALPHA_REV_SUB, ALPHA_MIN, ALPHA_MAX
"+test:" it takes a number, I beleve it needs to be a value between 0 and 255. you can use this to make alpha transparent bits that stuff will be able to render through
"+test_opp:" determines how the test works (if the alpha of a pixel on the texture is greater/less/equa/ect..l than the pixel on the screen do/don't draw it) it takes the same arguments as the z test opp and works the exact same way
(none,less,equal,lessequal,greater,notequal,greaterequal,all)
in order to make use of manual pllha blending you need to know the alpha blending formula,
at any given pixel
final color = dest*dest_factor + src*src_factor
'dest' is the color on the screen.
'dest_factor' is what you specify when you use the '+dest:' tag.
'src' is the color of the texture (well actualy the color of the output polygon) at the point on screen it's getting drawn.
'src_factor' is what you specify when you use the '+src:' tag
the addition between the two terms can be changed to a subtraction (or a subtraction with the terms reversed) by changein the "+blend:" tag.
"$Cull:" a much simpler option, this determines wich, if any, cull mode is used, 1 draws polygons faceing the screen,0 draws all polygons, -1 draws only the polygons faceing away from the screen. this would be especaly fun with multi-pass textures were you draw the back face of something one way and the front face a totaly diferent way (with some sort of alpha blending).
if you use 1 or 0 the model will draw prety much exactly like you expect, if you use -1 they will draw inside out. use 0 only if you are doing something like additive alpha.
"$Lighting:" a yes/no, does this material use the fixed function lighting, almost all the time you will want to use 'yes' but if you have something that glows (or later has precalculated lighting values, or you use vertex/pixel shaders) then you would want 'no'
"$Pass_Variable:" this takes an expression for each of the "+R:","+G:","+B:","+A:" components, this is what is used later when you specify a variable for a render step argument.
ok, that's all the current pas specific stuff, now on to the render steps:
"$Render_Step:"
you must always have at least one render step, you may not have more than eight.
"+opp:" this is one of the things you have an absurd number of choices with, it is the opperation that will be performed on the two arguments. the options you will most commonly use would be
add - add arg1 to arg2
and
mult - multiply arg1 with arg2
but you have a few more opptions available,:
DISABLE, ARG_1, ARG_2, MULT, MULTX2, MULTX4, ADD, ADD_SIGNED, ADD_SIGNEDX2, SUB, ADDSMOOTH, BENLD_VERTEX_ALPHA, BLEND_TEXTURE_ALPHA, BLEND_VARIABLE, BLEND_LAST_ALPHA, PREMODULATE, MULT_ALPHA_ADD_COL, MULT_COL_ADD_ALPH, MULT_INV_ALPHA_ADD_COL, MULT_INV_COL_ADD_ALPH, DP3, MULT_ADD, LERP
so... I guess I should explain a few of those...
disable will kill the current render step and any following render steps.
arg_1 and arg_2 mean you just select one of them and discard the other
mult multiply, multX2 = a1 * a2*2, multX4 = a1 * a2*4
ehh.. I'll link to the MS DX documntation that describes all of these in detail.
"+Arg1:" and "+Arg2:" exept on the first pass arg1 defaults to 'current' arg2 defaults to 'texture', now to explain what this means.
the values available for these tags are: CURRENT, TEMP, DIFFUSE, SPECULAR, TEXTURE, VARIABLE
because there are only five, I'll explain all of them
'CURRENT' the result of the last texture step
'TEMP' a temporary off screen drawing area (I'll explain how to draw to this in a second)
'DIFFUSE' and 'SPECULAR' the first and second color chanles respectively, they are named for what lighting values the fixed function lighting system gives them
'VARIABLE' use the pass variable that you defined earlier (if you didn't define this and you use it here it will give you black)
'TEXTURE' one of the material textures, use "+value:" after this to specify wich of the 8 textures to use, with the current hack system only three textures are available 0 = defuse base texture, 1 = glow map, and 2 = shine map. you may use a texture only once per pass, and only one texture at a time.
"+Output" draw the result of the opperation opp(arg_1,arg_2) to the screen (current) or the temp drawing surface.
"+UV Index:" wich set of UV coordanants to use, useless at this time always set to 0 or better yet, don't use at all.
"+Addressing:" one of the more fun things to play with, that I'm use people will get a kick out of, this determine how out of range uvcoords get handled, the default is to wrap (repete, tile), but you also have "mirror" "clamp" and "border", further, you get to determine this on a per direction basis so you can hae it wrap in the U direction and miror in the V. the corect syntax for this item is
+Addressing:
+U:mode
+V:mode
were mode is one of the available options (wrap,mirror,clamp,border)
"+frame_selector:" this is a mathmatical expression that determines wich frame of an animation (if there is an animation used) is selected
the default frame selector is:
"(:global.time:*:texture.fps:)%:texture.n_frames:"
the last line is especaly important to remember, because at this time I don't have any error corection code in place and if you forget to make sure you are within the range of available frames you'll try useing frames that probly don't exsist, or are some random texture, I will fix this eventualy, but at the moment you need to be aware of this.
+texture_matrix(
(ii,ij,ik,il)
(ji,jj,jk,jl)
(ki,kj,kk,kl)
(li,lj,lk,ll)
)
ah... the texture matrix.. what can I say about this...it can do lots of neat stuff. rotations scaleing panning of textures, kind of dificult to explain how to do that tough
you only need to define it as big as the values you need, so generaly the fourth row and collum can be ignored. the matrix is row major (or what ever is the opposite of OGL's default)
*each element is an expression* you can put simple numbers down, or full expressions, useing any game variable or function you could use elseware. currently you can only define a single matrix, so you will have to work matrix multiplications out by hand, but I intend to alow defineing of multable matricies that get multiplied together.
##texture panning: the element ki and kj relate to a UV offset in the U and V directions respectively, this needs to be made a function of time (or some other changeing variable) in order for you to realy see anything happening.
+++++++nothing bad will happen if you just screw around with this, don't be afraid of it+++++++
useing sin and cos of an angle would be usefull in the first 2*2 elements
this matrix is 4*4 because d3d suports up to 4 texture coordanants, and I need all four dimentions to properly set up environment mapping. you will probly never need the 4th row or collum.
}Pass
}instance
