Hi Jaap, In svn/trunk I've introduced the ability to set the Eplsion value to a user specified value rather than the default of 1e-4, this may not be an ideal solution though, I'd much rather have the code work with defaults correctly.
The clipping of the line length to the bounding box is done to make it more likely that intersection tests will be more rejected more quickly so speeding up the intersections. We could add an option to disable this clipping and explore just much of an impact it has. Scaling the epsilion by the size of the bounding box is a possibility, but this would cause problems with small objects but with relatively large xyz values. One could possible have a constant and scaled epsilon term to get round this. A double version of the intersection functions wold be another possibility. Robert. On 16 May 2013 09:07, Jaap Glas <[email protected]> wrote: > Dear Peter, Robert, and all. > > I would like to endorse Peter's remarks on the current implementation of > the LineSegmentIntersector. We experience precisely the same problems when > trying to pick on plane faces that coincide with the bounding box of the > Drawable to which they belong. The simplest example is a drawable consisting > of one triangle or quad aligning with the axes of the local coordinate frame. > > Like Peter, we are also dealing with co-ordinate values running into the > thousands. The applied epsilon of 1e-4 in the intersectAndClip() function > is too small in suchlike cases, especially if the TriangleIntersector keeps > using floats at some places. > > For the moment, we circumvent the problem by overloading the computeBound() > function of the Drawable and return a slightly bigger bounding box ourselves, > but a more general solution would be better in the end. > > Like Peter, I also do not see why the intersectAndClip() function should > cut off those parts of the line segment that are outside the bounding box. > What is the computational benefit of this later on? I would expect it is > sufficient to check whether the line segment is crossing the box or not, > and neglect Drawables for which the answer is false. > > However, assuming that this clipping does serve a goal, then my choice > would be not to assign the epsilon in the intersectAndClip() function > an absolute value, but to make it relative to the bounding box size, > for example by multiplying the current epsilon of 1e-4 with the diagonal > length of the bounding box. > > > Best regards, > > Jaap Glas > > dGB Earth Sciences > Enschede, The Netherlands > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=54027#54027 > > > > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
