On Mon, 2012-09-10 at 22:57 +0800, Wang Rui wrote: > 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,
I'm testing this out, but you appear to have left noise_tex.jpg out of the zip. :) > Wang Rui > > > 2012/6/21 Wang Rui <wangra...@gmail.com>: > > 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 > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
