Re: [osg-users] Primitive Restart
Hi Felix, On 4 April 2012 20:13, Felix Nawothnig felix.nawoth...@googlemail.com wrote: 2012/4/3 Robert Osfield robert.osfi...@gmail.com: Is there any reason why you can't just connect the tri strips together using a repeated indices to create a degenerate triangle that connects two strips together. Of course you can do that - it just wastes quite some memory for indices, considering that automatically generated tri strips usually are just about 5-6 tris long. Using a repeated indices is no more expensive that using a restart index, both require inserting an extra index per new strip. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Primitive Restart
Hi Felix, On 4 April 2012 20:11, Felix Nawothnig felix.nawoth...@googlemail.com 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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Primitive Restart
Hi Frederic, 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 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. 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. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Primitive Restart
2012/4/4 Robert Osfield robert.osfi...@gmail.com: 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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Primitive Restart
2012/4/3 Robert Osfield robert.osfi...@gmail.com: Is there any reason why you can't just connect the tri strips together using a repeated indices to create a degenerate triangle that connects two strips together. Of course you can do that - it just wastes quite some memory for indices, considering that automatically generated tri strips usually are just about 5-6 tris long. For our geometry (30+ million vertices) this really makes quite a difference, after we put the actual vertex data into a highly packed format (3x16bit fixed point position, 3x8bit notmals). Felix ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Primitive Restart
Hi Felix, Is there any reason why you can't just connect the tri strips together using a repeated indices to create a degenerate triangle that connects two strips together. This way you can put multiple tri strips into a single DrawElementUShort and avoid the heavy cost of lots of separate OpenGL calls. Using this approach just requires some post processing of the osg::Geometry rather than changes to the core OSG. The combining of tri strips this way will also perform better and use less memory. Robert. On 2 April 2012 00:25, Felix Nawothnig felix.nawoth...@googlemail.com wrote: Hey. Now comes a non-trivial one... :-) A while ago I added support for primitive restart to our internal build to stitch triangle strips - this greatly improved performance and VRAM usage for our very heavy CAD data. As primitive restart was included in GL core a while a ago I suppose this feature has a chance to be included in OSG. I havn't prepared a patch yet (mostly because I don't want to waste the time in case this isn't going to be integrated anyway), so I'll just outline what I did: - osg::DrawElements and friends got two new attributes, PrimitiveRestart (bool) and PrimitiveRestartIndex (unsigned integer) - osg::State was extended to allow setting the respective GL attributes - The osg::PrimitiveFunctor and osg::PrimitiveIndexFunctor interfaces were extended by a primitiveRestart() and setPrimitiveRestart(bool, unsigned int) method - osg::TriangleIndexFunctor was extended to implement the new functionality ... and all other PrimitiveFunctor / PrimitiveIndexFunctor implementations everywhere were extended to support primitive restart. (I also have a visitor stitching strips which are contained in seperate primitive sets but I did that outside of OSG ... if PS support is included I suspect it might be useful to have a visitor to do this in osgUtil somewhere too) So... should I prepare a patch? Cheers, Felix ___ 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
Re: [osg-users] Primitive Restart
Hi Robert, as I understand it, this feature enables one to put unconnected strips in a single primitive, while degenerated triangles may add a line between the end of a strip and the next. Regards, -Fred - Mail original - De: Robert Osfield robert.osfi...@gmail.com À: OpenSceneGraph Users osg-users@lists.openscenegraph.org Envoyé: Mardi 3 Avril 2012 15:34:02 Objet: Re: [osg-users] Primitive Restart Hi Felix, Is there any reason why you can't just connect the tri strips together using a repeated indices to create a degenerate triangle that connects two strips together. This way you can put multiple tri strips into a single DrawElementUShort and avoid the heavy cost of lots of separate OpenGL calls. Using this approach just requires some post processing of the osg::Geometry rather than changes to the core OSG. The combining of tri strips this way will also perform better and use less memory. Robert. On 2 April 2012 00:25, Felix Nawothnig felix.nawoth...@googlemail.com wrote: Hey. Now comes a non-trivial one... :-) A while ago I added support for primitive restart to our internal build to stitch triangle strips - this greatly improved performance and VRAM usage for our very heavy CAD data. As primitive restart was included in GL core a while a ago I suppose this feature has a chance to be included in OSG. I havn't prepared a patch yet (mostly because I don't want to waste the time in case this isn't going to be integrated anyway), so I'll just outline what I did: - osg::DrawElements and friends got two new attributes, PrimitiveRestart (bool) and PrimitiveRestartIndex (unsigned integer) - osg::State was extended to allow setting the respective GL attributes - The osg::PrimitiveFunctor and osg::PrimitiveIndexFunctor interfaces were extended by a primitiveRestart() and setPrimitiveRestart(bool, unsigned int) method - osg::TriangleIndexFunctor was extended to implement the new functionality ... and all other PrimitiveFunctor / PrimitiveIndexFunctor implementations everywhere were extended to support primitive restart. (I also have a visitor stitching strips which are contained in seperate primitive sets but I did that outside of OSG ... if PS support is included I suspect it might be useful to have a visitor to do this in osgUtil somewhere too) So... should I prepare a patch? Cheers, Felix ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Primitive Restart
Hi Fred, On 3 April 2012 16:21, Frederic Bouvier fredlis...@free.fr wrote: as I understand it, this feature enables one to put unconnected strips in a single primitive, while degenerated triangles may add a line between the end of a strip and the next. You say may add a line, is this supposition or have you seen documented evidence that this can happen? Robert? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Primitive Restart
Hey. Now comes a non-trivial one... :-) A while ago I added support for primitive restart to our internal build to stitch triangle strips - this greatly improved performance and VRAM usage for our very heavy CAD data. As primitive restart was included in GL core a while a ago I suppose this feature has a chance to be included in OSG. I havn't prepared a patch yet (mostly because I don't want to waste the time in case this isn't going to be integrated anyway), so I'll just outline what I did: - osg::DrawElements and friends got two new attributes, PrimitiveRestart (bool) and PrimitiveRestartIndex (unsigned integer) - osg::State was extended to allow setting the respective GL attributes - The osg::PrimitiveFunctor and osg::PrimitiveIndexFunctor interfaces were extended by a primitiveRestart() and setPrimitiveRestart(bool, unsigned int) method - osg::TriangleIndexFunctor was extended to implement the new functionality ... and all other PrimitiveFunctor / PrimitiveIndexFunctor implementations everywhere were extended to support primitive restart. (I also have a visitor stitching strips which are contained in seperate primitive sets but I did that outside of OSG ... if PS support is included I suspect it might be useful to have a visitor to do this in osgUtil somewhere too) So... should I prepare a patch? Cheers, Felix ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
