Hi functionally it is about same as osgPPU as far as i can tell, but more straightforward and easy to use. I like it :) Was missing ogre-like materials and compositiors when working with osg, tyvm for your work.
10.09.2012, 18:57, "Wang Rui" <[email protected]>: > Hi all, > > Just to announce that the material system is still in progress and > I've just made the first version for myself to test and use. An > optimized version with a complete deferred shading pipeline (XML > files) will be submitted if it could fit most requirements. > > As to share my current work with anyone who are also interested in > this idea and implementations, I'd like to attach the source files > along with this mail instead of submitting it in full fling. If you do > have better ideas, think the work is misdirected or needs to be fixed > in some parts, please don't hesitate to tell me. A second version with > more test files and a detailed XML file introduction will be updated > soon after some days. > > Thanks, > > Wang Rui > > 2012/6/21 Wang Rui <[email protected]>: > >> 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
