Hi Rui, Great timing. I've been wondering about the value of developing a high level scene effects library for the OSG that would sit between the viewer and model scene graph to enable effects such as you've mentioned that take advantage of viewer level threading as well integrate with existing OSG effects like libraries like osgShadow. I haven't got to the point of spec'ing up what form this library might take, let alone getting down to the design and prototyping stage so I suspect you'll be further along than myself on it so look forward to hearing more about what you are proposing/working on.
Getting these feature in for OSG-3.2 might be possible but personally I'd like to get 3.2 sooner rather than later so would suggest aiming for after 3.2. However, as much as I wanted to get 3.2 out already my work and personal life have rather swept me off my feet in the last six months so getting on to 3.2 has taken me rather longer than I ever wanted... Over the next week I'll be taking stoke of all my outstanding work and what is planned for the next few months so will have a think about 3.2 as part of this. I can't make a 3.2 without the community so it's something will need to fit in with availability of others as well. For now I'd suggest just concentrate on your proposals and if they fit into 3.2 time frame than all good, if not no worry, we can just aim for 3.4. Cheers, Robert. On 21 June 2012 09:53, Wang Rui <[email protected]> wrote: > Hi Robert, hi all, > > During the past few days, I was thinking of implementing a resource system, > as well as a rendering structure which could support both forward and > deferred rendering for OSG. This could help developers design complex > materials and effects, test cutting-edge GPU techniques, and implement > multi-pass / deferred rendering pipelines with user-friendly interfaces or > even a readable script format. Similar work were already done in some game > engines like Ogre3D, CryEngine and Unreal, and I now plan to work out > something with the same power and can fit our OSG users much better. :-) > > My initial thoughts are: > 1. A resource system records all the resource used in the rendering > pipeline, including textures, state attributes, shaders, uniforms, camera > parameters, and semantics (not used in GLSL, but very useful IMHO). Resource > can be referred by other resource, or obtained from APIs to be altered. It > can be recorded in an XML-based format for reading/writing, > and external uses. > 2. A rendering framework uses one or more techniques, passes, and connect > their inputs/outputs for complex render work. It can also be recorded by the > resource system and is implemented as a group node in the scene graph, > which performs actual forward/deferred rendering work. > 3. Some in-built techniques and passes can help implement some complex > effects on customized scene quickly. Common ones I planned include HDR, > SSDO, godrays, depth of field, motion blur, lensflare, color grading and > FXAA. A benchmark could be developed first to show how the framework works. > 4. Reader/writers could be developed then to convert DAE, CGFX, or even > other game engine scripts into OSG native rendering pipelines, which will > greatly help migrations from other engines. > > The resource system itself is actually abstract and can be extended to > contain whole scene information later, so it could be placed in the osgDB > library. And the new rendering pipeline, which can totally replace current > osgFX functionlities, can be placed in osgFX and rendering resource > management will be done here, too. > > I'm glad to work with others who has interests in such an idea, and hope an > initial version could be finished before OSG 3.2. For the first stage I will > borrow some code from the osgPostEffects library in my experimental osgXI > project, to quickly build the low-level APIs of the framework. But anyone > who have better ideas, or could contribute some code or effects will be > really appreciated. > > Cheers, > > Wang Rui > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
