Hi Robert and Alistair,
I gave it another long thought and found one more idea. Let me show it on
example of
bounding box of bb_max.[x,y,z] set to 1'000'000 and bb_min.[x,y,z] set to
999'999. I such
case, the size of bounding box does not matter and distance of start and end
neither
(unfortunately) as both are about 1.0. By multiplication of 1e-5, we get pretty
small number
that would not change bounding box in any way if substracted or added to any
component
of bounding box.
I admit that this is not well designed scene but it shows the precision problem
as it is, if I am
not mistaken. In my opinion, we should just take the biggest number of all
bounding box
float values while ignoring the sign. Then, we multiply the biggest value by
1e-5 to get
epsilon. This should provide the value big enough value to move all the sides
of the bounding
box while computations based on bounding box size does not always serve this
purpose.
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.
Does it seems reasonable? Some more ideas?
John
On Monday 19 of August 2013 08:50:46 Robert Osfield wrote:
Hi John et. al,
I too am not too happy with the approach of a fixed epilson, adding the ability
for the user to
set this value isn't much better.
Scaling the epsilon by the size of the bounding box may be an improvement but
I'm not yet
convinced it's the best approach. The epsilon is there is account for
numerical precision
issues associated with the mathematical functions being performed.
The maths in this case is clamping the present line segment start and end
points to the
bounding box, here the distance of the sides from the start and the start to
the end point
along each axis is what will determine the size of the values and the range of
the numerical
errors that are likely. The largest value is likely to be the length of the
line segment so might
be the best distance to use as the scale.
Thoughts?Robert.
On 19 August 2013 06:38, PCJohn <pec...@fit.vutbr.cz[1]> wrote:
Hi Robert,
there was recently a commit concerning epsilon in LineSegmentIntersectorthat is
now
carried as class member. I can imagine motivation behind, but Ibelive there is
a better
approach to the problem.
If the motivation is just to allow the setting bigger epsilon for biggerobjects
(too small
epsilon, recently statically assigned to 1e-5, will notaffect big bounding
boxes because of
limited float resolution. I belive, thiswas the motivation behind the change
for the person
who submitted the patch.)
The correct solution in my opinion would be to make epsilon depend on size
ofbounding box
of the intersected object:
// extend bounding box a little bit to avoid floating point imprecisions
double epsilon =
(bb_max-bb_min).length() * 1e-5; bb_min.x() -= epsilon; bb_min.y() -=
epsilon; bb_min.z()
-= epsilon; bb_max.x() += epsilon; bb_max.y() += epsilon; bb_max.z()
+= epsilon;
This should work in all cases, for both - small and big objects.
Hard-codingepsilon, even when
giving the user the ability to change it, is not correctway in my opinion, as
there may be very
small objects (requiring smallepsilon) together with big objects (requiring big
epsilon) in the
scene. Wecan give the user the callback to adjust the epsilon for each visited
objectin the
scene, but I do not belive this is the best approach._______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
