Hi Robert, I discussed with my mathematical friend once again. These are the results:
1. He was against allowing both points to go to infinity. If we allow it, it generates circle at infinity going through both points with the center at (0,0,0). To parametrize the position at the circle, two floats (or doubles) would be necessary. Position at the first specified point would be (0,1) and position at the second (1,0). To go to the second point in opposite circle direction, (-1,0) should be the parameter of the second point. Between 0 and 1 or 1 and 0 linear interpolation is used. Vertices of geometry itself can be placed at infinity by 4D vertex coordinates with w set to zero, or by a special transformation matrix that would move or project a mesh to infinity. Typical scenario might be a skybox or a background image. Intersection between objects at infinity and with such "circle" would be just 2D intersection. Intersection point would be standard x,y,z in local coordinates and 4D vector in global coordinates. Ops, it can be 4D vector even in local coordinates in the case when osg::Geometry uses Vec4 as vertex coordinates. Thus, both coordinates should be Vec4. The sorting of the intersections would be difficult as I am not sure how to define the less operator. Maybe, angle from the start point? Anyway, I am not sure if there will be any useful usage for such "infinite circle" intersections... It would also take some time to implement this. 2. Easier option is to allow only start or only end to be placed at infinity. At that moment, the parametrization can be realized by just a single float (or double) and sorting can be defined by distance from the start point. The only problem might be the sorting of intersections at infinity. That is far from trivial. The first problem is that transformation matrix projecting objects to infinity does not have an inverse, thus it is challenging problem to transform the ray to local coordinates. Anyway, it should be possible to construct it using direction of projection and direction of ray. In local coordinates of intersected object, we have the correct order, but it is difficult to transform it to global coordinates as it is always +inf. Thus, any unstable sort would destroy the order of intersections even if we put them to the list in the correct order. My last idea discussed with my friend is (although we were not completely sure about the whole idea), that maybe we can use two floats once again, setting w to zero but x may carry the distance of intersection from the center of projection before the object was projected to infinity. Let me explain it more clearly on an example: Let's have few cubes and a projection center from which all cubes are projected to the infinity. The distance of each cube from the projection center can be used for x part while w will be zero. Anyway, I do not see this as trivial. Let me sumarize the current options (from simplest): - we might want to have intersector specified by point and direction that is able to pick anything in 3D, but not at infinity at this moment (solved in the submitted code) - we might want to have intersector above plus support for transformations that extends frustum or geometry to the infinity (partially solved in the submitted code, e.g. it works well for all transformation matrices that have inverse.) - all above plus detecting intersections at infinity, but without ability to sort them from closest to furthest (not included in the submission, but probably not too difficult) - all above with the ability to sort intersections at infinity (challenging task, may need more math background) - some or all of above while start and end points can be both at infinity (not sure, but this may need completely extra code to handle this special case) Feel free to propose strategy. My inclination is to have only first two points with the vision to get the third. Thus, I would sort the intersections by one float (or double) only. Intersection point would be Vec4 in both - local and global coords. But feel free to choose a different strategy. This is just my inclination. Sorry for a long email. I wanted to dump my head as I will not be on email for one month starting from tomorrow morning. Thanks, John On Friday 31 of May 2013 15:54:02 Robert Osfield wrote: > Hi John, > > Thanks for the additional info. > > Intersecting objects at infinity is a curious thing, I hadn't thought > about needing a ratio with a w component. The barycentric coordinates > used for the vertices surrounding the intersected triangle can safely > stay as a float or double, although I'd need to look up the maths > involved to know about the interpolation of homogeneous coords. > > In terms of objects at infinity being effectively 2D, for ray > intersections you can think about all objects being 2D if you change > the coordinate frame so the ray is along the a local Z axis, then we > you transform all the geometry into this coordinate frame you'd just > test against XY and depth no longer becomes an issue. > > It might be reflecting on the maths involved might help refine what > the API and class structure should be. Leave this with me, I have > your implementation to work with, and can ponder on the public > interface to it and how we construct the back end. I can't promise > anything immediate though. If you mathematical friend has any further > suggestions that let me know. > > 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
