Hi J-S, Wojciech, Thanks for the help. I've got shadow maps working (I'm on 2.6.1) and when I get round to it, I'll migrate up to the 2.7 ViewDependant stuff and see if I can get the other techniques working as well.
> Now, an add-on library could be written that would help unify the art > pipeline. Things like models, textures, mapping of textures to texture > units, shader management, shader generation from chunks of shader code, > effect management, etc. could be made much simpler and more user-friendly. > But as I said, I don't think it's OSG's job to do this. OSG provides a > framework, and this is a bit too domain-specific IMHO. > > Regarding shader management, I think that it *would *be appropriate for OSG to provide something here. ( Obviously I realise that this is a large amount of code - I'm arguing about the appropriateness, not actually demanding that someone provide it ! ) The reason is basically that as fixed function falls away, shaders become more important, and the relationship between the scenegraph and the shader becomes much more like the relationship between the scenegraph and the state. For example, the 2.7 shadow library does a fantastic out-of-the-box job of providing a sort of uber-shader that tries to handle a variety of effects (various sorts of lights, multiple lights, diffuse texture etc.). However, throw that at a model that already has shaders on it, and you end up having to copy-and-paste the shadow shader into the models' shader. This gets more complicated if the various shadowed objects have different shaders, and this is the situation I have. I fear that bugfixes and so on to the complex shaders in osgShadow will end up with my object shaders being out-of-step, and therefore producing hard to pin-down errors in the result. (shader debugging is awful). Thinking aloud, I wonder if some sort of text-based accumulation of functions that are passed down the scenegraph, with assembly and binding at the level they are actually required, would be appropriate. For example, the shadow shader could just be a stub e.g. a "float CalculateShadow()" function that objects that are shadowed need to call if they want. A couple of specific things: 1) I admit I haven't looked properly at the 2.7 osgShadow, but does it handle LOD nodes within objects? 2) Although not relevant to me right now, in case the depth-only vertex shader gets implemented (at the moment it appears from the comments that fixed function has been found to be faster) it might be useful to be able to override osgShadow's depth-only vertex shader, - the object might in some cases be being dynamically transformed during shadowing (e.g. character animation). Anyway, just my 2p. Thanks (all involved) for all the work on the shadow libraries. David
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
