|
Hi Robert, Thanks for looking into this! We do not have a suitable example dataset online at the moment, but we will prepare one for you. I will send you an e-mail once it is online. Cheers, Rick. Robert Osfield wrote: 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<[email protected]> 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 [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 |
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
