Thancks a lot for the feed-back and the time spend. I'll update
the text. I have some additional questions though:
"(TODO: why an S?)" - you wonder why materials contain references to
shaders?
=> Yes, why many shaders are referenced by a material ?
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.)
=> There is something subtle I don't grasp. What you mean is that (for
exemple) my Cg code gets called/executed by the
render loop ?
Best regards,
Sebastien.
res a écrit :
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 âEUR~texture coordinate XâEUR^(TM) 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.
------------------------------------------------------------------------
-------------------------------------------------------------------------
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]
-------------------------------------------------------------------------
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]
