[osg-users] automatically merge close-by geometries to reduce cull/draw overhead?

[Robert Osfield]

Hi Christian,

On 8 September 2015 at 15:26, Christian Buchner <christian.buchner at gmail.com
> wrote:

>
>
> 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.
>
> 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.
>
> Also I am wondering what the SPATIALIZE_GROUPS feature of the optimizer
> does.
>

All these merge/specialize visitors work on flat osg::Geode and osg::Group
respectively.

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.

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.

I don't want to help you make bad scene graphs.  I want to help you make
efficient scene graphs.

Robert




On 8 September 2015 at 15:26, Christian Buchner <christian.buchner at gmail.com
> wrote:

>
> 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.
>
> 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.
>
> Also I am wondering what the SPATIALIZE_GROUPS feature of the optimizer
> does.
>
> Christian
>
>
> 2015-09-07 12:32 GMT+02:00 Robert Osfield <robert.osfield at gmail.com>:
>
>> Hi Christian,
>>
>> Since you are creating the building yourself I would recommend that you
>> build them grouped to start off with rather than post process them.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> Robert.
>>
>>
>>
>> On 7 September 2015 at 10:50, Christian Buchner <
>> christian.buchner at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> 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.
>>>
>>> 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!
>>>
>>> Are there any specific features within OSG to group close by geodes, and
>>> to merge their drawables?
>>>
>>> I know the osgUtil::Optimize has flags for merging geodes and drawables,
>>> but I guess it would not automatically merge only very close objects.
>>>
>>> What path should I try to take for tackling this problem, if possible
>>> using built-in OSG features?
>>>
>>> Christian
>>>
>>>
>>>
>>> _______________________________________________
>>> osg-users mailing list
>>> osg-users at lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>>
>>
>> _______________________________________________
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20150908/3325ece2/attachment-0003.htm>