Hi. I decided to go the uniform way as it fits EffectCompositor easily. Source code of applying materials to nodes: http://goo.gl/PmJaif Pipeline XML: http://goo.gl/KCU7Qt Materials XML: http://goo.gl/BtV7Gt Result: http://youtu.be/Jjk0mlmoB2c
This seems like a fine way to specify object materials relative to the used pipeline, because separate pipelines with materials allow for easy video setup changes (low, medium, high), easy theming (different material sets), etc.. Any ideas? Thanks. 2013/11/7 Sebastian Messerschmidt <[email protected]> > Am 07.11.2013 14:04, schrieb michael kapelko: > > I was thinking of creating some sort of material.xml and assign it to > each object (or a group of objects). > > You could totally do this. So material.xml could contain the defines. > > As far as I understand, the define approach creates one shader per > object eventually. And that turns out to be faster than one shader per > pipeline with different StateSets and uniforms per object. > Am I correct? > > Partially. It eventually creates one shader program per node. There might > be different statesets after all. As the shader-program is part of the > StateSet. > The thing saved here are the uniforms (in my case there where around 50 > non-material/camera related uniforms just for controlling which > rendering-paths are taken) > > > > Thanks. > > > 2013/11/7 Sebastian Messerschmidt <[email protected]> > >> As this is company code and part of a bigger framework I can only give >> you some hints. >> >> I have a custom shader loader which parses the shader source in order to >> later add the defines and creates a osg::Program derived class >> e.g. CustomProgram. >> >> In GLSL you can use preprocessor macros like in C. >> So you can say: >> >> #define PATH_1 >> >> and later >> >> vec4 color = vec4(); >> #ifdef PATH_1 >> color = vec4(1,0,0,0); >> #else >> color = vec4(0,0,1,0); >> #endif >> >> So the shader loader will create the CustomProgram which holds a list of >> defines which should be applied later. >> The CustomProgram itself will do this in the ::apply function, by >> injecting the #define %DEFINE_NAME% in to the shadersource before compiling >> it. >> >> For setting the defines at the statesets you want, you can simply check >> the stateset for a program-attribute, cast it to CustomShader and add a >> define. >> You will have to do some management inside the CustomProgram to make it >> aware of changed define-sets etc. But it the end you are simply adding some >> custom attributes to control the compiled shader program at the state set, >> instead of setting uniforms directly. >> While this seems complicated it allows for two things: >> 1. Fast less-branching shader code >> 2. Different sets of shaders realizing rendering based upon defines. In >> my case I can do deferred and forward shading with the same framework >> without having to know which one is running under the hood, when assigning >> materials/material effects. >> >> cheers >> Sebastian >> >> Can you please provide an example of how an object manages its >> define-set? >> In my case, I simply get the object's StateSet and setup uniforms. But I >> don't get how to setup defines. >> Thanks. >> >> >> 2013/11/7 Sebastian Messerschmidt <[email protected]> >> >>> Am 07.11.2013 12:55, schrieb michael kapelko: >>> >>> Hi, Sebastian. >>> >>> So you compose one shader per object? >>> >>> No, one program per define-set (e.g. #define NORMAL_MAPPING,#define >>> PARALLAX_MAPPING, ...) >>> The idea is not to compose the shader from functional blocks, but to >>> write one shader containing all paths which are activated based upon the >>> defines. >>> It is still complicated to get all the paths correctly in the >>> ubershader, but i found it a good transition from uniform based >>> de/activation. >>> >>> So you will end up with N different programs with N being the number of >>> define-combinations used. >>> >>> >>> >>> Thanks. >>> >>> >>> 2013/11/7 Sebastian Messerschmidt <[email protected]> >>> >>>> Hi Michael, >>>> >>>> I solved a similar problem by overriding osg::Program which composes a >>>> shader from an Ubershader. This is not done via uniforms but defines. >>>> It seems to work somehow and improved the performance over branching >>>> based on uniforms. >>>> >>>> >>>> Hi. >>>> >>>> I decided to go with single pipeline that provides big shaders and >>>> objects using own uniforms and textures to change the pipeline behaviour. >>>> I started to design a simple material format so that it resembles the >>>> one of EffectCompositor. >>>> >>>> Thanks. >>>> >>>> >>>> 2013/10/31 michael kapelko <[email protected]> >>>> >>>>> Hi, Wang. >>>>> >>>>> I've just checked if I can use some uber shader and control its >>>>> behaviour per object by setting the object's uniforms. And it works. >>>>> I wonder if that's ok to do that to make different objects rendered >>>>> differently in the same scene. >>>>> Thanks. >>>>> >>>>> >>>>> 2013/10/31 Wang Rui <[email protected]> >>>>> >>>>>> Hi Michael, >>>>>> >>>>>> Effect compositor in fact adds the child scene graph to a camera >>>>>> binding to a FBO, and then uses RTT cameras to perform the post >>>>>> processing >>>>>> work. The last step is always to show the final image on an HUD quad so >>>>>> all >>>>>> other scene nodes will be occluded. The only way to make the effect >>>>>> compositor work with other fixed pipeline nodes is to write to the depth >>>>>> values in the shader code of the last step, which cannot be automated. >>>>>> >>>>>> The dof.xml does such work so you may try ./osgeffectcompositor >>>>>> --normal-scene cessna.osg --effect dof.xml to see how normal and deferred >>>>>> shaded objects are merged. At present I haven't had a better idea about >>>>>> this problem. :-) >>>>>> >>>>>> Wang Rui >>>>>> >>>>>> >>>>>> >>>>>> 2013/10/30 michael kapelko <[email protected]> >>>>>> >>>>>>> Hi. >>>>>>> I've recently implemented deferred shading with normal mapping and >>>>>>> shadow mapping using EffectCompositor, but it has effect on the whole >>>>>>> scene, not a single object. >>>>>>> Is it possible to use EffectCompositor to apply effects per object? >>>>>>> Thanks. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> osg-users mailing >>>> [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 >>>> >>>> >>> >>> >>> _______________________________________________ >>> osg-users mailing >>> [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 >>> >>> >> >> >> _______________________________________________ >> osg-users mailing >> [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 >> >> > > > _______________________________________________ > osg-users mailing > [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 > >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
