[osg-users] Seeking advice: Efficient method for large grid rendering (terrain) with unique state per grid square
John Peterson
halalkitty at gmail.com
Tue Sep 8 15:35:21 PDT 2015
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
More information about the osg-users
mailing list