Hi Wojtek, I will be looking at the VirtualProgram approach as well. I want to look at all the various approaches. I haven't yet looked at GL4 in detail so your prompt is timely, I go pull down some docs and have a review of it.
In terms of the final approach I merge, I would like to retain the flexibility of the OSG current StateAttribute + GL mode approach, this is already a form of state composition that has all the inheritance/compositional behavior that I'd like to see, but we currently rely upon the GL drivers to do the mapping fixed function pipeline to shaders for us. Roland's approach does provide something similar to this, am I'm still learning about the implementation details so can't yet comment in full of how close it gets. I would appreciate others having a look at Roland's implementation as well. Robert. On Tue, Jun 22, 2010 at 12:56 PM, Wojciech Lewandowski <[email protected]> wrote: > Hi, Robert > > I hope you will also look at Virtual Program in shader composition example. > I am not trying to sell the implementation but I really would like to see > shader composition simple and easy to use and I think that VirtualProgram > approach could be seen as such fairly simple interface. > > I was hoping that current osg::Program could be extended to allow incomplete > shaders like VirtualProgram allows. In that case VirtualProgram could be > removed. OSG could solve shader completness in similar way as uniforms are > handled: neccessary uniforms are selected and applied when program is > applied. > > I think shaders could be selected and compiled in the same moment ie when > program is applied and using similar logic and handling as uniforms. We > would need to have the functional name for the shader to select shaders used > by program. That name would work bit like uniform name. It was "semantics" > parameter in VirtualProgram but some other shader names could be used as > well for this purpose. > > And the other subject I think may affect your work are Open GL 4.0 > subroutines. Lets make the shader composition in OSG future compatible with > this concept. > > That are only my 2 cents. I don't want to start any fierce discussion. I > will accept a solution you would select as most appropriate. > > Cheers, > Wojtek > > -------------------------------------------------- > From: "Robert Osfield" <[email protected]> > Sent: Monday, June 21, 2010 7:02 PM > To: <[email protected]> > Subject: Re: [osg-submissions] Shader composition > >> Hi Roland, Johannes et. al, >> >> I've mostly cleared my desk for other tasks so am now ready to dive >> back into the topic of shader composition. My plan this week is to >> dig out my own design notes, and do a review of Roland's submissions >> and experiment with the runtime usage/results of the submission to get >> better idea of the problem domain and the submission itself. >> >> Any updates on the submission or any thoughts on shader composition >> would be most welcome. Once I'm more back up to speed on Roland's >> submission and my collected more of my own thoughts together I'll >> strik a discussion on osg-users about shader composition, but feel >> free to chip in on this thread if you have comments about Roland's >> submission. >> >> Cheers, >> Robert. >> _______________________________________________ >> 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 > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
