Hi Rick, It sounds like the set up of the ClusterCullingCallback is the problem. Could you provide an example dataset and camera position that illustrates the incorrect culling?
FYI, the actual control point "should" automatically adjusted to lie above the tops of the mountains with the deviation angle adjusted appropriately. The concept of cluster culling is that the boundary of the tile would occlude the terrain, so you compute the position and angle to fit to this. Clearly there must be something wrong in this calculation, but what is the question... without the a good example of where the current computation is failing I can't easily reproduce and know if that an fix actual works. Cheers, Robert. On Tue, Jun 23, 2009 at 12:36 PM, Rick Middelkoop<r...@k2vi.com> wrote: > Hi everyone, > > We came across a cluster culling problem with Virtual Planet > Builder-generated globe datasets. > > With the viewpoint at a relatively low altitude (say <1000m), descending > causes distant mountain-tiles to be culled at a moment when they have > not yet disappeared completely behind the horizon. The far plane is > behind these mountains, so frustum clipping is not the cause. > > It seems that tiles containing (high) mountains are culled sooner than > 'flat' (elevation=0.0) tiles. At least in our 'globe' datasets > (generated with different versions of VPB up to 0.9.10) this is the > case. Of course, what you would expect is the opposite. > > The cluster culling control point for a terrain tile lies at the top > elevation for the tile, which seems very valid. However, the cluster > culling calculation (which calculates the angle between the (far away) > tile normal and the vector from the control point to the viewpoint, and > compares this with a 'deviation' threshold to determine if a tile is to > be culled) works in such a way that the high elevation of the control > point causes a larger angle between the 'control point to > viewpoint'-vector and the tile normal than a low elevation of the > control point would. > > In other words, when looking from the viewpoint to the control point at > the top of the mountain, one is looking from below [= reason for > culling: a flat (elevation=0.0) tile would be behind the horizon], while > from the same viewpoint one could be looking at a 'flat' (elevation=0.0) > tile from the top [= reason for not culling]. A threshold deviation > seems to aim to compensate for tile elevation, but this does not prevent > the mountain tiles from being incorrectly culled. > > The solution that works for us (but which may not be optimal), is to set > the elevation of the control point at -(top elevation), and thus > introduce a bias that allows the mountains to remain visible when not > yet completely behind the horizon. > > Did anyone experience this problem? If it turns out that this is a > general vpb/cluster culling issue, what would be the best solution? > > Thanks & Best Regards, > > Rick. > > > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
