Re: [osg-users] large VBOs for multiple Drawables
Paul Martz wrote: On 5/6/2011 4:05 AM, Fred Smith wrote: You usually want to create GL batches that are as large as possible. 10 draw calls of 100 elements will be slower than 1 draw call of 1000 elements. Something else I have noticed a little while ago was that the stateset processing engine of OSG might be slow. One thing I have been surprised with was the performance with a scene graph containing just empty statesets on drawables vs. no stateset at all. Just having empty statesets decreases perf quite a bit, eg. just by calling getOrCreateStateSet. osgWorks.google.com contains the CountStateSets visitor, which will remove empty StateSets, just for this reason. -Paul OSG is a great piece of code, don't get me wrong - but I see a weakness here. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39193#39193 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] large VBOs for multiple Drawables
On 5/9/2011 5:49 AM, Fred Smith wrote: OSG is a great piece of code, don't get me wrong - but I see a weakness here. What, exactly, does that mean? -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] large VBOs for multiple Drawables
It means that there seems to be a cost in doing state changes with OSG. GL state changes do not necessarily incur any cost - this is implementation specific anyway - whereas OSG state changes seem to always incur one, as even going through empty statesets does incur a cost. Is that clear enough for you? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39204#39204 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] large VBOs for multiple Drawables
Hi Fred, On Mon, May 9, 2011 at 3:42 PM, Fred Smith osgfo...@tevs.eu wrote: It means that there seems to be a cost in doing state changes with OSG. Indeed there is!! It's written to be lightweight, using pointer rater than content comparisons where possible, but you can't ever disappear CPU cycles completely. This work that the OSG does on state is to minimize the number of state changes sent to OpenGL, so while there is a higher CPU cost, the GPU cost is lower. GL state changes do not necessarily incur any cost - this is implementation specific anyway - whereas OSG state changes seem to always incur one, as even going through empty statesets does incur a cost. Some GL state changes are relatively lightweight, but since any GL call overhead itself is not cheap, avoid GL calls is worth the effort, and some GL state changes are hugely expensively. The OSG does state sorting and lazy state updating to make sure that the graphics is sent to the GPU as efficiently as it can. As for empty StateSets, the OSG during traversal doesn't know a StateSet is empty until it checks it contents, do so waste time of course, but there is nothing the OSG can do during traversal to avoid this. However, an empty StateSet is a indication of very poorly set up scene graph. Efficient scene graph don't have rendundent StateSet or Node's in the scene graph, the osgUtil::Optimizer contains are plarethora of visitors to help condition poorly balanced scene graphs, so if you do have a problem scene graph the Optimizer is a great tool to utilize as a pre-processing step. Performance problems that end users see are almost always caused by scene graphs that are poorly constructed for the purpose that have been created for, so if you see high update, cull and draw dispatch and draw GPU investigate the bottlenecks with a view to understanding what in your scene graph is introducing the large overheads. The skill of creating an optimal scene graph isn't a trivial one though, it's one of the core skills for real-time graphics experts to develop, a skill that takes many years to mature. I am still a learning, and don't really every expert to stop learning about this as technology continues to evolve at a break-neck speed. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] large VBOs for multiple Drawables
Hi Robert, The stateset performance issue, if ever encountered, can easily be worked around with a draw callback using applyAttribute/applyTextureAttribute prior to rendering every drawable. This is a very slim point where there might be room for improvement, and what you said perfectly makes sense to me. OSG is a library that I like getting familiar with, kudos to you and the community for all the good work. Best, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39209#39209 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] large VBOs for multiple Drawables
Hi All, Paul, I think I've done some of the benchmark you're referring to on my end right before starting this thread =) In my example I replicate the same geometric primitive many times. The geometric object is a little cube counting 40 vertex and 66 triangles all rendered as a single drawElements in batch. I'm using a very basic toon shader to render them, passing vertices, normals and a vec4 attribute array. Here's what I got when I test with 20.000 instances of the primitive when they are all in the view frustum, my box is Win7, i7 920 processor, nVidia 285GTX: 1) 20.000 separate drawables, each with its own VBO assigned. CULL: 11ms, DRAW: ~40ms, GPU: ~37ms Stats are very unstable with this scenario, even when I don't move and with all of the threading models. 2) 20.000 separate drawables, sharing underneath the same VBO and EBO (at least I hope I'm doing it the right way, check the code in my previous post) CULL: ~8ms, DRAW: ~36ms, GPU: ~35ms 3) A single geode+geometry in which I combine all of the instances, rendered in a single VBO + EBO CULL: 0.04ms, DRAW: 0.18ms, GPU: ~4.5ms Stats very stable, no differences among threading models. With this scenario the fragment opeations becomes the bottleneck when I look at the scene from a viewpoint that cause all the geometries to be rendered almost back to front, so that nothing is culled nor discarded by z test. So scenario 3 provides a huge boost as expected, while the difference between 1 and 2 is not as evident as I had hoped... I'll see if I'm able to to patch the osg code to achive what Robert suggests. Thanks, Ricky On Thu, May 5, 2011 at 20:47, Robert Osfield robert.osfi...@gmail.comwrote: HI All, Current the OSG does unbind VBO's at the end of osg::Geometry::drawImplementation(..) so that VBO and EBO state doesn't leak into adjoining Drawables. If an implementation is known to only use VBO's, with no display lists then potentially we could not bother with the unbind at the end of Geometry::drawImplemenation() and use lazy state updating. Robert. ___ 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] large VBOs for multiple Drawables
Hi Ricky, Given you have 20,000 instances their will and cull and draw dispatch bottleneck. Sharing VBO's won't really share this much. The big elephant in the room is the number of seperate objects to traverse in the cull and draw traversals and the number of seperate GL calls that will have to be made. As you've found batching the data ovoids these bottlenecks and is certainly the way forward. Robert. On Fri, May 6, 2011 at 9:49 AM, Riccardo Corsi riccardo.co...@kairos3d.it wrote: Hi All, Paul, I think I've done some of the benchmark you're referring to on my end right before starting this thread =) In my example I replicate the same geometric primitive many times. The geometric object is a little cube counting 40 vertex and 66 triangles all rendered as a single drawElements in batch. I'm using a very basic toon shader to render them, passing vertices, normals and a vec4 attribute array. Here's what I got when I test with 20.000 instances of the primitive when they are all in the view frustum, my box is Win7, i7 920 processor, nVidia 285GTX: 1) 20.000 separate drawables, each with its own VBO assigned. CULL: 11ms, DRAW: ~40ms, GPU: ~37ms Stats are very unstable with this scenario, even when I don't move and with all of the threading models. 2) 20.000 separate drawables, sharing underneath the same VBO and EBO (at least I hope I'm doing it the right way, check the code in my previous post) CULL: ~8ms, DRAW: ~36ms, GPU: ~35ms 3) A single geode+geometry in which I combine all of the instances, rendered in a single VBO + EBO CULL: 0.04ms, DRAW: 0.18ms, GPU: ~4.5ms Stats very stable, no differences among threading models. With this scenario the fragment opeations becomes the bottleneck when I look at the scene from a viewpoint that cause all the geometries to be rendered almost back to front, so that nothing is culled nor discarded by z test. So scenario 3 provides a huge boost as expected, while the difference between 1 and 2 is not as evident as I had hoped... I'll see if I'm able to to patch the osg code to achive what Robert suggests. Thanks, Ricky On Thu, May 5, 2011 at 20:47, Robert Osfield robert.osfi...@gmail.com wrote: HI All, Current the OSG does unbind VBO's at the end of osg::Geometry::drawImplementation(..) so that VBO and EBO state doesn't leak into adjoining Drawables. If an implementation is known to only use VBO's, with no display lists then potentially we could not bother with the unbind at the end of Geometry::drawImplemenation() and use lazy state updating. Robert. ___ 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] large VBOs for multiple Drawables
Hi Robert, thank you for your advice, but I used 20.000 only for benchmarking purposes, I'll balance better the scenegraph in the real application. Even so, with the scenario number 2, I was hoping to achieve performances closer to scenario 3 than 1, as the stats scale quite in linear way with smaller number of drawables. Do you think the approach you suggest, avoiding explicit buffer unbind, would provide some benefit? I also have another question: when assigning vertex attributes and using VBO, I've met some issues using methods Geometry::setNormal/ColorArray and retrieving the related attributes with gl_Normal/Color in shaders, while everything works smooth if I assign and bind specific attribute indices. What is the reason behind it? Thank you, Ricky On Fri, May 6, 2011 at 11:29, Robert Osfield robert.osfi...@gmail.comwrote: Hi Ricky, Given you have 20,000 instances their will and cull and draw dispatch bottleneck. Sharing VBO's won't really share this much. The big elephant in the room is the number of seperate objects to traverse in the cull and draw traversals and the number of seperate GL calls that will have to be made. As you've found batching the data ovoids these bottlenecks and is certainly the way forward. Robert. On Fri, May 6, 2011 at 9:49 AM, Riccardo Corsi riccardo.co...@kairos3d.it wrote: Hi All, Paul, I think I've done some of the benchmark you're referring to on my end right before starting this thread =) In my example I replicate the same geometric primitive many times. The geometric object is a little cube counting 40 vertex and 66 triangles all rendered as a single drawElements in batch. I'm using a very basic toon shader to render them, passing vertices, normals and a vec4 attribute array. Here's what I got when I test with 20.000 instances of the primitive when they are all in the view frustum, my box is Win7, i7 920 processor, nVidia 285GTX: 1) 20.000 separate drawables, each with its own VBO assigned. CULL: 11ms, DRAW: ~40ms, GPU: ~37ms Stats are very unstable with this scenario, even when I don't move and with all of the threading models. 2) 20.000 separate drawables, sharing underneath the same VBO and EBO (at least I hope I'm doing it the right way, check the code in my previous post) CULL: ~8ms, DRAW: ~36ms, GPU: ~35ms 3) A single geode+geometry in which I combine all of the instances, rendered in a single VBO + EBO CULL: 0.04ms, DRAW: 0.18ms, GPU: ~4.5ms Stats very stable, no differences among threading models. With this scenario the fragment opeations becomes the bottleneck when I look at the scene from a viewpoint that cause all the geometries to be rendered almost back to front, so that nothing is culled nor discarded by z test. So scenario 3 provides a huge boost as expected, while the difference between 1 and 2 is not as evident as I had hoped... I'll see if I'm able to to patch the osg code to achive what Robert suggests. Thanks, Ricky On Thu, May 5, 2011 at 20:47, Robert Osfield robert.osfi...@gmail.com wrote: HI All, Current the OSG does unbind VBO's at the end of osg::Geometry::drawImplementation(..) so that VBO and EBO state doesn't leak into adjoining Drawables. If an implementation is known to only use VBO's, with no display lists then potentially we could not bother with the unbind at the end of Geometry::drawImplemenation() and use lazy state updating. Robert. ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] large VBOs for multiple Drawables
You usually want to create GL batches that are as large as possible. 10 draw calls of 100 elements will be slower than 1 draw call of 1000 elements. Something else I have noticed a little while ago was that the stateset processing engine of OSG might be slow. One thing I have been surprised with was the performance with a scene graph containing just empty statesets on drawables vs. no stateset at all. Just having empty statesets decreases perf quite a bit, eg. just by calling getOrCreateStateSet. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39084#39084 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] large VBOs for multiple Drawables
Hi Ricccardo, On Fri, May 6, 2011 at 10:53 AM, Riccardo Corsi riccardo.co...@kairos3d.it wrote: Do you think the approach you suggest, avoiding explicit buffer unbind, would provide some benefit? It's unlikely to make a big difference as it's only one small part of all the operations being done in the draw traversal. I also have another question: when assigning vertex attributes and using VBO, I've met some issues using methods Geometry::setNormal/ColorArray and retrieving the related attributes with gl_Normal/Color in shaders, while everything works smooth if I assign and bind specific attribute indices. What is the reason behind it? No clue what might be amiss, there is far too little information to go on to know. I haven't personally seen problems with using setNormalArray/setColorArray when using shaders, perhaps there is somethin unusual you are doing. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] large VBOs for multiple Drawables
On 5/6/2011 4:05 AM, Fred Smith wrote: You usually want to create GL batches that are as large as possible. 10 draw calls of 100 elements will be slower than 1 draw call of 1000 elements. Something else I have noticed a little while ago was that the stateset processing engine of OSG might be slow. One thing I have been surprised with was the performance with a scene graph containing just empty statesets on drawables vs. no stateset at all. Just having empty statesets decreases perf quite a bit, eg. just by calling getOrCreateStateSet. osgWorks.google.com contains the CountStateSets visitor, which will remove empty StateSets, just for this reason. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] large VBOs for multiple Drawables
Hi All, I revamp this thread as my question is strictly related, as I'm trying to pack multiple geometries into shared VBO. I'm creating a shared osg::Vec3Array for vertices, same for as many vertex attribute as I need, and then assigning these shared arrays to the different geometries (pGeom-setVertexArray() and pGeom-setVertexAttribArray() ) and telling the geometry to use VBO and not display lists. Then I create a new DrawElements for each geometry, with the correct vertex indices offset, and as I want them to share the same EBO underneath, I'm trying with: pDrawElemsUInt-setElementBufferObject(pSharedEBO); pGeom-addPrimitiveSet(pDrawElemsUInt); But I think I' missing something because, with gDebugger, I see that there are as many bindBuffer calls as num-geom * num-shared-buffers. Am I wrong in the way I try to share the drawElems EBO? Or missing something else? Thank you! Ricky On Mon, Jan 3, 2011 at 19:31, Jason Beverage jasonbever...@gmail.comwrote: Hi Terry, I was generating all my geometry in code so I wrote some custom code to pack them tightly into a single vertex array. Jason On Mon, Jan 3, 2011 at 1:05 PM, Terry Welsh mogu...@gmail.com wrote: Hi Jason, Thank you for the suggestion. I feel like I'm missing something still. Is there an Optimizer feature or something that combines Arrays for you? Or did you write a bunch of custom code that processes your models after you load them? -- Terry Welsh mogumbo 'at' gmail.com www.reallyslick.com Message: 3 Date: Sun, 2 Jan 2011 21:28:12 -0500 From: Jason Beverage jasonbever...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Subject: Re: [osg-users] large VBOs for multiple Drawables Message-ID: aanlktin2mdb-vewdrpkp0rwjxcok2jm4o0vdx31ao...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi Terry, You can pack the verts of your small objects into a single osg::Vec3Array and share that array across multiple osg::Geometry objects then use DrawElements for each geometry with the correct indices. I've just recently done this actually for a project I'm working on and it's worked out great. Thanks, Jason On Sat, Jan 1, 2011 at 6:21 PM, Terry Welsh mogu...@gmail.com wrote: I found some email threads that hinted at this a little, but nothing seemed very specific. ?I have scenes where display lists perform a bit better than VBOs. ?My best guess is because my objects have relatively small vertex counts (usually between 20 and 200). ?Is there any way in OSG to use one large VBO to store the date for multiple Drawables in order to minimize buffer state changes? -- Terry Welsh mogumbo 'at' gmail.com www.reallyslick.com ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] large VBOs for multiple Drawables
Ricky, AFAIK, OSG doesn't maintain VBO/EBO bindings as part of its sortable state. So I believe they will be bound and unbound for each Geometry, even if they are shared. Somebody correct me if I'm wrong. (See Geometry::drawImplementation.) Glenn Waldron / Pelican Mapping / @glennwaldron On Thu, May 5, 2011 at 11:40 AM, Riccardo Corsi riccardo.co...@kairos3d.itwrote: Hi All, I revamp this thread as my question is strictly related, as I'm trying to pack multiple geometries into shared VBO. I'm creating a shared osg::Vec3Array for vertices, same for as many vertex attribute as I need, and then assigning these shared arrays to the different geometries (pGeom-setVertexArray() and pGeom-setVertexAttribArray() ) and telling the geometry to use VBO and not display lists. Then I create a new DrawElements for each geometry, with the correct vertex indices offset, and as I want them to share the same EBO underneath, I'm trying with: pDrawElemsUInt-setElementBufferObject(pSharedEBO); pGeom-addPrimitiveSet(pDrawElemsUInt); But I think I' missing something because, with gDebugger, I see that there are as many bindBuffer calls as num-geom * num-shared-buffers. Am I wrong in the way I try to share the drawElems EBO? Or missing something else? Thank you! Ricky On Mon, Jan 3, 2011 at 19:31, Jason Beverage jasonbever...@gmail.comwrote: Hi Terry, I was generating all my geometry in code so I wrote some custom code to pack them tightly into a single vertex array. Jason On Mon, Jan 3, 2011 at 1:05 PM, Terry Welsh mogu...@gmail.com wrote: Hi Jason, Thank you for the suggestion. I feel like I'm missing something still. Is there an Optimizer feature or something that combines Arrays for you? Or did you write a bunch of custom code that processes your models after you load them? -- Terry Welsh mogumbo 'at' gmail.com www.reallyslick.com Message: 3 Date: Sun, 2 Jan 2011 21:28:12 -0500 From: Jason Beverage jasonbever...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Subject: Re: [osg-users] large VBOs for multiple Drawables Message-ID: aanlktin2mdb-vewdrpkp0rwjxcok2jm4o0vdx31ao...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi Terry, You can pack the verts of your small objects into a single osg::Vec3Array and share that array across multiple osg::Geometry objects then use DrawElements for each geometry with the correct indices. I've just recently done this actually for a project I'm working on and it's worked out great. Thanks, Jason On Sat, Jan 1, 2011 at 6:21 PM, Terry Welsh mogu...@gmail.com wrote: I found some email threads that hinted at this a little, but nothing seemed very specific. ?I have scenes where display lists perform a bit better than VBOs. ?My best guess is because my objects have relatively small vertex counts (usually between 20 and 200). ?Is there any way in OSG to use one large VBO to store the date for multiple Drawables in order to minimize buffer state changes? -- Terry Welsh mogumbo 'at' gmail.com www.reallyslick.com ___ 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 ___ 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] large VBOs for multiple Drawables
Hi Glenn, thanks for your reply... so to avoid the gl state change related to the bind/unbind of the buffers, have I got to pack multiple geometries into a single one? I'd had preferred to keep them separated as each has a logical meaning in my app, and to have direct access to a single geom when picking. Also, I don't understand very much what's advantage in sharing VBOs among geometries if they are rebound for every geometry rendered. I thought the gain when creating larger VBO shared among geometries was to reduce the state changes and obtain better batches down on the graphics HW. Thank you. Ricky On Thu, May 5, 2011 at 17:51, Glenn Waldron gwald...@gmail.com wrote: Ricky, AFAIK, OSG doesn't maintain VBO/EBO bindings as part of its sortable state. So I believe they will be bound and unbound for each Geometry, even if they are shared. Somebody correct me if I'm wrong. (See Geometry::drawImplementation.) Glenn Waldron / Pelican Mapping / @glennwaldron On Thu, May 5, 2011 at 11:40 AM, Riccardo Corsi riccardo.co...@kairos3d.it wrote: Hi All, I revamp this thread as my question is strictly related, as I'm trying to pack multiple geometries into shared VBO. I'm creating a shared osg::Vec3Array for vertices, same for as many vertex attribute as I need, and then assigning these shared arrays to the different geometries (pGeom-setVertexArray() and pGeom-setVertexAttribArray() ) and telling the geometry to use VBO and not display lists. Then I create a new DrawElements for each geometry, with the correct vertex indices offset, and as I want them to share the same EBO underneath, I'm trying with: pDrawElemsUInt-setElementBufferObject(pSharedEBO); pGeom-addPrimitiveSet(pDrawElemsUInt); But I think I' missing something because, with gDebugger, I see that there are as many bindBuffer calls as num-geom * num-shared-buffers. Am I wrong in the way I try to share the drawElems EBO? Or missing something else? Thank you! Ricky On Mon, Jan 3, 2011 at 19:31, Jason Beverage jasonbever...@gmail.comwrote: Hi Terry, I was generating all my geometry in code so I wrote some custom code to pack them tightly into a single vertex array. Jason On Mon, Jan 3, 2011 at 1:05 PM, Terry Welsh mogu...@gmail.com wrote: Hi Jason, Thank you for the suggestion. I feel like I'm missing something still. Is there an Optimizer feature or something that combines Arrays for you? Or did you write a bunch of custom code that processes your models after you load them? -- Terry Welsh mogumbo 'at' gmail.com www.reallyslick.com Message: 3 Date: Sun, 2 Jan 2011 21:28:12 -0500 From: Jason Beverage jasonbever...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Subject: Re: [osg-users] large VBOs for multiple Drawables Message-ID: aanlktin2mdb-vewdrpkp0rwjxcok2jm4o0vdx31ao...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi Terry, You can pack the verts of your small objects into a single osg::Vec3Array and share that array across multiple osg::Geometry objects then use DrawElements for each geometry with the correct indices. I've just recently done this actually for a project I'm working on and it's worked out great. Thanks, Jason On Sat, Jan 1, 2011 at 6:21 PM, Terry Welsh mogu...@gmail.com wrote: I found some email threads that hinted at this a little, but nothing seemed very specific. ?I have scenes where display lists perform a bit better than VBOs. ?My best guess is because my objects have relatively small vertex counts (usually between 20 and 200). ?Is there any way in OSG to use one large VBO to store the date for multiple Drawables in order to minimize buffer state changes? -- Terry Welsh mogumbo 'at' gmail.com www.reallyslick.com ___ 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 ___ 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] large VBOs for multiple Drawables
On Thu, May 5, 2011 at 12:02 PM, Riccardo Corsi riccardo.co...@kairos3d.itwrote: Hi Glenn, thanks for your reply... so to avoid the gl state change related to the bind/unbind of the buffers, have I got to pack multiple geometries into a single one? yes I'd had preferred to keep them separated as each has a logical meaning in my app, and to have direct access to a single geom when picking. I have been in the same boat. OSG does not draw Geometry's in the order they appear in the graph; rather it sorts them by state attributes in order to minimize state changes during the draw. (Other things like bins come into play as well.) But VBO/EBO bindings are not part of that state...maybe they should be. Or maybe the bind/unbind methods in State could be smarter about not unbinding a buffer object until a new one needs binding. Not sure what side effects this might have but it's worth experimenting with...? Also, I don't understand very much what's advantage in sharing VBOs among geometries if they are rebound for every geometry rendered. I thought the gain when creating larger VBO shared among geometries was to reduce the state changes and obtain better batches down on the graphics HW. Thank you. Ricky On Thu, May 5, 2011 at 17:51, Glenn Waldron gwald...@gmail.com wrote: Ricky, AFAIK, OSG doesn't maintain VBO/EBO bindings as part of its sortable state. So I believe they will be bound and unbound for each Geometry, even if they are shared. Somebody correct me if I'm wrong. (See Geometry::drawImplementation.) Glenn Waldron / Pelican Mapping / @glennwaldron On Thu, May 5, 2011 at 11:40 AM, Riccardo Corsi riccardo.co...@kairos3d.it wrote: Hi All, I revamp this thread as my question is strictly related, as I'm trying to pack multiple geometries into shared VBO. I'm creating a shared osg::Vec3Array for vertices, same for as many vertex attribute as I need, and then assigning these shared arrays to the different geometries (pGeom-setVertexArray() and pGeom-setVertexAttribArray() ) and telling the geometry to use VBO and not display lists. Then I create a new DrawElements for each geometry, with the correct vertex indices offset, and as I want them to share the same EBO underneath, I'm trying with: pDrawElemsUInt-setElementBufferObject(pSharedEBO); pGeom-addPrimitiveSet(pDrawElemsUInt); But I think I' missing something because, with gDebugger, I see that there are as many bindBuffer calls as num-geom * num-shared-buffers. Am I wrong in the way I try to share the drawElems EBO? Or missing something else? Thank you! Ricky On Mon, Jan 3, 2011 at 19:31, Jason Beverage jasonbever...@gmail.comwrote: Hi Terry, I was generating all my geometry in code so I wrote some custom code to pack them tightly into a single vertex array. Jason On Mon, Jan 3, 2011 at 1:05 PM, Terry Welsh mogu...@gmail.com wrote: Hi Jason, Thank you for the suggestion. I feel like I'm missing something still. Is there an Optimizer feature or something that combines Arrays for you? Or did you write a bunch of custom code that processes your models after you load them? -- Terry Welsh mogumbo 'at' gmail.com www.reallyslick.com Message: 3 Date: Sun, 2 Jan 2011 21:28:12 -0500 From: Jason Beverage jasonbever...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Subject: Re: [osg-users] large VBOs for multiple Drawables Message-ID: aanlktin2mdb-vewdrpkp0rwjxcok2jm4o0vdx31ao...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi Terry, You can pack the verts of your small objects into a single osg::Vec3Array and share that array across multiple osg::Geometry objects then use DrawElements for each geometry with the correct indices. I've just recently done this actually for a project I'm working on and it's worked out great. Thanks, Jason On Sat, Jan 1, 2011 at 6:21 PM, Terry Welsh mogu...@gmail.com wrote: I found some email threads that hinted at this a little, but nothing seemed very specific. ?I have scenes where display lists perform a bit better than VBOs. ?My best guess is because my objects have relatively small vertex counts (usually between 20 and 200). ?Is there any way in OSG to use one large VBO to store the date for multiple Drawables in order to minimize buffer state changes? -- Terry Welsh mogumbo 'at' gmail.com www.reallyslick.com ___ 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
Re: [osg-users] large VBOs for multiple Drawables
On 5/5/2011 9:51 AM, Glenn Waldron wrote: AFAIK, OSG doesn't maintain VBO/EBO bindings as part of its sortable state. So I believe they will be bound and unbound for each Geometry, even if they are shared. Somebody correct me if I'm wrong. (See Geometry::drawImplementation.) This is my experience as well. OSG binds and unbinds the buffer object per Geometry during draw, and doesn't attempt to minimize this state change. OSG relies on the underlying OpenGL implementation to do lazy buffer bindings, so that binding a buffer, followed by unbinding a buffer, followed by binding the same buffer again, is handled optimally. However, to my knowledge, OSG doesn't group Geometry objects based on the buffer objects they use, so even if the underlying OpenGL implementation does perform lazy buffer bindings, it's unlikely that OSG is taking maximum advantage of it. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] large VBOs for multiple Drawables
On Thu, May 5, 2011 at 12:59 PM, Paul Martz pma...@skew-matrix.com wrote: On 5/5/2011 9:51 AM, Glenn Waldron wrote: AFAIK, OSG doesn't maintain VBO/EBO bindings as part of its sortable state. So I believe they will be bound and unbound for each Geometry, even if they are shared. Somebody correct me if I'm wrong. (See Geometry::drawImplementation.) This is my experience as well. OSG binds and unbinds the buffer object per Geometry during draw, and doesn't attempt to minimize this state change. OSG relies on the underlying OpenGL implementation to do lazy buffer bindings, so that binding a buffer, followed by unbinding a buffer, followed by binding the same buffer again, is handled optimally. However, to my knowledge, OSG doesn't group Geometry objects based on the buffer objects they use, so even if the underlying OpenGL implementation does perform lazy buffer bindings, it's unlikely that OSG is taking maximum advantage of it. Paul, you know more about OSG internals than I. Would you think that isolating all the Geomety objects that share a VBO into a single render bin might increase the effectiveness of the driver's lazy binding? Glenn Waldron / Pelican Mapping / @glennwaldron ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] large VBOs for multiple Drawables
On 5/5/2011 11:26 AM, Glenn Waldron wrote: On Thu, May 5, 2011 at 12:59 PM, Paul Martz pma...@skew-matrix.com mailto:pma...@skew-matrix.com wrote: On 5/5/2011 9:51 AM, Glenn Waldron wrote: AFAIK, OSG doesn't maintain VBO/EBO bindings as part of its sortable state. So I believe they will be bound and unbound for each Geometry, even if they are shared. Somebody correct me if I'm wrong. (See Geometry::drawImplementation.) This is my experience as well. OSG binds and unbinds the buffer object per Geometry during draw, and doesn't attempt to minimize this state change. OSG relies on the underlying OpenGL implementation to do lazy buffer bindings, so that binding a buffer, followed by unbinding a buffer, followed by binding the same buffer again, is handled optimally. However, to my knowledge, OSG doesn't group Geometry objects based on the buffer objects they use, so even if the underlying OpenGL implementation does perform lazy buffer bindings, it's unlikely that OSG is taking maximum advantage of it. Paul, you know more about OSG internals than I. Would you think that isolating all the Geomety objects that share a VBO into a single render bin might increase the effectiveness of the driver's lazy binding? Assuming the driver does lazy buffer bindings, yes. I know that OSG gets a big win from sorting some OpenGL state, so it stands to reason that including more OpenGL state in this feature (such as buffer bindings) would produce a performance increment. (Of course it goes without saying that the performance delta depends on the model's organization.) This is something that could be benchmarked in an OpenGL app first, to see if there's any real performance delta between the three strategies that I can think of: 1) Render using random buffer objects, always bind and unbind around each Geometry analogue (what OSG does currently). 2) Group Geometry analogues by their buffer objects, but still bind and unbind around each Geometry analogue (what you're proposing). 3) Like 2, but only bind once for each group of Geometry analogues that share the same buffer object (the optimal approach). -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] large VBOs for multiple Drawables
HI All, Current the OSG does unbind VBO's at the end of osg::Geometry::drawImplementation(..) so that VBO and EBO state doesn't leak into adjoining Drawables. If an implementation is known to only use VBO's, with no display lists then potentially we could not bother with the unbind at the end of Geometry::drawImplemenation() and use lazy state updating. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] large VBOs for multiple Drawables
Hi Jason, Thank you for the suggestion. I feel like I'm missing something still. Is there an Optimizer feature or something that combines Arrays for you? Or did you write a bunch of custom code that processes your models after you load them? -- Terry Welsh mogumbo 'at' gmail.com www.reallyslick.com Message: 3 Date: Sun, 2 Jan 2011 21:28:12 -0500 From: Jason Beverage jasonbever...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Subject: Re: [osg-users] large VBOs for multiple Drawables Message-ID: aanlktin2mdb-vewdrpkp0rwjxcok2jm4o0vdx31ao...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi Terry, You can pack the verts of your small objects into a single osg::Vec3Array and share that array across multiple osg::Geometry objects then use DrawElements for each geometry with the correct indices. I've just recently done this actually for a project I'm working on and it's worked out great. Thanks, Jason On Sat, Jan 1, 2011 at 6:21 PM, Terry Welsh mogu...@gmail.com wrote: I found some email threads that hinted at this a little, but nothing seemed very specific. ?I have scenes where display lists perform a bit better than VBOs. ?My best guess is because my objects have relatively small vertex counts (usually between 20 and 200). ?Is there any way in OSG to use one large VBO to store the date for multiple Drawables in order to minimize buffer state changes? -- Terry Welsh mogumbo 'at' gmail.com www.reallyslick.com ___ 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] large VBOs for multiple Drawables
Hi Terry, I was generating all my geometry in code so I wrote some custom code to pack them tightly into a single vertex array. Jason On Mon, Jan 3, 2011 at 1:05 PM, Terry Welsh mogu...@gmail.com wrote: Hi Jason, Thank you for the suggestion. I feel like I'm missing something still. Is there an Optimizer feature or something that combines Arrays for you? Or did you write a bunch of custom code that processes your models after you load them? -- Terry Welsh mogumbo 'at' gmail.com www.reallyslick.com Message: 3 Date: Sun, 2 Jan 2011 21:28:12 -0500 From: Jason Beverage jasonbever...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Subject: Re: [osg-users] large VBOs for multiple Drawables Message-ID: aanlktin2mdb-vewdrpkp0rwjxcok2jm4o0vdx31ao...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi Terry, You can pack the verts of your small objects into a single osg::Vec3Array and share that array across multiple osg::Geometry objects then use DrawElements for each geometry with the correct indices. I've just recently done this actually for a project I'm working on and it's worked out great. Thanks, Jason On Sat, Jan 1, 2011 at 6:21 PM, Terry Welsh mogu...@gmail.com wrote: I found some email threads that hinted at this a little, but nothing seemed very specific. ?I have scenes where display lists perform a bit better than VBOs. ?My best guess is because my objects have relatively small vertex counts (usually between 20 and 200). ?Is there any way in OSG to use one large VBO to store the date for multiple Drawables in order to minimize buffer state changes? -- Terry Welsh mogumbo 'at' gmail.com www.reallyslick.com ___ 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] large VBOs for multiple Drawables
Hi Terry, You can pack the verts of your small objects into a single osg::Vec3Array and share that array across multiple osg::Geometry objects then use DrawElements for each geometry with the correct indices. I've just recently done this actually for a project I'm working on and it's worked out great. Thanks, Jason On Sat, Jan 1, 2011 at 6:21 PM, Terry Welsh mogu...@gmail.com wrote: I found some email threads that hinted at this a little, but nothing seemed very specific. I have scenes where display lists perform a bit better than VBOs. My best guess is because my objects have relatively small vertex counts (usually between 20 and 200). Is there any way in OSG to use one large VBO to store the date for multiple Drawables in order to minimize buffer state changes? -- Terry Welsh mogumbo 'at' gmail.com www.reallyslick.com ___ 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
