source: GTP/trunk/App/Demos/Illum/IBRBillboardCloudTrees/OGRE/IBRTreesOGRE/media/oldgeneral/help_shadow_mapping.txt @ 1493

<kandhalt> Hi everybody!
<fp12> wow, I convert my file to have CR and it doesn't find my materials anymore...
<kandhalt> I have some questions about shadow techniques in ogre3d
<Sinbad> download for release build on Windows you get CRLF, download on Linux/OSX for release build and you get CR
<kandhalt> I have different kind of objects in ogre3D
<kandhalt> I have trees for example
<kandhalt> the leaves are semitransparent planes
<kandhalt> and the trunk a simple trunk mesh
<Sinbad> kandhalt: texture shadows can deal with alpha, stencil shadows cannot
<kandhalt> my question is that I want to use different  custom shaders in order to compute
<kandhalt> the shadows for each kind of object
<kandhalt> the problem that I see is that if I use the call setShadowTextureCasterMaterial
<kandhalt> ALL the objects will use the same technique
<Phantom-> Sinbad: I am wondering about the skybox orientation argument... Why isn't just the skybox scenenode rotated? at the moment all the six planes are rotated according to the orientation quaternion...
<kandhalt> Sinbad: the problem is that I'm using a special kind of billboard clouds for the tree leaves
<kandhalt> and I apply a different approach in order to have high resolution impostors in the shader
<kandhalt> so the shader code is not the same that I use for generate the shadow of the trunk
<kandhalt> that's why I ask if there is a way to specify different shadow techniques for each object
<kandhalt> all of them will be texture shadows of course
<kandhalt> but with some differences in the shader code
<Soulim> Somebody said something like RenderToTexture? What is the function for that?
<P__> Phantom-, skybox has no scenenode, or i'm wrong ?
<Sinbad> kandhalt: you can set a shadow caster vertex shader per pass
<-- DWORD se ha marchado (Read error: 110 (Connection timed out))
<Sinbad> http://www.ogre3d.org/docs/manual/manual_20.html#SEC85
<kandhalt> Sinbad, yes I know. but
<kandhalt> for example
<P__> Soulim, you can look at the RenderToTexture demo
<Phantom-> P__: yes it has, I tried modifying the code to just rotating the scenenode
<kandhalt> if I set the vertex shader code <---> for the shadow of the leaves
<Soulim> P__ - oh yes, the ogre examples
<P__> Phantom-, ok
<-- dogzr se ha marchado ()
<kandhalt> then this code won't be de one that I want to exec for generating the shadows of the trunk
<Sinbad> Phantom-: can't remember - but it's the same thing ;)
<kandhalt> I have different shaders
<Sinbad> kandhalt: I know
<kandhalt> Sinbad: what I mean is that if I set a material with this vertex shader for the shadow_map pass
<-- Siroro se ha marchado (Read error: 110 (Connection timed out))
<kandhalt> I can't have the other vertex shader for the other kind of object
<Sinbad> hence why I said you can set a shadow vertex shader for each pass, per material thus have a different one for the trunk and the leaves
<kandhalt> mmm... but I thought
<Phantom-> Sinbad: yea I know it should be, but somehow when rotating with the current version, the planes of the skybox get dragged further and further appart from eachother... it's hard to explain. Changing ogres code to use the scenenode orientation fixed this
<Phantom-> no idea why
<-- Soulim se ha marchado ("Zzz")
<kandhalt> that if I use a custom technique for the shadow mapping I have to define the
<kandhalt> setShadowTextureCastMaterial
<kandhalt> WITH the material that has the custom shadow vertex shader
<kandhalt> isn't it?
<Sinbad> you didn't read the notes in the API
<Sinbad> Individual objects may also override the vertex program in
<Sinbad> your default material if their materials include 
<P__> good night
<Sinbad> shadow_caster_vertex_program_ref shadow_receiver_vertex_program_ref
<-- P__ se ha marchado ("Leaving")
<Sinbad> entries, so if you use both make sure they are compatible.
<Sinbad> thats in the setShadowTextureCasterMaterial API description
<Sinbad> Phantom-: odd, well submit it as a patch then please :)
<Phantom-> Sinbad: On my way. But first I will make a few more test to see if I am not doing something horribly wrong :)
<Sinbad> hehe, always a good idea
<kandhalt> Sinbad, ok I see. Everyobject can override  the vertex_program for the shadow_maps, so in the object material pass I will have two passes, one with the shadow_caster_vertex_program_ref, and a second pass with my rendering conf to draw the object?
<kandhalt>  (so in the object material I will have two passes, one with the shadow_caster_vertex_program_ref, and a second pass with my rendering conf to draw the object?)
<Sinbad> nono
<Sinbad> the material for rendering to the screen is completely separate from the material used to render to the shadow texture
<kandhalt> yes that's what I was trying to explain
<kandhalt> at first
<kandhalt> but
<kandhalt> this separate material
<kandhalt> must be the same for every object that will be a shadow caster?
<kandhalt> (sorry for my bad english)
<Sinbad> ah, I see where you're coming from
<kandhalt> :)
--> efkoj (i=efkoj@d5152052A.access.telenet.be) ha entrado en #ogre3d
<Sinbad> ok, I guess this can look a little odd
<efkoj> hello guys
<Sinbad> but, the shadow_caster_vertex_program_ref is really just providing a linkage from the material used to render to the screen, to the material used to render the shadow texture
<Sinbad> the latter is entirely created by OGRE, it isn't your material
<Sinbad> but you can influence it
<Sinbad> by telling it what vertex program to use when it renders an object that would otherwise be using your material
<Sinbad> so, the shadow vertex program ref goes in your normal pass definition
<Sinbad> and it won't ever get used in normal screen rendering
<kandhalt> aaaaah
<Sinbad> but will affect how the object is rendered to the shadow
<kandhalt> now I understand
<kandhalt> ok
<kandhalt> nice
<kandhalt> I thought that I should define the shadow_caster_vertex_program in the shadow caster material
<kandhalt> ok
<kandhalt> I can define this shadow_caster_vertex_program in each different kind of object material and
<Sinbad> nope, you've got a global shadow caster material you can set, and then a vertex program that can be plugged into it per original material pass
<kandhalt> will be sticked to the shadow_caster material
<Sinbad> yes
<Sinbad> which can either be the OGRE-created one or your custom one
<kandhalt> nice
<kandhalt> perfect
<Sinbad> that's why the API makes a point about needing to make them compatible
<kandhalt> that is not a problem ;)
<Sinbad> cool
<kandhalt> thanks
<kandhalt> now I fully understand how it works
<Sinbad> np - it was originally created to deal with hardware skinning but clearly works for any custom shaders
<kandhalt> yes I'm using it in fact
<kandhalt> but until today with only one kind of shadow caster objects
<kandhalt> now I understand how to use it in general
<kandhalt> thanks
<Sinbad> you're welcome
<kandhalt> It's noticeable that you played alot with this shadowing interface it's flexible
<Sinbad> it caused me some serious headaches to deal with all the variations, but it got there in the end :)