Jean-Sébastien Guay wrote:
I bet it wouldn't be too hard to add apply(osg::Camera& camera) that would set view and projection matrix uniforms, as well as apply(osg::Transform& transform) for the current local-to-world matrix (and perhaps uniforms for model*view, model*view*projection for convenience).Good thought. I've been mulling ways to set local2world, view, normal, and projection matrices in a manner non-intrusive to app code. Unfortunately I need to table this while I work on some other stuff, but hopefully I'll resume this work in the near future. Well I think for the basic functionality (vertex positions, normals, vertex colors, texcoords and the normal matrices) an app should not have to change other than modifying its shaders to use new names. OSG is after all a rendering library, so I think we can assume most apps will use this functionality as a bare minimum.Agreed, OSG is a rendering library. So is OpenGL, but OpenGL 3 allows apps to not specify vertices on the host, and instead procedurally generate clip coordinate positions as output of the vertex shader. In contrast, the current Geometry::drawImplementation is a no-op if the vertex pointer is not set. I think we want to allow for apps that don't specify vertices from host code, and forcing the app to call Geometry::setVertexPointer in such a case would obfuscate the code. If an app wants to use only generic vertex attributes, OSG needs to change to allow this. This type of usage (Geometry without a vertex pointer) introduces a new issue, which I alluded to in my BOF presentation: How does OSG cull if the Geometry has no vertices, and therefore no bounding box? setInitialBounds could be a solution, disabling culling on the Geometry is another option. After that we can decide whether we want to keep the current wrapping of fixed-pipeline state (for example osg::Fog) and have it set uniforms when needed.I flip back and forth on this. On one hand, I have clients with large OSG-based apps, and the last thing they want is some kind of disruptive change in OSG. To serve them, I think we really do need to continue to support the old FFP state in GL3. On the other hand, there's a reason why OpenGL ditched the old FFP feature set: Apps that use all the features simultaneously are rare, and testing these features was an O(n^n) problem. Eliminating the features allows for equivalent functionality in much simpler app-specific shaders. If OSG tries to move forward with the old FFP feature set, we will be attempting to do what hardware vendors like ATI and NVIDIA have given up on. As more features are added to OSG, the problem will only get worse. (We already have such feature mixing issues in OSG. Ever try to use osgText with osgShadow? Both nodekits think they own texture unit 0... I've intended to make the texture unit a configurable option for some time now, but haven't gotten to it.) It seems like a "d*mned if we do, d*mned if we don't" kind of problem. But certainly one worth discussing. So I think we have to answer a basic question before we do any actual work: Do we want OSG to be like it was before, and basically become a GL2 layer over GL3? That would make it easier to use than straight GL3 for beginners, I think, but it would make OpenGL programming less hands-on than straight GL3. Of course, if we do it right we can still expose all the GL3 code paths through a thin layer like was done for GL2, so people who wanted to use all the freedom and generality of GL3 could still do so. But OSG would become a good solution for people who wanted an easier way of doing graphics programming than the "programming without a safety net" model that GL3 offers. I personally think this is a great opportunity for OSG to position itself as a great solution that offers all the power of OpenGL 3 but with a gentler learning curve.Excellent points, and well-said. This really is the question. And as I said above, there is existing code that is counting on the old FFP interface continuing to be supported in OSG. I'm currently very interested in researching ways to write apps that use OSG today in such a way that they avoid OSG functionality that is currently implemented on GL 1/2. The idea being, if you write your app this way, then any future changes to OSG aimed at supporting GL3 will be inconsequential. Good discussion. -Paul |
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
