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