On Sat, Jun 26, 2010 at 12:30 PM, Robert Osfield <robert.osfi...@gmail.com>wrote:
> Hi Tim, > > On Fri, Jun 25, 2010 at 8:37 AM, Tim Moore <timoor...@gmail.com> wrote: > > Is it fair to say that the major interest in shader generation is in > porting > > existing OSG apps to OpenGL ES 2.0, which doesn't have any fixed > pipeline? > > I wouldn't agree with this statement. It's not about GLES 2.0 and > it's not about shader generation relating to just fixed function > pipeline. > > First up, the phrase "shader generation" is possible not too helpful > though in the way that Wojtek phrased it - i.e. relating to just fixed > function mapping. I believe it's better to think of doing shader > composition as mainly linking shaders with a tiny amount of generation > of shader mains, something that applies applies as much to the fixed > function pipeline mapping as it does shader composition which is > entirely user created. > OK, so the "shader generation" or fixed function emulation provides more shaders that might be linked or combined by "shader composition," and the "shader candidate functions" are controlled by existing OSG state attributes? > > It's also not just about GLES 2.0, as OpenGL 3.x and OpenGL 4.x are > also like OpenGL ES 2.0, once we drop the fixed function support than > OpenGL provides we have to provide out own equivalent support or > require application developers to roll their own shaders for > everything, even just viewing something a simple as cow.osg. > > > It's also worth mentioning that all our plugins target the fixed > function StateAttributes, right now under GL3./GL4/GLES2 you have to > do you own mapping from these StateAttribute to your own custom > shaders. > > Right; I'm not personally doing core OpenGL 3.3 or 4.0 programming, but my impression was that the compatibility profile was going to be with us for a long, long time. Are a significant number of OSG users working with the core profiles? > I think right now you go it alone with all shader scene graphs, and > build all your own scene graphs accordingly and ignore all the > NodeKits and Plugins that the OSG provides, but it really won't be > productive for most applications. Until we have a credible way for > mapping fixed function StateAttribute and associated modes to shaders > most application developers will have to stick with GL2. > > Many users are effectively stuck at GL1.1 + hundreds of extensions, including ones that implement the capabilities of OpenGL 3.3 and 4.0. > I also believe that once we get going with shader composition we'll be > mixing and matching lots of different StateAttribute, some provided by > the core OSG, some custom one from applications or 3rd party > libraries, and sometime just overriding the standard shaders providing > by the built ins. If we continue to think about fixed function > pipeline vs shader pipeline as two separate things, and that then I > think we've lost something really important in understanding of the > problem domain, both right now and going forward. I can't argue with that, just wondering if the fixed function emulation via shaders is vital problem to solve at the moment. Tim
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
