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

[Robert Osfield]

Hi John,

LOD (Level Of Detail) is all about providing multiple versions each with
different resolution of geometry and/or texture data so that lower
resolution versions are used at far distances and higher resolution
versions are used at a nearer distance.  LOD's can also be used in
conjunction with a quad tree hierarchy where the low resolution version
covers the area of four geographically smaller tiles.  This quad tree
hierarchy can be go as deep as you want, especially when used with
PagedLOD's rather than LOD's.

However, from your description you aren't talking about this
multi-resoliution management, but simply a quad tree layout that has no
actual need for LOD's.  This leaves me a mixture confused about your intent
or unsure about your level of understanding of basic scene graph concepts.

The way to do a quad tree to enable early culling is to create a hierarchy
of osg::Group nodes that each have four children, nesting down the levels
till you get to the leaf nodes containing the actual geometry and textures
required.

Using a quad tree without LOD's would be fine for an application that only
ever views a relatively fixed number of tiles at one time such as map view
from a fixed height.  For general 3D rendering such a quad tree hierachy of
a big dataset would lead to performance problems as distant views or views
looking out to the horizon would have so many tiles to render that the
system would be overloaded.  In this situations LOD's are essential to load
balance.  From really large dataset PageLOD's become essentially to allow
you to scale to very large ranges and resolutions - the OSG is used with
whole earth visualization systems that have data down to sub m resolution
with ten's of terrabytes of data, all working at solid 60Hz.

Robert.



On 10 September 2015 at 18:17, John Peterson <halalkitty at gmail.com> wrote:

> Thank you for your reply, Robert.
>
> You mentioned PagedLOD nodes. While I might not use the paged version of
> the LODs nodes just yet, I've been thinking a lot about whether LOD nodes
> are the way to go in order to get OSG to cull large portions of my terrain
> without having to traverse and render every single grid square in the
> world. I'd be interested to know if the following technique might succeed
> for my use case, which I could later extend to PagedLOD nodes as I increase
> the area of my terrain.
>
> For the purposes of this very simple example, imagine a 4x4 grid where
> each one of the 16 grid squares represents a 5000 m^2 area of terrain. I
> should have been clear in my original post and mentioned that the grid
> squares are literally that--four vertices to render a pair of triangles.
> (In other words, it's not a particular complicated terrain from a geometric
> standpoint.) I'm wondering if I could use LOD nodes hierarchically in order
> to partition the scene in such a way that OSG will simply discard entire
> quadrants that are too far away from the viewer. To illustrate more clearly
> the scene graph I envision (excuse the ASCII art):
>
>
> Code:
> root
>   LOD
>     LOD
>       geometry for square at (0,0)
>     LOD
>       geometry for square at (1,0)
>     LOD
>       geometry for square at (0,1)
>     LOD
>       geometry for square at (1,1)
>   LOD
>     LOD
>       geometry for square at (2,0)
>     LOD
>       geometry for square at (3,0)
>     LOD
>       geometry for square at (2,1)
>     LOD
>       geometry for square at (3,1)
>   LOD
>     LOD
>       geometry for square at (0,2)
>     LOD
>       geometry for square at (1,2)
>     LOD
>       geometry for square at (0,3)
>     LOD
>       geometry for square at (1,3)
>   LOD
>     LOD
>       geometry for square at (2,2)
>     LOD
>       geometry for square at (3,2)
>     LOD
>       geometry for square at (2,3)
>     LOD
>       geometry for square at (3,3)
>
>
>
> Of course, I'd have to carefully choose the LOD min and max values to
> ensure that I'm neither discarding too much of the scene graph nor
> including more than I actually need.
>
> My question is, is this technique reasonable and scalable? Are there any
> pitfalls that I need to watch for, or any red flags that it raises?
>
> Best regards,
> John
>
> ------------------
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65101#65101
>
>
>
>
>
> _______________________________________________
> 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/ef5fa263/attachment-0003.htm>