Hi Robert, after this new idea, I am starting to ask myself, what are the cases for which we need epsilon?
- when the line segment accidentally misses bbox while triangle intersection routines would indicate intersection (can this happen?) - when clipping puts the start or end point "inside" the bbox, thus triangles on the bbox surface might be omitted from the intersection If only the second point is the case, your proposed solution could handle this quite well. Once again, we have probably different opinion about computing epsilon. If I understand it right, you want to make epsilon something line lineSegmentLenght*1e-5, am I right, or once again I do not understand your idea? (By epsilon I mean the space distance that you shift the start or end.) I am writing it because lineSegmentLength is unrelated to the float precision of newly computed start and end. Thus, computation based on lineSegmentLength would fail in many cases. If we have newly computed start close to the [0,0,0], we have high precision and epsilon should be very small, otherwise we waste float precision. And if newly computed start is [1e10, 1e10, 1e10], then epsilon must be quite big to move such point, otherwise missing intersections may occur. Unfortunately, computer floating arithmetic is strange and 1e10 + 1e2 = 1e10 . Correct me if I am not right. John On Thursday 22 of August 2013 10:17:57 Robert Osfield wrote: > Hi John, > > I wasn't thinking of expanding the line segment, rather expanding the > bounding box just with a epsilon scaled by the line segment length. > > However, you confusion about what I was thinking has given me an idea - > perhaps the best thing to do is do the intersection against the original > bounding box then pull the intersection point on the line segment back > towards the original end points just a little. In essence this is exactly > what expanding the bounding box always did, but rather than put the epsilon > into the bounding box, we just put it into the ratio that is used to > compute the near start and and end points, as a ratio is used when > computing the distance there won't be any need to scale the epsilon too. > > So the code: > > // clip s to xMin. > s = s+(e-s)*(bb_min.x()-s.x())/(e.x()-s.x()); > > > Would change to something like: > > s = s+(e-s)*((bb_min.x()-s.x())/(e.x()-s.x())-epsilon); > > One would need to add a check to make sure the ratio computed isn't less > than the epsilon though, you wouldn't want the start and end points > migrating outwards. > > Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
