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
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
