Dear J-S, Thanks for the help.
If you're using the ViewDependentShadow techniques, they already disable > shaders while rendering the shadow pass. Ah - I hadn't spotted that in the code yet. So no problems there then. While I'm here, is there any reason why the shaded objects shouldn't do the TexGen in a vertex shader? I would subclass and just add a public getter for the texture since it's > protected. Pretty simple. Sounds like a good idea. > I wonder what the "good architectural reasons" are, but let's not get into > that discussion :-) > No, lets, as you might spot something I hadn't considered. Lets say I have a node representing a mirror, which uses an RTT technique to draw reflections. In a similar way to the shadows, the objects to be reflected are placed as children of the mirror, in addition to their normal position in the SG. The mirror puts various transforms and clips on the reflection, so that the reflected image is correct. Now, the mirror is itself a shadowCaster, as are the objects it is trying to reflect. If I put the objects and the mirror as children of the shadowTechnique node, then the non-mirror objects cast shadows twice - once in their normal orientation, and once in their reflected-child-of-mirror orientation, which is wrong. Thinking about it though, I suppose that setting shadowCast to false on an intermediate node between the mirror and the reflected objects prevents the cull traverse from ever finding them, so they don't cast shadows twice. Sounds right? Although I'm still a bit uneasy about what the mirror might make of the repeated cull traverse attempts... I suppose I had just better try it out rather than blather on and on. ...multitexturing.... Your comments agreed. <soapbox mode> I think that the issue is a little bit more far ranging to manage in a generic application way. For example, the set of incoming models I have to draw unfortunately comes in with texture units all over the place. (e.g. some have diffuse = 0, normal = 1, specular = 2, some have diffuse = 0, specular = 1, no normal). This is in part because file formats that do specify texture types (diffuse, normal, gloss etc.) like obj and 3ds, don't specify which texture unit they should occupy. Openflight, in contrast, specifies which textureUnit the incoming map actually is. Hence we end up with a bit of a mishmash, thanks to not having an art path that is historically well controlled, and receiving assets from various sources. Therefore it is tricky for me to say that texture unit 0 = shadows and 1 = diffuse, because it is hard to guarantee that in the general case. The solution I'm likely to resort to is to say shadow = 7, and then if the model comes in with anything in tex unit 7 then...well.. it has been warned. Can't say that's happened often though. [Although one might be using tangentspace generators to push normals into attributes 6,7,15, which could conceivably get mangled with shadows's texgen (in the case of shadow=7) which means that 7 is a bad choice... and so on.] Not ideal. I would prefer an OSG wide setting that would be user controlled that set up some sort of relationship between default texture types and units(e.g. 0=DIFFUSE, 1=SHADOW, 2=NORMAL, 3=SPECULAR etc.) , so that all the loaders that cared would be consistent (e.g. 3ds, obj), and that the shadow map could refer to, and that any shader set could read sampler2D values from, etc. No idea where this would go, though. </soapbox mode> Thanks again for the pointers. David
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
