2012/4/4 Robert Osfield <[email protected]>: > I have a quick look up on the GL primitive restart and understand it a > bit better now. As this feature has to be enabled/disabled using > glEnable/glDisable it naturally would be an StateSet::setMode() rather > than something embedded in a DrawElements. The > glPrimitiveRestartIndex call is also something I would be inclined to > put in it's own dedicate StateAttribute as it's likely to be something > that one would set to a particular value for a subgraph and not change > it. When working to get the best performance out of OpenGL is crucial > to minimize the number of separate glEnable/glDisable and other OpenGL > calls that change the state machine, the OSG manages this by having > fine grained lazy state updating so the setMode and custom > StateAttribute suggestion here would take advantage of this - whereas > putting these in DrawElements work break this lazy state updating > facility and lower performance. Putting the mode changes into an
Well, the methods I added to osg::State do lazy updating - a StateAttribute would of course increase performance... but see below for the problems... A dummy state which just affects sorting of the leafs would give the same advantages, without the problems. > DrawElements would also leave the door open to mode changes being done > within a display list which will break the lazy state updating > mechanism and lead to state leakage. I believe the same dummy state would help to avoid that too, no? > Using a custom StateAttribute for glPrimitiveRestartIndex would > however cause problems for code that parses DrawElements without > knowing that there is a special index embedded it in. To handle this > one would need to watch out for this custom state attribute and mode > in the parental path and then it's it's value when parsing the > DrawElements. And this will cause problems all over OSG... suddently all functionality which deals with the geometry of primitive sets (intersection visitors, kd trees, exporters) will suddently need to accumulate the State when traversing graphs... and crash when the code wasn't written with that in mind. I don't think that this is a realistic approach... My changes just add new pure virtual functions to the respective functors - the compiler then tells you when you need to extend your code to primitive restart. And a primitive set still completely describes it's geometry - independent of the state used to render it. I believe that's a very nice thing to have... Cheers, Felix _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
