On Wed, Jul 17, 2013 at 12:11 PM, phoenix <[email protected]> wrote:
> > Am I correct that your tests so far have not needed to track the fuzzy
> uncertainties involved with propagating "error bars" through multiple
> intersections? Let's say, for example, that two curves intersect at a
> point, within some tolerance. However, if we test both of those curves and
> that intersection point against a surface, one curve intersects the surface
> within tolerance, one does not, and the point does. What do we do?
>
> I mainly work on individual intersections currently, and take the fuzzy
> uncertainties that might happen with multiple intersections into
> consideration. Although the default tolerance is 0.001, in the
> implementation, I try to make it even more accurate (without too much
> effect on performance), so as to reduce the accumulative errors. But as for
> the example you mentioned above, which seems contradictory, may still
> happen. (I think a more common case is that the two curves both intersect
> the surface but the point doesn't, because the point has larger uncertainty
> due to curve-curve intersection, and the curves are more accurate.) So when
> we have multiple intersections (e.g. during evaluation a NURBS
> combination), we need to track the fuzzy uncertainties, and use different
> tolerances to suit the propagating error?
>
I'm not actually sure what the "best" solution is. I had a vague notion
(which I think originated with Sean and probably got distorted in
transition to my brain) of building a "topology map" that keeps track of
the various individual intersections and how they relate to each other,
then makes a final pass to make the best decisions that can be made. I
would actually expect that your example of two curves and a surfaces almost
converging at a point would have the point (with its larger uncertainty
bounds) intersect the surface where neither of the two curves do. In that
example, if we are building an abstract topology map, the three points in
question (the two from the two curves and the surface point that
intersected with the wider tolerance curve intersection point) and
knowledge of which curve/surface they originate from would be incorporated
into that "node". At the end of the intersection process, there would be a
series of nodes connected to various curves and surfaces and a "final
decision" could be made with full knowledge of all of the geometric
elements that are (potentially) interacting within the volume of each node,
rather than having merging decisions made "early" in the process causing
trouble further up the merge tree.
As I say, that's a vague description based on half remembered conversations
of how to approach the issue, so hopefully Sean will be able to point the
way towards a truly "robust" approach. (Plus the various papers listed,
which I haven't had time to wade through yet...)
CY
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
