Hi Paul, Thanks for the insight into GL 3.1. This thread is really about scoping out the landscape for a time when the scene graph has to manage all details of uniforms, shaders and vertex data. The OSG already knows everything about the the matrices, vertex data and shaders/uniforms that are required to driver GL3.1, but... it's obviously doesn't have the rendering backend that manages this right now.
Interesting thing about GL3.1 and similar graphics API's is the high level AP's like scene graph actually become a more important part of managing things for end users than in the GL1-GL2 era graphics API's, so scene graphs will become even more relevant. We do have to expose the functionality effectively though... fitting all that flexibility into fixed function pipeline centric approach won't cut it. Once can't loose sight of the possibility of the rendering back end being done using straight C/C++ or OpenCL rather than OpenGL x.x. A next gen scene graph that does enable these possibilities will be not be as future proofed as it should be. Working out what such a next gen scene graph might look it is one great challenge, the other perhaps even bigger one is working out how we might migrate the OSG code base and users from an OpenGL 2.x centric scene graph to a more generic scene graph that able to be the front end to such a wide range of rendering approaches. Robert. On Fri, Feb 20, 2009 at 4:58 PM, Paul Martz <[email protected]> wrote: > Hi folks -- As a Khronos member, I have some insider knowledge about OpenGL > 3.1, but as the spec is not yet available, I am not at liberty to divulge > specifics. Instead, though, I'll reference the slide set presented at last > year's SIGGRAPH in which it stated clearly and plainly "plan on deprecated > functionality going away sooner rather than later". > > If you interpolate from there, then in OpenGL 3.1 (and GLSL 1.40) and > beyond, the fixed function pipe is gone, and all associated state is gone, > and all predefined uniforms are gone. So, to answer the query "how to access > lighting state from a shader?", you can't set it on the host, and you can't > access it from a shader, because it no longer exists. If you need _any_ > uniform in your shader, you must explicitly create that uniform on the host > and explicitly declare it in your shader. This is the future of OpenGL. > > Also worth noting, glVertexPointer, glColorPointer, glNormalPointer, etc., > are also all gone, and correspondingly, gl_Vertex, gl_Color, etc., are all > gone as well. All vertex data, including the vertices themselves, get passed > to shaders as generic attributes. The modelview and projection matrix > uniforms are gone; you'll need to create them yourself if you need them. > ftransform() is gone. > > This greatly changes the way you think about OpenGL, and about how the scene > graph should work, and how to move forward with OSG. I have some ideas about > a scene graph built on Open GL 3.1. I haven't really finalized them yet, but > supporting the current OSG core API seems unlikely. > > I suggest you wait for OpenGL 3.1 to be released before you make solid plans > for OSG's future. You really need to see the 3.1 spec (and GLSL 1.40) to > know which direction to steer the OSG ship. The 3.1 spec will probably be > out very soon (before SIGGRAPH). > > Paul Martz > Skew Matrix Software LLC > http://www.skew-matrix.com > +1 303 859 9466 > > _______________________________________________ > 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
