[osg-users] Seeking advice: Efficient method for large grid rendering (terrain) with unique state per grid square

[Robert Osfield]

Hi John,

When dealing with large amounts of data the best approach is typically to
use paging, you can use the osg::PageLOD node to support this when
generating your own scene graphs, or use VirtualPlanetBuilder to creat a
paged database offline, or osgEarth to create the paged database at runtime
on demand.  Either of these approaches may be appropriate for your dataset.

You don't say much about the nature of your dataset.  The area of coverage
of each tile isn't important, what is important is the amount of data.
Typically one needs to balance the amount of data per tile, so the area of
the tile you will want to build will be governed by the amount of data you
want to use per tile.  In OSG-3.4 there is support in osgTerrain for
sharing the osg::Geometry between tiles and assigning seperate texture
layers to each tile, this drastically cuts the memory footprint and
bandwidth needs.  Even you don't use osgTerrain/osgEarth etc. this sharing
approach might be appropriate for you.

Robert.


On 8 September 2015 at 23:35, John Peterson <halalkitty at gmail.com> wrote:

> Hello everyone,
>
> I am seeking some advice on the best way to implement a particular task
> using OSG. Hopefully I can articulate what I'd like to do in a way that
> makes sense--please do not hesitate to ask if I need to clarify.
>
> Essentially, I'd like to use OSG to render a large grid which is basically
> a heightfield representing a terrain. Each square of the grid will
> represent a fairy large amount of area, about 5000 m^2 per grid square, and
> I envision having a large number of these grid squares--on the order of a
> couple hundred thousand. I'd like to be able to assign a unique state
> consisting of one or more textures to each grid square. For instance, one
> grid square may have a water texture, another square a grass texture,
> another a road segment, etc. My camera will almost always be just above the
> terrain, similar to what the DriveManipulator accomplishes. I do not
> foresee having to 'fly' high above the terrain; I don't know if that allows
> for some sort of optimization.
>
> I've tried creating my own geometry objects, one per grid square, which
> allows me to set a unique StateSet per square. Performance scales poorly
> with total number of grid squares added, as one might expect. I thought OSG
> would cull the grid squares that were out out the viewport, but I suppose
> traversing all those geometries is CPU-intensive. That said, I did add all
> my objects to the root of the scene; I did not try grouping them
> hierarchically in any way (for instance, breaking down the grid into
> quadrants, then breaking those quadrants into four, etc.) If I built up a
> tree in this manner using osg::Groups, would OSG know to cull the entire
> group if its bounding box were outside the viewport, or does it just
> iterate over all the children each time? Is there a facility I should look
> into that can accomplish this?
>
> My application sounds like a perfect fix for osgTerrain and its
> constituent classes, but my understanding (which may be incorrect) from
> reading osgTerrainTile is that while it can be assigned an elevation layer
> with many rows and columns, a colour layer for a texture will cover the
> entire tile. If I were to use osgTerrainTile, I'd be creating tiles with
> one row and column (one height value), and setting layers for my textures.
> This basically sounds like my existing solution and seems like an abuse (or
> horrible misuse? underuse?) of the terrain facilities, and again I'm
> concerned about performance.
>
> Are there any techniques that I should look into to ensure a performant
> application? I'll admit that this is not my area of expertise. I appreciate
> any pointers in the right direction.
>
> Best regards,
> John
>
> ------------------
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65071#65071
>
>
>
>
>
> _______________________________________________
> 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/20150910/61658cd6/attachment-0003.htm>