Hi Robert, I have lost in your reasoning. Let me go back to be sure we understand each other.
> The bounding box based epsilon will likely fail when the size of the box is > very small compared to the length of the line segment. I came to conclusion that size of bounding box does not matter. Even the lenght of line segment does not matter. I came to this by considering that box and the line segment (both of size 10, f.ex.) might not be close to [0,0,0], but they may be translated 1e7 far away. In such case, even epsilon of 1 would not change the size of box or line because it is bellow the numerical precision of float that already holds value 10'000'000 and it is not possible to append 1. Even although we want to enlarge it by 10% (from 10 to 11), we can not do it because of high value the float is carrying. Thus, size of line and box does not matter. What matters is the absolute float value, that is 10'000'000 in this case, so epsilon should be 10'000'000 * 1e-5 = 100. If I am wrong in something, please point it out to move our discussion forward. If you have some other approach in mind, please, do the same. I am looking purely for the good solution acceptable for you and OSG. John On Tuesday 20 of August 2013 06:54:21 Robert Osfield wrote: > > ** > > We could use Robert's idea to get start and end points. From them, we can > > get the biggest value for epsilon as well that would provide "better" > > epsilon. It should be smaller in most cases, but still big enough to > > always > > work correctly. I just had doubts small bounding box [-1,-1,-1, 1,1,1] and > > start [2,0,0] and end point [1e7,0,0]. In this case, epsilon will be > > computed from end point 1e7 by multiplying 1e-5 with the result 100. Thus, > > bounding box will grow to [-101,-101,-101, 101,101,101], making false > > collision with start point [2,0,0]. Later computation in > > LineSegmentIntersector will remove the collision, but it costs > > computational time. > > > > After the consideration, my inclination is towards bounding box choosen > > epsilon (as opposite to start and end point based epsilon), as the user > > may > > tend to set high values for end points just to pick through the whole > > scene > > or to create fake ray, although not sure if I not overlooked something. > > The bounding box based epsilon will likely fail when the size of the box is > very small compared to the length of the line segment. It's better to be > conservative with this type of operation. If we get the computation right > then we should be able to reduce the size of the epsilon considerably. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
