Hi Aurelien
2013/3/24 Aurelien Albert <[email protected]> > Hi, > > @David Callu : > > > > Your main problem is "how to handle fixed pipeline attribute/uniform in > GLSL Core profile?" > > > Yes, but not only. My problem is also to handle application specific > StateAttribute and to allow a way to specify different StateAttribute <=> > GLSL binding for different applications. > ok, so you don't want to emulate FFP but extend or replace them with your own custom StateAttribute/rendering code > > > If you change one attribute, you have to update the entire UBO. > > ModelView matrix change for each drawable, so UBO is updated on each > drawable. > > > I know this problem, but it appears only in the example I've provided, > which is a very simple and not optimized one. > > As you can see in the osg::Pipeline class, all methods are pure virtual, > and the choice to use a single uniform for each StateAttribute or a big > UBO, or a mix between the two (eg a uniform for each matrix and a big UBO > for materials) is made by the developper. > > With this approach, if you need performances, you can create your own > optimized and specific pipeline, which maybe doesn't need to support every > StateAttribute, but only a subset usefull in your application. > ok, nice > I've also try to work with shader generators, but they are always > problematic for me : for example you have to re-run the shader generator > each time you add/remove a texture. > Shader Generator (SG) will assemble many ShaderComponent hold by StateAttribute to generate a final osg::Program. SG could create a map that associate list of ShaderComponent to osg::Program, then create one time and reuse many time the osg::Program generated by a list of ShaderComponent. More over, you can use subroutine function to extract data from a texture or other source. > > With this osg::Pipeline class I can now write a single shader, bound it at > the top a the scene graph (or a subgraph) and it reacts to every state > change (as you can see in my example : the "T" key and the "L" key to > toggle texturing and lighting are still working without any modification in > the EventHandler and without re-generating shaders. > So this is an UberShader solution, one shader could render all drawable in the scene > A shader generator system also often need rendering logic both in C++ code > (to build correct GLSL) and GLSL code (to execute the rendering), which is > more complex to maintain and debug. you're right My main goal here is to provide a customizable way to send all (or a > subset) standard osg::StateAttribute (and customized ones) to the GPU to > allow all the rendering logic to be coded in GLSL. > > As an example, I use this class in one of my application which renders > objects in 2 views : a "standard OpenGL" one (basically a phong rendering) > and a "thermic" one (with different modes : temperature, emissivity... > values which are computed real time or offline from different algorithms). > > So I've defined several pipelines : > - a Phong pipeline (which looks like the one I've provided in the example) > - a "Render temperature" pipeline (very simple : doesn't handle any > texture attribute, or any light source, or any osg::Material...) > - a "Render emissivity" pipeline (very simple : doesn't handle any texture > attribute, or any light source, or any osg::Material...) > - a "Render XXX" pipeline (very simple : doesn't handle any texture > attribute, or any light source, or any osg::Material...) > > And now I can : > - switch between them by simply change the pipeline and change the "main" > shader (at the top of the graph) > - easily open multiple views with the same or different pipelines > - any change on a StateAttribute is immediatly visible in all views > This look like to a custom FFP. One osg::Pipeline/osg::Program per OpenGL Context and you can change the pipeline only at the end of a frame. What happen if you want to render different kind of drawable like - someone defined by traditional Vertex/Normal/TexCoord Array - others defined by Shader Tesselation - others defined by Shader Geometry extrusion - others defined by opengl instancied array - and one particle system update in shader, so vertex position is computed during shader execution all of this in the same scene. And if you want to do some RTT with this scene to generate shadowMap or create mirror image. One osg::Pipeline/osg::Program or one osg::Pipeline/many osg::Program can't handle all this complex drawable case. And After 12 month of work, when you have create a lot of custom osg::Pipeline to handle all you particular rendering case. you need to render a drawable with Openly instanced array, or one defined by Shader Tesselation. You have to update all you osg::Pipeline. This could become a long and borring work. In a near Futur when Shader Generator will be available in OSG, I think that StateAttribute will be derived in many way, and NodeKit like osgLighting will appear and will provide new way to illuminate a scene. This could be - anisotropic light - freshnel effect - BRDF illumination - Cook-Torrance reflection ... new NodeKit osgFog could provide many fog rendering like - OpenGL FFP fog, - Layered fog - Localized fog ... All of this require new osg::StateAttribute that will provide glsl function/uniform to do desired effect. And we can't put them in one big structure. We have to define a way to handle them when their apear without update/rewrite API. Minor change in internal code is acceptable but no more. So We/OSG need a Shader Generator that will assemble many little piece of code/attribute to create one program. The cost of lots of possibility is complexity. This is our work to do this as maintainable as possible but we can't do without complexity. OSG is an example of "extended possibility coul'd not be without complexity". In a design code point of view, this is often more flexible/scalable to use many little piece of code and define few rules to work together than create a big one piece of code that will do all the stuff. Your solution seem to be a good one for usability point of view. But possibility to render complex scene or extend rendering capability without rewrite a osg::Pipeline/osg::Program is not available. David > @Robert : > > > > I will put some time early next week to do a review. > > > Thanks a lot ! > > > > > Cheers, > Aurelien > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=53216#53216 > > > > > > _______________________________________________ > osg-submissions mailing list > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
