Hi Tim, On Tuesday 17 March 2009 19:58:02 Tim Moore wrote: > That needs to be handled in the shader program. The OpenGL fog parameters > are available as uniforms in shaders. Sure, but you need to rewrite that in every shader? Sure, that is the was OpenGL/OpenSceneGraph does this.
> > How does this interact with the proposed changes of Robert Osfield to > > plug together shader programs from some fixed pipeine state attributes > > together with custom parts of the scenegraph user? > > Did you follow this discussion on osg-users? > > I have been following that. I think that work applies to a situation where > you don't have a fixed function pipeline anymore -- like in OpenGLES 2.0 > and OpenGL 3.x -- and want to keep OSG programs that use state sets > running. Eventually, as we use shaders more ourselves and want to run in > these new environments, we'll need to worry about being compatible, but for > now it's not an issue. Hmm, My impression was that OpenGL 3.0 was the starting point for that thoughts. But the consequences, that you can plug together your shaders from predefined components and replace only those components that need to be replaced is a critical thing for shader use. And this is currently a huge problem with OpenGL I think. >From my point of view, once shaders are in use, the fact that you have to replace the whole pipeline forces you to either: * reimplement all the same common stuff in each shader that is in use. Which is a maintainance nightmare if you want to change something here. * or reinvent such a shader component thing yourself which is a huge amount of work to get right. Both is not nice to do! Which one is your choice? So my impression was that Robert started thinking about something that makes such a component wise shader structure happen. So, all I think is that we should keep the eyes open to not end with something that we cannot handle in the longer term ... OTOH, I see that people want to make use of that nifty shader thing... Sure ... While OpenGL 3.0 started to move things into a direction that brakes compatibility, that comment on OpenGL 3.1 changing again an a non OpenGL whateverversion compatible way made me frighten ... So, I see very well, that this kind of changes need to happen, especially when you know how a gpu works and how bad the legacy OpenGL api is in terms of implementation and partly runtime complexity to map that api onto such a hardware. But .... *sigh* Greetings Mathias ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
