Hi Wojtek, J-S et al, Thanks for sharing the code Wojtek. It is always nice to see production code that does the job. What a coincidence, right now I am experimenting with embedding custom modes (including Your osgShadow) and shader composition directly in a cull traversal. Definitely I will take a look at Your code. IMO the ubershader is not the way to go, OSG should focus on more distributed approaches like the one You presented.
I wrote StateEx in ShaderGen to get access to protected members of osg::State. In the past osg::State was not used outside of cull/render stages. Since shaders came into play it is more often abused :). Regards, Maciej 2009/5/11 Jean-Sébastien Guay <[email protected]> > Hi Wojtek, > > I am glad I have Your support. Honestly, I was counting on You ;-) I am >> not that fluent in English as I would like to be. Writing such posts usually >> take me much longer than in may native polish, I often realize that some >> ideas got lost in the midle of batlle with proper word/expression selection, >> so its always good to have some support from native speakers ;-). >> > > Actually my native language is French, but I learned English at a very > young age so I'm pretty fluent. Thanks for the compliment, I'm glad to help > and when the functionality is something I've wanted for a while I'm even > more glad! :-) > > Look at StateHack class and reinterpret_cast<StateHack> expression in >> VirtualProgram apply. >> > > Wow, how did I miss that? :-) > > StateHack overrides osg::State class to make getAttribureVec method >> accessible to Virtual program. This method is protected or private to >> osg::State. >> Obiously this could be solved by mamking VirtualProgram a friend of >> osg::State but that would require changes to core OSG. >> > > I've actually seen such a class a few times in the past few months (one in > the osgUtil::ShaderGen class (cpp file, class called StateEx). That, to me, > means that perhaps the osg::State API isn't as flexible as it could be (or > perhaps it was ok in the past but now it needs to be evolved in new > directions). Robert, any comments on this? > > Obviously exposing osg::State's internals wholesale would make it easy for > users to muck things up, but two cases of overriding it to provide access to > some of its private/protected methods/data tells me that it might be nice to > think about a cleaner way to provide this access? In both cases, the methods > are just getters so perhaps they could be safely added to the API (or in a > slightly modified mode)? > > Hoping to see this move forward, > > > J-S > -- > ______________________________________________________ > Jean-Sebastien Guay [email protected] > http://www.cm-labs.com/ > http://whitestar02.webhop.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
