Hi Felix, On 4 April 2012 20:11, Felix Nawothnig <[email protected]> wrote: > Well, the methods I added to osg::State do lazy updating - a > StateAttribute would of course increase performance... but see below > for the problems...
Lazy state updating done in osg::State is done using pointer comparisons so is very efficient as you never have to load the contents of object into CPU cache. > A dummy state which just affects sorting of the leafs would give the > same advantages, without the problems. You would have to do an additional check on every primitive set dispatch, this would effect *everyone* who uses the OSG. My suggestion only effects those who use the feature, and even those they would only typically every have the state set once per frame as I can image one using multiple different primitive restart indices. > >> 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? No. If you change state within a display list you don't ever know when it's be change when the display lists is used. >> 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... I've only been working on the OSG for 14 years, I generally am pretty good at assessing what is realistic approach. If I'm pushing back on your suggestion is because it's not something is going to work. If you want to throw back my suggestions then fine. This doesn't change the fact that how you've describe your approach is not something I would consider as workable and not suitable for inclusion into the core OSG. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
