Hi Bill, On Fri, Feb 20, 2009 at 4:21 PM, Bill Prendergast <[email protected]> wrote: >> Given this context I was expecting to have to do some high level shader >> composition >> (i.e. in our C++ code) using modes as a guide to know which shaders to >> include in the >> vertex/fragment main shaders. It may be possible to use #define's and >> #ifdef's to >> replicate some of this mode support, but have to admit I haven't explored >> this part of GLSL yet. > > This seems to me to be a perfectly acceptable way to tackle it. If OSG > "caught" every > GL_LIGHTING mode change a user could make and set a uniform at that StateSet > level, then > the emulation shader would function like FFP (in this regard) and have access > to a valid > bool that tracked the GL_LIGHTING mode.
The OSG already trakes all modes and attributes in the process of doing lazy state updating. One could easily extend this is mapping modes to uniforms. Uniforms aren't free though both from the CPU side and the GPU side. The GPU side may actually remove the optional code paths by linking the GLSL program, and in doing so moves the bottleneck to the CPU rather than the GPU. Going the #ifdef route would force a recompile/relink of the GLSL program as well, but potentially one could cache multiple programs to avoid this recompile, so one would just have a bind of a new GLSL program. Given all these variables I'd expect different drivers/hardware to suite different approaches. Either way it's the main() shader that is what will have to manage all this. > The usual warnings come into play, such as a user poking through to OpenGL > behind OSG's > back and making a change to a mode that isn't caught by the uniform handler, > etc. Users directly calling OpenGL directly does complicate things. It might be that we'll need to come up with a specific scheme for integrating OpenGL code that insulates state changes to prevent problems, as right now it's a bit too ad-hoc and requires careful management. -- Another little titbit to add is that I'm wondering about the possibility of decoupling the scene graph objects from the back end implementation completely. This decoupling would mean that there isn't any direct emulation of fixed function vs GLSL going on, simply there are modes and attributes in the scene graph that loosely map to components of functionality down on the graphics card. The rendering backend would then interpret these modes/attributes and work out what rendering code is required to represent them, but it by use fixed function pipeline or composing the required shader fucntion, shader main and uniforms. To achieve this there would need to be a granularity in the scene graph state objects that maps to what will be built in the rendering backend, so one would still have a classes like texgen and associate mode(s), one wouldn't be directly referring to GL_TEX_GEN_ etc. though, rather one would have scene graph modes/enums that we'd manage that insulate the user from the actual implementation. There are of courses cases were you'd specifically want to provide a shader function and shader main, and associated uniforms. In these cases you'd want to craft things in a way as to enable these shaders to be composed by state compositors in the GLSL flavour of rendering back-end. This will require a bit more work on the shader interfaces, but the upshot would be greater flexibility in composing the final state from different components, be it emulated fixed function elements like glTexGen or other shader components. Right now, this is all just pontification on my part. I don't really know how best to tackle this. I know that we'll need to come up with some approach for GL3/GLES2, which we might assume would be a something that would go into a OSG-3.x series. My interest in thinking about this at this point in time is in scoping a little of what OSG-3.x might look like, and how we might guide the OSG-2.x series in this direction little by little. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
