Hi J-S, I've got it. Thanks for the clarification. OSG is great work!
- Werner - > 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 _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
