Hello Werner,
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.
I have always thought of the shaders in the code as being for guidance only. I don't think anyone will use those shaders directly. You have to keep in mind, OSG is not a graphics engine. It is a graphics API, on top of which you develop your own graphics engine. So the shaders in the code show you how the shadow map should be accessed, but they are not general "do all the effects you want in your engine" shaders. You do those yourself.
So IMHO, copying the code from the shadow technique's cpp is not a drawback, it's just part of the process, and it takes 2 seconds. Then you do what you want with it.
I'm doing commercial projects and I need this functionality now. So I have to do it, at least locally here.
I don't think you NEED this functionality. You can do it yourself without any change to the shadow technique classes, as I said just put your own shaders in the graph anywhere - the shadow map texture will be available anywhere under the shadowedScene, so you can use it. That's what we do, and it works great (not as well as shader composition, see below, but it's fine given the current state of things).
Having shader composition would be REALLY GREAT!! Is there any estimate for availability?
It was supposed to be the one big thing that needed to be done for OSG 3.0 to be released, but I think Robert pushed it back because it's been too long since the last stable release and waiting for shader composition in order to make 3.0 is not realistic if we want a stable release soon.
I have a question in general: It is my feeling that shaders should not be seen as part of shadow techniques.
EXACTLY the point I made above. The shaders in the cpp should be used as guidance. Personally I don't even use the setStandardFragmentShader(), setShadowFragmentShader()... methods at all, I just place shaders in my graph so they override the default ones.
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.
Yes, you can filter your shadows the way you like.
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.
This is what an engine would do. But see my comment above, OSG is not an engine.
The problem is that until we have official support for shader composition, different developers will want to implement shader support in different ways. There are essentially two ways: a scene-wide "uber shader" that you control with uniforms, like what you suggest above, or smaller shaders that only do what is needed and are placed in different places in the graph. Depending on your bottleneck, these two approaches will give different performance - the first introduces more branching in shaders, and the second increases the number of times the pipeline will switch shaders, possibly causing pipeline resets/flushes. All the literature I've seen suggests that uber shaders are worse than using smaller shaders where they're needed, as long as state sorting can reduce the number of shader switches to a minimum, but the big drawbacks are code duplication (if you make all shaders be in a single file) or having to manage where you place each shader fragment (if you separate functions into their own files).
With shader composition you get the best of both worlds, because you can write parts of shaders once, and have functions be overridden lower in the graph, without having to place complete shaders everywhere.
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.
Again, OSG is not an engine. It's just not its focus. If OSG wants to stay a thin layer over OpenGL (at its core) it needs to give you more flexibility and not impose any shaders. You, as the app developer, can do things the way you want.
I think this focus could be made to change in the future, but for now there are already many OSG-based engines out there. You can use one of those if you want, or use OSG directly and make your own decisions about how your pipeline is built. I won't comment this focus anymore I think, so if you have further questions about it I'll let Robert answer.
Hope this helps, J-S -- ______________________________________________________ Jean-Sebastien Guay [email protected] http://www.cm-labs.com/ http://whitestar02.webhop.org/ _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
