Hi Joakim, Could it be the use of Vec3 internally is part of the issue here? If you have large values of v then it's likely to cause numerical issues.
For the LOD ranges I presume it's the highest rest LOD child range that is not being selected when it should. When using screen space LOD ranges the highest rest child range will be near infinite, and perhaps we should even be supporting an infinite value to allow for children that have their bounding sphere's sitting exactly at the eye plane so that these don't get culled. I must admit that using screen space LOD is not something that is widely used in the OSG and isn't the most as exposed the level of testing that distance based LOD ranges have. If there areas we need to tighten up then I open to suggestions. Robert. On 4 November 2011 10:14, Joakim Low <[email protected]> wrote: > Hi, > > I'm experiencing some problems with disappearing terrain tiles close to > camera, which I believe have to do with a combination of PagedLOD range > handling and pixel-size-on-screen computation. > > > The problem: > At certain combinations of distance and angle from camera, PagedLOD tiles are > completely culled, causing a hole in the terrain. The problem seems to appear > only for tiles close to camera, when using large coordinates. > > > My understanding: > I've pinpointed the source of my problem to the function: > > float CullingSet::pixelSize(const Vec3& v, float radius) const { return > radius/(v*_pixelSizeVector); } > > Occasionally, the scalar product in the denominator becomes zero, causing the > function to return an inf-value. This means no LOD-range will cover the > resulting pixelSize, which in turn means no tile is shown. The > _pixelSizeVector is computed by the function > CullingSet::computePixelSizeVector. I don't have much understanding of how > this function works, but after looking at the components of _pixelSizeVector > (a Vec4 vector), my guess is that the problem appears due to numerical > cancellation. In my case, the x,y,z components of _pixelSizeVector are very > small compared to the w-component, while the components of v (a Vec3 vector > representing the bounding sphere center here) are large. The scalar product > returns zero due to limited precision, where it probably should return some > very small number instead. > > > Questions: > I can think of two ways to deal with this: > 1. Find another, more stable, way to compute the pixel-size-on-screen. If I > understood the idea/algorithm used in the CullingSet::computePixelSizeVector, > I could try to figure a different way to do it, or predict the cases where > the problem occurs. I'm not sure this would utlimately solve the problem > though, since pixel-size-on-screen may be extremely large (?), causing the > tile pixel size to fall out of all LOD-ranges. Can anyone point to an > explanation of the idea/algorithm used to compute in > CullingSet::computePixelSizeVector? I would really like to know more. > 2. Accept that the CullingSet::pixelSize may return extremely large values, > even inf in some cases, and handle this in PagedLOD. This is the work-around > I'm currently using. > > Has anyone else experienced similar problems? Is there something I've > missed/overlooked? I'm currently on OSG version 2.8.2, but as far as I can > tell, the code in trunk still works the same way. > > Thank you for any input, > Joakim > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=43712#43712 > > > > > > _______________________________________________ > 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
