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

[Patrick Shriwise]

Hi all,

Having seen how many other ray tracing codes operate I think that these 
are valuable changes to the OrientedBoxTreeTool which will allow it to 
be extended to many other applications.

Pulling out these DAGMC-specific intersection disambiguation operations 
into separate functions for filtering intersections will also allow them 
to be applied in other ray tracing kernels (AdaptiveKDTree, etc.) if 
desired.

-Patrick

Patrick C. Shriwise
Research Fellow
University of Wisconsin - Madison
Engineering Research Building - Rm. 428
1500 Engineering Drive
Madison, WI 53706
(608) 446-8173

On 12/09/2016 04:44 PM, Paul Wilson wrote:
>
> 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/20161212/aa100fc7/attachment.html>