<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi all, <br>
</p>
<p>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.</p>
<p> 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.</p>
<p>-Patrick<br>
</p>
<pre class="moz-signature" cols="72">Patrick C. Shriwise
Research Fellow
University of Wisconsin - Madison
Engineering Research Building - Rm. 428
1500 Engineering Drive
Madison, WI 53706
(608) 446-8173
</pre>
<div class="moz-cite-prefix">On 12/09/2016 04:44 PM, Paul Wilson
wrote:<br>
</div>
<blockquote cite="mid:289f8b8f-bdff-a59d-f7a4-46a7372bc345@wisc.edu"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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 moz-do-not-send="true" 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 moz-do-not-send="true" 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>
</blockquote>
<br>
</body>
</html>