Hi John, I'm a bit confused as what to further explain. For precision purposes it's the math operations done to clamp the line segment to the bounding box that is important. The maths operations bascially use the length of the line segment in each axis and the distance from each face to the start point. An epsilon based on the largest of this values is probably the thing to go for, although one might simply simply it and us the length in each axis of the linesegment otherwise you'd need to introduce if()else blocks that are relatively expensive for the processor to handle.
Robert. On 20 August 2013 10:33, PCJohn <pec...@fit.vutbr.cz> wrote: > 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 > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
