<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hello all,</p>
<p>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).</p>
<p>In general, these are all additional tests that make sense only
in the context of a call from DagMC:</p>
<ul>
<li>is this facet in a list of previous facets intersected by this
ray prior to this call</li>
<li>is this facet in a list of previous facets (or their
neighborhood) encountered during this call</li>
<li>is this intersection a piercing or glancing intersection as
defined by notions of surface sense known to DagMC</li>
</ul>
<p>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.</p>
<p>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.</p>
<p>Instead I propose the reduce the interface of all ray_intersect_*
methods to include only the following:</p>
<ul>
<li>const EntityHandle root_set: points to the root of the OBB
Tree</li>
<li>const double tolerance: for use in searching for intersections
(largely unused at the moment, I think)</li>
<li>const double ray_point[3]: starting point of ray</li>
<li>const double unit_vector[3]: direction of ray</li>
<li>std::pair<double*, double*> window: window to narrow
search for interesting intersections <br>
</li>
<li>std::pair<double*, double*> register_intersection(...):
call back function to perform application specific
filtering/disambiguation of possible intersection, returning an
updated window</li>
</ul>
<p>These methods would no longer return lists of intersections, but
would return them one at a time for consideration by the calling
application.</p>
<p>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???</p>
<p>Paul<br>
</p>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
Paul P.H. Wilson
Grainger Professor of Nuclear Engineering
608-263-0807
<a class="moz-txt-link-abbreviated" href="mailto:paul.wilson@wisc.edu">paul.wilson@wisc.edu</a>
419 Engineering Research Bldg
1500 Engineering Dr, Madison, WI 53706
calendar: <a class="moz-txt-link-freetext" href="http://go.wisc.edu/pphw-cal">http://go.wisc.edu/pphw-cal</a>
Computational Nuclear Engineering Research Group
cnerg.engr.wisc.edu
Faculty Director, Advanced Computing Initiative
aci.wisc.edu</pre>
</body>
</html>