> Because it is uniform it is entirely under the control of the application, > the shader cannot modify it in any way.
Another main point about "uniformity" is that the value is the same for *all* vertices (and thus fragments) of the current mesh (as opposed to "varying" variables which can be different for each vertex [and thus fragments]). (Since there are usually much less varying variables available than uniform ones it's usually a good idea to use uniforms if possible.) > The shader variable can be accessed through the iMaterial interface The text doesn't explicitly states that materials are the only container for shader vars; but it doesn't say the opposite either :) Perhaps mention at some point that other places for SVs exists. (Such as mesh wrappers ... which would be useful for your highlighting case: use the same material for all meshes, and just set/unset the highlight color *on the mesh*.) > The material object is a collection of texture, shaders (TODO: why an S?), > and shader variable The "textures" referenced by a material are actually stored in SVs, too. It might be slighly more correct to speak of "references to shaders" or some such, as materials are not the primary container for shaders. "(TODO: why an S?)" - you wonder why materials contain references to shaders? > A technique is then a collection of pass, each pass including some code to do > the rendering for that pass. That rendering is delegated to plugins. Technically not entirely correct. The shader plugins references in a CS shader just do some shader setup (setting GL states and such), they don't render stuff themselves. (Rendering is still done by plugins - render loop ones, currently - but the choice of these plugins is *not* affected by the shaders. Quite the opposite: the rendering chooses the shader(s) used for a material.) > (I am not 100% sure what succeed means on top of compiling properly). That's it: "succeeds" means shader technique can be used. The referenced shader plugins must be present and programs must load. Generally it means the hardware/renderer must support the program. For Cg programs this essentially means the program can be compiled to something the hardware supports. For e.g. multitexturing setup the number of "layers" must not exceed what the HW supports. And so on. > The ‘texture coordinate X’ destinations correspond to TEXCOORDX in the Cg > code. You can also use names of varying variables directly as buffer destinations: > <buffer source="texture coordinate 0" destination="IN.TexCoord" /> The explicit "TEXCOORD0" binding can also be omitted from the Cg code. (Using this feature is IMO easier than using explicit bindings: you can add new varying variables and remove some without much headache about what buffers were already used or not. This is especially relevant for more complex applications of shader conditionals were you may want to use/not use certain input data depending on SV values; not declaring used buffers in that case is slightly more economic. But note that some bindings are still needed, notably POSITION.) > recompiled on the fly if needed Not exactly recompiled. Compiled variations of a shader are cached, so each variation is at most compiled once. > Shader Xml syntax Might be a good idea to put this syntax overview into it's own article/wiki page/manual page. > Shader Template Xml system Maybe put a link to the existing (albeit lengthier and drier) reference in: http://crystalspace3d.org/docs/online/manual/Shader-Conditions-and-Processing-Instructions-Reference.php#0 > flipculling Flips the culling: when specified, not backfaces, but frontfaces are culled. > writemask Can be used to selectively disable writing of any combination of the red, green, blue, alpha components to the render target. > Vertex program (not to be confused with vertex shaders) "vproc" means "vertex processor". Vertex programs are called that in CS, and not vertex shaders. Likewise, we call fragment programs that. -f.r.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Crystal-main mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/crystal-main Unsubscribe: mailto:[EMAIL PROTECTED]
