Hi Robert and Rui, I am trying to recall why infinite picking line and infinite projection matrix required so much code changes in my submission:
- the essential part is LineSegmentIntersector::intersectAndClip() that clips line segment or infinite line to the bounding sphere, making any infinite coordinates finite, unless we allow infinitely large objects or objects placed at infinity. Neither of these is supported by my code yet. - LineSegmentIntersector::intersect() should theoretically stay the same because intersectAndClip feeds it by finite coords. Unfortunately, changes were necessary for two reasons: (a) ratio does not work with infinite intersection lines. Thus, I compute ratio in global coordinates, that is viewport coordinates in my case as I specify intersection line in viewport coords. For standard perspective matrices, ratio equal to 0 is zNear and ratio 1 is zFar. But I agree that it would be, maybe, better to use just distance from starting or ending point, as Robert suggested. This is probably more general solution. (b) LIMIT_NEAREST required ratio in global coords in my case - the computation is rather complex (local2globalMatrix,etc.), but it may be changed to simple if-statement if we change the ratio to contain the distance. - LineSegmentIntersector::intersects() is changed to handle infinite lines. I use homogemeous coordinates (Vec4H, Vec2H classes) as I believe it makes the routines shorter and improves their readability. When considering number of changes provided by my code, I have nothing against having two classes: one for simple 3D intersections and one for more general cases with (in)finite rays and (in)finite projection matrices. Unless you or Rui have more ideas or suggestions, I might try to create RaySegmentIntersector, RayIntersector, or whatever name you suggest, while changing ratio member to distance (or suggest another name) that would contain a positive value for distances from startPoint (endPoint is at infinity) or negative values when startPoint is at infinity and the distance is measured from endPoint. Unfortunately, I have a deadline on my project so I might not be available next two weeks. Then, I will try to dig into the problem. Feel free to comment or to provide another ideas, John On Tuesday 28 of August 2012 09:42:21 Robert Osfield wrote: > Hi Rui and John, > > I've done a quick review of Rui's code, your emails and had a more > general think about the issues. > > My current feeling is that we possible should have a completely > different type of interesector for infinite rays, this is both a > conceptual and an implementation issue. > > >From the conceptual standpoint the LineSegmentIntersector intersects > > the scene graph with a Line Segment, and a Line Segment is not some > one would usually think of as a unbounded at one or both ends. > > Implementation wise the intersection ratio works well for a Line > Segment as it allows would to easily compute the position of the > intersection and any of interpolated attributes along the line > segment. > > For a ray emanating from a point isn't somewhat different, one really > would want to work with a start point and a direction, and the > intersection value you'd likely want to report would be a distance > from the start point. > > So conceptually and interface wise I think we might be better served > by introduce a RayIntersector class for these unbounded intersections > tests. Implementation wise repeating lots of code isn't great so I do > wonder if a RayIntersector might be able to leverage some of the > present LineSegmentIntersector/KdTree code, perhaps either by a > refactor of the LineSegmentIntersector or having the RayIntersector > use a LineSegmentIntersector internally. > > Implementation wise there is obvious a big different between a ray and > line segment for the first test against the scene graph as the ray is > obvious unbounded either at one or both ends, but once you intersect > the topmost bounding sphere of the scene graph being intersected one > now has two end points and therefore a line segment so now one > potentially could leverage the LineSegmenetIntersector and KdTree > codes. > > Thoughts? > Robert. > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph. > org _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
