Hi J-S! > Yes, Wojtek mentioned about a week ago that this was an oversight on his > part, so please submit the whole modified file to osg-submissions. >
Done. > > Also it would be nice having a chance to using the existing shader code > > in a derived class and just add new functions i.e. for bump mapping > > without cut and paste the shader source code. > > > > I suggest putting all the functions in separate shaders and leaving just > > a minimal main() function. > > > > All shaders could go into a vector of shaders being loaded in the init > > function. This way it would be easy creating additional shaders (shader > > functions) and just slightly modify the main() function. > > > > Is there any maintainer of the code? Otherwise I would try to do the > > alterations myself. > > I would advise against doing this, for the simple fact that it would be > an interface specific to that class, whereas other classes that need > shaders might do things differently. I think it's easier to just set the > shadow technique's shaders to NULL, and set whatever shaders you want on > the scene. Note that you can also set shaders anywhere in the graph, so > you could have nodes without normal mapping, others without shadows, > etc. so setting all types of shaders on the shadow technique itself > doesn't really make sense. Yes, I see your point but I don't agree. Hardcoding a shader in a shadow technique isn't a better way at all. It leeds to the same problems you take for argument against my proposal. On the other hand it forces me to cut and paste the code into my derived class and I will njot profit from any improvements (like my submission for specular lights). So I'll do it for myself only. > > Eventually shader composition will be available in OSG, and we'll be > able to hopefully have a coherent interface for adding and overriding > shader parts in the scene graph. Until then I don't think it's useful to > change this. I'm doing commercial projects and I need this functionality now. So I have to do it, at least locally here. Having shader composition would be REALLY GREAT!! Is there any estimate for availability? I have a question in general: It is my feeling that shaders should not be seen as part of shadow techniques. Doing shadows is just on of many aspect for shaders. And in principle for most shadows they do the same job independent of shadow technique. They get a shadow texture and use it for manipulation of colors. So why shouldn't a shodow texture generated by any derivative of StandardShadowMap produce soft shadows? It is just a shader function. So having a nice "general purpose shader" providing functions for shadow, soft shadow etc. in my opinion would be covering most user requirements. Switching functions on and of by uniforms would give the user/developer the real flexibility. Right now I'm facing the problem that any self written shader changes scene optics depending on what shadow technique was chosen somewhere. Any change of independantly written shaders also mostly changes the optics of the scene. We could invest on common improvements, implement bump mapping, fog, vertex manipulation and many more and just switch it on and of by uniforms. I know there is no shader covering every need, but it would be easy to expand functionality either for one self or as submission to the community. In my opinion the shaders of StandardShadowMap are a good starting point. They would also fulfill their job for ShadowMap or even SoftShadowMap (with an additional function). The other techniques I didn't check so far. I'm excited to getting your comments. - Werner - _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
