[MOAB-dev] Digging into ray_intersect_* in the OBBTreeTool - proposing an interface change

[Paul Wilson]

Hello all,

I have been spending a lot of quality time with the ray_intersect_* 
methods of the OrientedBoxTreeTool over the last few weeks.  I think I 
have (re)learned all the subtleties of the additional code that exists 
in RayIntersectSets::leaf() (invoked with API function ray_intersect_sets).

In general, these are all additional tests that make sense only in the 
context of a call from DagMC:

  * is this facet in a list of previous facets intersected by this ray
    prior to this call
  * is this facet in a list of previous facets (or their neighborhood)
    encountered during this call
  * is this intersection a piercing or glancing intersection as defined
    by notions of surface sense known to DagMC

There is then a complex logic related to how many intersections to keep 
based on three quantities: two are a "window" in which the distance to 
distance to intersection must fall and the third is a count of how many 
intersections to keep.

The logic for ray_intersect_triangles() includes none of this.  I was 
contemplating an interface change to ray_intersect_triangles() that 
would add enough information to include the same tests, and modularizing 
those tests to reuse code in both places.  However, (a) the interface 
for that would be awkward and (b) it would be imposing DagMC conventions 
on even more code.

Instead I propose the reduce the interface of all ray_intersect_* 
methods to include only the following:

  * const EntityHandle root_set: points to the root of the OBB Tree
  * const double tolerance: for use in searching for intersections
    (largely unused at the moment, I think)
  * const double ray_point[3]: starting point of ray
  * const double unit_vector[3]: direction of ray
  * std::pair<double*, double*> window: window to narrow search for
    interesting intersections
  * std::pair<double*, double*> register_intersection(...): call back
    function to perform application specific filtering/disambiguation of
    possible intersection, returning an updated window

These methods would no longer return lists of intersections, but would 
return them one at a time for consideration by the calling application.

Since this is such a major interface change, I thought I'd solicit 
feedback before embarking upon it.  It won't necessarily bee that much 
code change, but who knows how it impacts other possible users of this 
code???

Paul


-- 
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --

Paul P.H. Wilson
Grainger Professor of Nuclear Engineering
608-263-0807
paul.wilson at wisc.edu
419 Engineering Research Bldg
1500 Engineering Dr, Madison, WI 53706
calendar: http://go.wisc.edu/pphw-cal

Computational Nuclear Engineering Research Group
cnerg.engr.wisc.edu

Faculty Director, Advanced Computing Initiative
aci.wisc.edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20161209/793c6ede/attachment.html>