Hi Paul, I'd prefer not to have a separate "Geometry3" class that is only supported by some GL paths, as this would complicate supporting both fixed function pipeline and shaders in one scene graph. One plan I have had for a while is to move all the old vertex index array support out of osg::Geometry and into a deprecated osg::GeometryWithIndicies class, leaving the osg::Geometry class focused on just forwards compatible implementations. This would be a good first step towards adding the named array interface.
Robert. On Mon, Aug 10, 2009 at 5:13 PM, Paul Martz<[email protected]> wrote: > Good info, Robert, thanks. > > Rather than disrupt the current Geometry implementation, I've been > considering deriving a new class from Drawable called "Geometry3", which > would be very much like the current Geometry class, but would be GL3-safe. > This would mean removing the setVertexPointer, setNormalPointer, etc., > methods, removing all the "slow path" indices methods, buffer objects on by > default, and support for the new primitive types. I imagine such a class > could greatly reduce the length of the currently 800-line long > Geometry::drawImplementation, so maybe some performance boost there by > reducing instruction cache misses, not to mention simplifying the code. > > Rather than a separate class, perhaps we could reimplement Geometry using a > factory design pattern for different rendering APIs, GL1/2, GL3, GL ES 1.1, > GL ES 2.0, etc. > > I mention all this because it impacts how vertex attributes would or would > not change. If we were to go with a separate Geometry3 class (factory > pattern or not), we could add the variable name string support only to the > new class, and leave the extant Geometry class interface as it stands. > > All of this is dependent on your plans to move OSG to a plugin back-end to > support multiple APIs. I'm not sure of the design details, but I'd like to > start discussing them. Ideally, the move to support OpenGL 3 would be > organized and coherent; if we all decide to tackle this port with > heterogeneous and incompatible mechanisms, it would produce less than ideal > results. > > Paul Martz > Skew Matrix Software LLC > http://www.skew-matrix.com > +1 303 859 9466 > > Robert Osfield wrote: > > Hi Paul, > > On Mon, Aug 10, 2009 at 3:12 AM, Paul Martz<[email protected]> wrote: > > > Is there no way for an app to associate vertex attrib data with a variable > name string (like Uniforms)? If not, why not? And would you be open to a > code submission that adds this functionality? > > > Yes, there is no currently way of associating vertex attrib data with > a variable name string. This was a deliberate decision based on the > fact that you can't do a query of the name binding within a display > list and still get the correct binding, as the GLSL program can change > independent of the geometries display lists. The bottom line is > variable name strings for vertex attributes are incompatible with > display lists, which hardwired indices work fine either way. > > Fast forward to GL3 and display lists are no longer on the menu, and > one has to use name strings when assigned vertex attributes so both > have one barrier removed and the option to not use name strings > removed from the menu, so we have bite the bullet and go implement > them. To this we'll probably need to add a string name into the > Geometry::ArrayData structure, and interface into osg::Geometry for > setting it, and internal implementation details for setting up the > binding during Geometry::drawImplementation(. > .) > > Robert. > _______________________________________________ > 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 > > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
