Hi Robert Thanks for the answer and thanks to keep OSG on the good way. I will try to follow your rules about "features that all OSG user will rely upon, and niche features that a fair number of OSG users will rely upon".
Don't blame me if I still try to add niche feature, this is not always easy to do the good selection. Best Regards David 2013/6/13 Robert Osfield <robert.osfi...@gmail.com> > Hi David, > > On 13 June 2013 15:31, David Callu <led...@gmail.com> wrote: > > As you say, we need to carefully choose what we add in OSG, > > but I think OpenGL feature have to be add before we need it, > > to be sure that OSG is a fine layer over OpenGL and not a fine > > layer over a subset of OpenGL. > > I don't believe the OSG should try and map all features OpenGL, rather > just focus on the key features that all OSG will rely upon, and niche > features that a fair number of OSG users will rely upon. For niche > features that used by few users we still need to be able to provide a > path to implementing these features on the user side. > > For instance osg::StateAttribute system is extensible as is > osg::Drawable allow users to integrate the OSG with NVidia specific > extensions in the case of the osgNV library, and OpenCL etc. > > Know where to keep the niche features is something we have to > continuously evaluate - once niche features can become mainstream, > while once mainstream features can and sometimes should fall out of > use. An example of the later is OpenGL slow paths such as > BIND_PER_PRIMITIVE and vertex indices that aren't even supported by > modern OpenGL. The fixed function pipeline will eventually go this > way too. > > Being able to migrate things from external to the OSG to core OSG and > back out again is something we will need to do. Sometimes just making > a feature usage may require modifications of the core OSG, even when > the actual feature is implemented external to the OSG. > > I believe this flexibility has helped the OSG over years stay > relevant, unfortunately we've also accumulated a bit of cruft that > needs weeding out - like the slow path stuff in osg::Geometry. > Avoiding cruft building up is also part of why I don't just accept any > feature addition to the OSG, and why you see me pushing back on > threads like this. Often times when I have to easily accepted feature > additions to the OSG it's come back to bite us - with extra NodeKits > that have never quite fulfilled that original purpose and are now > largely orphaned. > > Robert. > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
