Hi John et. al, I too am not too happy with the approach of a fixed epilson, adding the ability for the user to set this value isn't much better.
Scaling the epsilon by the size of the bounding box may be an improvement but I'm not yet convinced it's the best approach. The epsilon is there is account for numerical precision issues associated with the mathematical functions being performed. The maths in this case is clamping the present line segment start and end points to the bounding box, here the distance of the sides from the start and the start to the end point along each axis is what will determine the size of the values and the range of the numerical errors that are likely. The largest value is likely to be the length of the line segment so might be the best distance to use as the scale. Thoughts? Robert. On 19 August 2013 06:38, PCJohn <pec...@fit.vutbr.cz> wrote: > Hi Robert, > > there was recently a commit concerning epsilon in LineSegmentIntersector > that is now carried as class member. I can imagine motivation behind, but I > belive there is a better approach to the problem. > > If the motivation is just to allow the setting bigger epsilon for bigger > objects (too small epsilon, recently statically assigned to 1e-5, will not > affect big bounding boxes because of limited float resolution. I belive, > this > was the motivation behind the change for the person who submitted the > patch.) > > The correct solution in my opinion would be to make epsilon depend on size > of > bounding box of the intersected object: > > // extend bounding box a little bit to avoid floating point > imprecisions > double epsilon = (bb_max-bb_min).length() * 1e-5; > bb_min.x() -= epsilon; > bb_min.y() -= epsilon; > bb_min.z() -= epsilon; > bb_max.x() += epsilon; > bb_max.y() += epsilon; > bb_max.z() += epsilon; > > This should work in all cases, for both - small and big objects. > Hard-coding > epsilon, even when giving the user the ability to change it, is not correct > way in my opinion, as there may be very small objects (requiring small > epsilon) together with big objects (requiring big epsilon) in the scene. We > can give the user the callback to adjust the epsilon for each visited > object > in the scene, but I do not belive this is the best approach. > > I would very prefer to scale epsilon by the size of the object as this is > how > the floats change their precision. Bigger the object, bigger the value in > float, > smaller float precision, bigger the epsilon is needed. The precision of > float is > between 1e-7 to 1e-6, so multiplying the size of bounding box by 1e-5 > should > provide big enough increase of the bounding box to avoid numerical > imprecisions. > > Having to specify epsilon by programmer is making the things more > difficult for > him, as he should understand float problems and has to think about the > precision value, while he usually just wants intersector to work correctly, > not taking care about hardware precision limitations. Scaling the epsilon > would do the work for him without giving him another parameter that may > turn > things wrong if not set properly. > > Your opinion on this point? > I can create patch based on your suggestions. > John > _______________________________________________ > 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
