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