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
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
I have not experienced this exact problem, but have found some strange
things with CullingSet::computePixelSizeVector. See below:
article.gmane.org/gmane.comp.graphics.openscenegraph.user/70166/
If you find any more details about the implementation it might help.
rgds
jp
>
> Thank you for any input, Joakim
>
> ------------------ Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=43712#43712
>
>
>
>
>
> _______________________________________________ osg-users mailing
> list osg-...@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.
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.
Thank you for the input.
I tried rewriting CullingSet::computePixelSizeVector to use Vec3d instead of Vec3. The problem occurs less frequently, but is still there.
In the function
void PagedLOD::traverse(NodeVisitor& nv)
there is a fallback to select the highest res tile when there is no cullstack or the cullstack lodscale is zero (line 152-160 in PagedLOD.cpp). I'm currently using the same fallback for the case when required_range is too large (i.e. not contained in any of the lod ranges) or infinite, and that works for me.
Thanks again
Regards,
Joakim
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43736#43736
By the way, I'm still a bit curious about how CullingSet::computePixelSizeVector works. Any pointers?
Regards,
Joakim
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43751#43751
On 8 November 2011 07:29, Joakim Low <Joaki...@saabgroup.com> wrote:
> Just to follow up; I would suggest adding the support for infinite values for screen space lod, that would be valuable for us. Thank you.
I'm afraid I'm rather busy with client work right now, could you dive
in and have a bash at implementing it?
> By the way, I'm still a bit curious about how CullingSet::computePixelSizeVector works. Any pointers?
It's some maths I derived from looking at combination of the
projection and modelview matrices. It's written to be fast to compute
and give a good enough result. I didn't keep my derivation of the
maths unfortunately - wrote it down on paper then coded it, then
discarded the paper. This was quite a few years back now.
Robert.
I'll give it a try.
Regards,
Joakim
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43757#43757