|
Ah! That's excellent, it should have the desired effect of greatly
simplifying the drawImplementation function. The benefit of the "Geometry3" idea is that I could code it up and get it running quickly, thus meeting my clients' desires to have some kind of future-proof path forward, without having to wait for a OSG3 branch and formalized API plugin architecture. But it seems that moving to a deprecated GeometryWithIndices would have the same effect. Alternately, as you've read, I'm researching ways to use the existing Geometry class in a future-proof way. Paul Martz Robert Osfield wrote: 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 |
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
