Hi Robert, hi others, I am currently working on image processing pipelines based on GLSL shaders. Currently we have many different special effects (shaders) but all of them work encapsulated. May we should also think on other topic while overwork the shader composite idea. i review the osgvirtualprogram example, and i am not sure, but believe - in this example the whole idea is presented of the new shaders with virtualprogram. what i am wondering is there also a concept how we can use different shaders in a pipeline. for example (i am hard working on Screen Space Ambient Occlusion) and it's all working based on osgFX. But the pipeline needs different FBO (RTT steps) in a pipeline. (1) Render the whole scene with depth/normal rendering (RTT 1) (2) Process the RTT 1 with Ambient Occlusion Filter (3) Render Shadow into RTT 2 (for example Parallel Split Shadow Map with 4 Maps == 4 Renderings) (4) .... (x) Bring all together and so on
In some case we have the same scene (object 2 render) then we can use virtual program, right? but how can we get the pipeline controled, it would be nice getting a rendering pipeline functionality in the shader -> render into gpu memory and store it (array) and bring it in last shader back and blend it. We will have final rendering. Would this be possible or is this to complex to get osg support in controling it? /adrian 2010/6/30 Robert Osfield <robert.osfi...@gmail.com>: > Hi Roland, > > On Tue, Jun 29, 2010 at 10:22 PM, Roland Smeenk <roland.sme...@tno.nl> wrote: >>> 1) Provide a way of encapsulating all the details required to >>> contribute a single chunk of functionality that will be combined with other >>> active ShaderSet to provide final composed osg::Program. >> >> Isn't this what I solved with the ShaderMode class? > > I believe ShaderMode and ShaderSet are pretty close in concept, the > fit a similar role and functionality granularity. Implementation and > usage wise they differ, but they have lots of similarity, i.e. they > are both big cats, but ones a tiger and ones a lion. > > >> Or is it that you are trying to separate the shader mode associated with a >> StateAttribute from the part that is responsible for adding of the piece of >> shader functionality. > > My currently thought is that the various StateAttribute subclasses > would provide a standard ShaderSet instance that implements their > functionality, but also make it possible to override this standard > ShaderSet with custom ones. For instance we might have a standard > implementation of osg::Light, but we also want to enable users to have > their own implementation, by just providing their own > MyCustomPerPixelLightShaderSet. > > There might also be cases where a osg::StateAttribute subclass might > dynamically decide which ShaderSet to use depending upon how it's > configured - this would be if we wanted to reduce the number of > uniforms by having more pre-configured shaders. > >> In my contribution I implemented a single ShaderMode that implements all >> fixed function lighting possibilities. For new types of lighting it seems >> more logical to indeed make a more fine grained breakup of ShaderModes. >> >> However there's a (minor) advantage to this "one size fits all" lighting >> code currently. To enable or disable lighting you simply can override a >> single mode. In the case where there are multiple lighting modes >> (directional, spot etc.) overall disabling of lighting needs to be done per >> lighting type. It might be needed that multiple ShaderSets implementing the >> same aspect/feature can be switched on or off all together with a single >> override. This will also be needed for instance in shadow map creation where >> in the first pass you would like to render geometry into a shadowmap as >> cheaply as possible and therefore without lighting. >> Perhaps multiple ShaderSets implement a the same aspect/feature in the final >> program that need to be disabled or enabled collectively. Again in the case >> of shadowmap creation you would like to only render geometry, no texturing, >> no lighting, no fog, but you do want to take into account skinned mesh >> deformation, wind deflection etc. > > I don't yet have any concrete plan on how to manage the case where > multiple GL enums control particular features. It might be that it'll > be best to map some of the controls to uniforms that enable one to > toggle features on/off such as lighting, but it might also be that we > it could be best to just pass the all modes on the StateAttribute when > asking for the appropriate ShaderSet to use and let it decide what to > use. > > This type of issue I expect to fall out of experience with > implementing various fixed function functionality such as Lighting. > > >>> 3) The ShaderSet would contain list osg::Shader objects, these osg::Shader >>> objects would target which ever part of the overall program that the >>> ShaderSet effects - be in multiple osg::Shader for vertex programs, one of >>> vertex program one for fragment, or any combination. >>> >> >> I guess you are more targeting shader linking instead of the code generation >> that I implemented. > > Yes, I believe preferring Shader linking over Shader code generation > will lead to better performance, more reusability and easier > management. > > One of my plans will be to come up with a ShaderSet file format that > will be a subset of use the osgDB serializers to provide > .osgt/.osgb/.osg support. This file format would contain the existing > serialization for osg::Shader objects, and add the small part of code > injection that we'll need. > > I also want to be able to map this ShaderSet configuration to a C++ > source file as well so we can prepare our ShaderSet just be editing a > configuration file and do quick runtime testing, then when we're happy > with the shaders setup we'd encode this ShaderSet into a .cpp which > then provides the default implementation for a particular > StateAttribute subclass. I took this approach with the shaders in > osgVolume, being able to edit a file and then re-run the application > we really effective at cutting the time it took to perfect the > shaders. > >>> The individual osg::Shader objects could also be shared by multiple >>> ShaderSet where appropriate. >> >> It could, but is this likely to happen? > > We'll find out once we start implementing the fixed function pipeline > mapping, but since sharing osg::Shader is already supported in > osg::Program providing this capability will effectively be free ;-) > >>> 5) It might well be that some StateAttribute have unifoms but no ShaderSet, >> >> I see no logical use case for this. What need is a uniform if there's no >> ShaderSet using it? > > I am thinking of cases where you might want to have a global setting > that is used in the shader mains, or a global setting that various > separate ShaderSet utilize. > > >>> it might also be appropriate for some StateAttribute to have no uniforms >>> and a ShaderSet. >>> >> >> Like the normalize in the fixed function pipeline? > > Yes, I believe this is a good example. > >> >> Some other notes: >> >> Like I discussed before I still would like to emphasize the need to be able >> to tune performance by balancing between shader program size and number of >> program switches. There is no optimal solution before knowing the actual >> usage scenario and therefore a user or internal OSG balancing system should >> be able to adapt this balance to improve rendering performance. > > I think this tuning of performance should be possible with the > approach I've discussing in this thread, however I don't want to get > bogged down too much by optimization right now as the task is complex > enough as it is. Once we have an implementation that is working, and > has the flexibility for us to customize things at runtime and enables > state sorting and lazy state updating then we will have a solution > that is reasonably efficient to start with be leave the door open to > later optimization. > > I believe optimization will have to be lead by performance testing > across database types, hardware types and drivers. I don't want to > make assumption early on about what will and won't be an issue. We > need an base implementation before can start doing any testing so this > will be my focus for now. > >> A thing not solved in my ShaderModes based implementation is support for CPU >> side calculations needed by the simulation or renderer. This includes >> intersection testing and bounding box calculation. When implementing a new >> piece of shader functionality (for instance wind deflection) is typically is >> not hard to implement the same on the CPU side. If there exists a mechanism >> to make the intersection visitor walk through the same ShaderMode tree (or >> linked ShaderSets) it could made be possible to actually intersect a tree >> swaying in the wind. > > Ooo I hadn't thought about providing a mechanism for computing vertex > positions on the CPU, but this would be very very useful for the > quandary of using shaders to modify the vertex positions dynamically. > The mechanism would need to know the uniform state and the ShaderSet > that are relevant, so the StateAttribute might be the place to couple > this. Or perhaps the IntersectionVisitor etc. could accumulate > StateSet's and pick out the StateAttribute that effect the vertex > position. > > >> To clearify the aspect/feature override part mentioned above here's a >> different use case I have in mind. In a scene where it is raining you >> typically would want to show all material as being wet. This can be >> implemented at several levels of realism. For a quick start I would increase >> specular reflection and maybe darken diffuse in the top level StateSet. The >> darkening of materials could be made different for several materials in the >> scene simply by setting a different uniform darkening value. Some objects in >> the scene might implement wetness with a specular cubemap. In case of a road >> it might even contain puddles and use a planar reflection of the scene. All >> these shader pieces implement the aspect "wetness" in different ways, where >> higher fidelity implementations lower in the scene tree override the default >> implementation in the top level stateset. And in case you want to disable >> "wetness" for the whole scene it should be possible to do so at the top >> level stateset similar >> to how we are used to disable texturing, lighting etc. > > This will be an interesting usage case. Once we have an basic > implementation in place we could start testing just how capable it is > by testing harder usage cases such as the above. I've talked a lot > and don't even have anything that can run yet, so I'll have to just > keep my sights set for doing simple stuff like lighting and texturing > first. > > Robert. > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- ******************************************** Adrian Egli _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
