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 <[email protected]> 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 > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
