<div dir="ltr">Hi Christian,<br><div class="gmail_extra"><br><div class="gmail_quote">On 8 September 2015 at 15:26, Christian Buchner <span dir="ltr"><<a href="mailto:christian.buchner@gmail.com" target="_blank">christian.buchner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div dir="ltr"><div><div><div><br></div>My building's aren't (yet) textured, so that removes the need for a texture atlas. However they are individually shaped (being created from an ESRI shape file essentially), so instancing is ruled out.<br><br></div>I might try to group the buildings into tiles of equal size, trying to run the osgUtil::Optimizer with MERGE_GEOMETRY and MERGE_DRAWABLES individually on each tile. Let's see how that goes. If it is too slow, I will have to refactor my code that generates buildings.<br><br></div><div>Also I am wondering what the SPATIALIZE_GROUPS feature of the optimizer does.<span class=""><font color="#888888"><br></font></span></div><span class=""></span></div></blockquote><div><br></div><div>All these merge/specialize visitors work on flat osg::Geode and osg::Group respectively.<br><br></div><div>While you potentially could try and co-opt these classes to help you they are bandages that can be applied to crappy scene graphs to try and prevent the worst offences they make from affecting performance.  With 3rd party scene graphs created by modelling tools with little clue of real-time scene graph needs this is best you can get.  Running the Optimizer classes might improve bad scene graphs but it can't avoid creating more fragment memory, and it can't make the most optimal solutions for all types of data.  <br><br>Creating efficient scene graphs from the start is ABSOLUTELY the most efficient way to use the OSG and OpenGL.  In your case you should be creating an efficient scene graph right from the start and their should be no need to run *any* of the osgUtil::Optimizer classes.   To keep asking about using the Optimizer you are effectively saying, no no I want to create crappy scene graphs and let the other code do it's best to fix it up.<br><br></div><div>I don't want to help you make bad scene graphs.  I want to help you make efficient scene graphs.<br><br></div><div>Robert<br></div><div><br><br></div><div> </div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 8 September 2015 at 15:26, Christian Buchner <span dir="ltr"><<a href="mailto:christian.buchner@gmail.com" target="_blank">christian.buchner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><br></div>My building's aren't (yet) textured, so that removes the need for a texture atlas. However they are individually shaped (being created from an ESRI shape file essentially), so instancing is ruled out.<br><br></div>I might try to group the buildings into tiles of equal size, trying to run the osgUtil::Optimizer with MERGE_GEOMETRY and MERGE_DRAWABLES individually on each tile. Let's see how that goes. If it is too slow, I will have to refactor my code that generates buildings.<br><br></div><div>Also I am wondering what the SPATIALIZE_GROUPS feature of the optimizer does.<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div><br>Christian<br><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2015-09-07 12:32 GMT+02:00 Robert Osfield <span dir="ltr"><<a href="mailto:robert.osfield@gmail.com" target="_blank">robert.osfield@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi Christian,<br><br></div>Since you are creating the building yourself I would recommend that you build them grouped to start off with rather than post process them.<br><br></div>The first step I'd tack would be to create a texture atlas from the wall and roof textures and then just create a single osg::Geometry and associated osg::StateSet.   This will half the number of Drawables and state changes.<br><br>If you have a set of roof and wall textures then see if you create a single texture atlas from them so that you can then reuse the same osg::StateSet between separate Drawables. <br><br>Then final step would be to merge groups of Drawables that are in geographical location.  The osgforest example does grouping of randomly placed trees so have a look at ways of doing this.<br><br></div><div>Another approach you could take would be to create a single osg::Geometry and then use instances to repeat the building geometry and provide a size for a shader to scale the geometry and place it in it's final position.  Again the osgforest has a code path that does this so have a look at this.<br></div><div><br></div>Robert.<br><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On 7 September 2015 at 10:50, Christian Buchner <span dir="ltr"><<a href="mailto:christian.buchner@gmail.com" target="_blank">christian.buchner@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><div><div>Hi,<br><br></div>we're using code loading some buildings (outline and height), creating a Geode with a two drawables per individual building - one drawable for the walls, one for the roof polygon. This has served us well to display a few hundred to a few thousand buildings.<br><br></div>Fast forward to current date. Our client has sent us a new geo data set containing 55000 building polygons. Once you zoom out the camera to show most of these buildings, frame rates drop into the low single digit, mostly due to all the culling effort done by the CPU (maybe also from the large number of draw calls). D'oh! <br><br></div><div>Are there any specific features within OSG to group close by geodes, and to merge their drawables?<br><br></div><div>I know the osgUtil::Optimize has flags for merging geodes and drawables, but I guess it would not automatically merge only very close objects.<br><br></div><div>What path should I try to take for tackling this problem, if possible using built-in OSG features?<span><font color="#888888"><br><br></font></span></div><span><font color="#888888"><div>Christian<br><br></div><div><br></div></font></span></div>
<br></div></div>_______________________________________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org" target="_blank">osg-users@lists.openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org" target="_blank">osg-users@lists.openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
<br></blockquote></div><br></div>