<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi Iulian,</p>
<p><br>
</p>
<p>To summarize... It seems we have use cases within the Sigma
project that include:</p>
<ul>
<li>moab::DAGMC - currently only calls
moab::..::ray_intersect_sets with special purpose arguments</li>
<li>meshkit::EBMesher - currently only calls either
moab::..::ray_intersect_sets or
moab::..::ray_intersect_triangles with no special purpose
arguments</li>
<li>cgm::iGeom::iGeom_getPntRayIntsct - currently calls
cgm::...::fire_ray() methods</li>
<li>meshkit::advancing_front_alg - currently calls
cgm::..::closest_point_along_vector</li>
</ul>
<p>The first two of these are impacted by changes we are proposing
here, but the latter two are completely different.</p>
<p><br>
</p>
<p>Given the way that EBMesher works, it is probably best to keep
both interfaces in OrientedBoxTreeTool.</p>
<p><br>
</p>
<p>Paul<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 12/14/2016 10:08 AM, Grindeanu,
Iulian R. wrote:<br>
</div>
<blockquote
cite="mid:BB009D978283884B95AED82EEAE7D964B0884BB9@DITKA.anl.gov"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
<div style="direction: ltr;font-family: Tahoma;color:
#000000;font-size: 10pt;">Hello,<br>
I am all for simplifying if possible.<br>
<br>
It is clear that DagMC is the main user of this API, which works
directly on a OBB tree.<br>
The only other place we are using it is for EBMesher; there, we
use both ,<font color="FF0000"> ray_intersect_sets</font> and
<font color="FF0000">ray_intersect_triangles</font> on a obb
tree. <br>
<br>
For EBMesher, we actually fire only in 3 directions, but from
many points, along a structured mesh; but it is important to
retrieve all intersections, and it is important to understand
what portion of the ray is inside/outside the "solid body
geometry" we fire upon. A solid body is defined by its boundary
shell (a brep). <br>
<br>
EBMesher should actually work directly with iGeom, so it should
not care about obb tree; EBMesher is not using iGeom, though,
probably because it was too complex/unstable at that time:<br>
/**\brief Intersect a ray with the model<br>
*<br>
* Intersect a ray with the model. Storage orders passed in
should be a<br>
* member of the iBase_StorageOrder enumeration.<br>
* \param instance iGeom instance handle<br>
* \param x Point from which ray is fired<br>
* \param y Point from which ray is fired<br>
* \param z Point from which ray is fired<br>
* \param dir_x Direction in which ray is fired<br>
* \param dir_y Direction in which ray is fired<br>
* \param dir_z Direction in which ray is fired<br>
* \param intersect_entity_handles Entities intersected by
ray<br>
* \param intersect_entity_handles_allocated Allocated size
of<br>
* intersections array<br>
* \param intersect_entity_hangles_size Occupied size of
intersections array<br>
* \param storage_order Storage order of coordinates passed
back<br>
* \param intersect_coords Coordinates of intersections<br>
* \param intersect_coords_allocated Allocated size of
coordinates array<br>
* \param intersect_coords_size Occupied size of coordinates
array<br>
* \param param_coords Distances along ray of intersections<br>
* \param param_coords_allocated Allocated size of
param_coords array<br>
* \param param_coords_size Occupied size of param_coords
array<br>
* \param *err Pointer to error type returned from function<br>
*/<br>
void <font color="FF0000">iGeom_getPntRayIntsct</font>(
iGeom_Instance instance,<br>
double x,<br>
double y,<br>
double z,<br>
double dir_x,<br>
double dir_y,<br>
double dir_z,<br>
iBase_EntityHandle**
intersect_entity_handles,<br>
int*
intersect_entity_handles_allocated,<br>
int*
intersect_entity_hangles_size,<br>
int storage_order,<br>
double** intersect_coords,<br>
int* intersect_coords_allocated,<br>
int* intersect_coords_size,<br>
double** param_coords,<br>
int* param_coords_allocated,<br>
int* param_coords_size,<br>
int* err );<br>
<br>
Should we keep these APIs related ? They are doing about the
same thing<br>
<br>
iGeom is actually calling this, down deep:<br>
return GeometryQueryTool::instance()-><br>
fire_ray( nc_point, nc_direction, target_entities,
ray_params, 0, EPSILON, &entities );<br>
<br>
which is actually calling this (of GeometryQueryEngine)<br>
// Do the ray fire. Note we will sort the hits by distance and
append to the output lists.<br>
if( gqe-><font color="FF0000">fire_ray</font>( origin,
direction, tb_list, tmp_ray_params,<br>
max_hits, ray_radius, tb_hit_list_ptr ) == CUBIT_FAILURE )<br>
<br>
I don't want to complicate our lives, but should we look at
these APIs for comparison?
<br>
<br>
Or maybe not....<br>
<br>
In Meshkit, we need another "ray intersect capability" for the
new implementation of an advancing front algorithm , done by
Evan;
<br>
There, he is using cgm directly, with something like <br>
<br>
RefFace* cgmFacePtr =<br>
dynamic_cast<RefFace*>(reinterpret_cast<RefEntity*>(surface));<br>
Surface* cgmSrfcPtr = cgmFacePtr->get_surface_ptr();<br>
CubitStatus posDirResult = cgmSrfcPtr-><font color="FF0000">closest_point_along_vector</font>(<br>
cvRayOrigin, cvRayDir, cvPointOnSrfc);<br>
<br>
There, it is important to get just the first hit along the ray,
to project a 2d mesh from working plane on a 3d surface (the
working plane is relatively close to the 3d surface the mesh
needs to be projected on)<br>
<br>
<br>
Iulian<br>
<br>
<div style="font-family: Times New Roman; color: #000000;
font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF463375"><font
face="Tahoma" color="#000000" size="2"><b>From:</b>
<a class="moz-txt-link-abbreviated" href="mailto:moab-dev-bounces@mcs.anl.gov">moab-dev-bounces@mcs.anl.gov</a>
[<a class="moz-txt-link-abbreviated" href="mailto:moab-dev-bounces@mcs.anl.gov">moab-dev-bounces@mcs.anl.gov</a>] on behalf of Paul Wilson
[<a class="moz-txt-link-abbreviated" href="mailto:paul.wilson@wisc.edu">paul.wilson@wisc.edu</a>]<br>
<b>Sent:</b> Tuesday, December 13, 2016 11:18 AM<br>
<b>To:</b> Vijay S. Mahadevan; Patrick Shriwise<br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:moab-dev@mcs.anl.gov">moab-dev@mcs.anl.gov</a><br>
<b>Subject:</b> Re: [MOAB-dev] Digging into
ray_intersect_* in the OBBTreeTool - proposing an
interface change<br>
</font><br>
</div>
<div>
<p>Hi Vijay,<br>
</p>
<br>
<div class="moz-cite-prefix">On 12/13/2016 11:03 AM, Vijay
S. Mahadevan wrote:<br>
</div>
<blockquote type="cite">
<pre>Paul, IMO, if there is DagMC specific logic embedded in general ray
intersection code, and if no one has complained about it so far, my
guess is there aren't many users relying on that API. In which case,
I'm all for simplifying it.
</pre>
<blockquote type="cite">
<pre>These methods would no longer return lists of intersections, but would return them one at a time for consideration by the calling application.
</pre>
</blockquote>
<pre>However, it is very unclear to me how a calling application would know
whether to stop querying again or if it should be satisfied once the
first successful entity is found. If there is a stronger reasoning for
this behavioral change, that would help motivate the change better.
But as I said above, if DagMC is the sole consumer of this API, do
modify it so that it is part of the next version.</pre>
</blockquote>
<br>
Conceptually there is really no difference imposed by this
change. The calling application will be asked to accept
intersections one at a time rather than getting a list all
at once. As it is, the calling application has to decide
how to deal with that list (if it has more than one entry).
The simplest approach is to just add them all to a list and
end up with the same information as was originally
available.<br>
<br>
Perhaps the interface can offer both options:<br>
<ol>
<li>methods that return complete lists with not
opportunity for filtering/disambiguation and don't
require a callback function<br>
</li>
<li>methods that return nothing but require a callback
function to register each intersection as they arise
</li>
</ol>
<p>Paul<br>
</p>
<br>
<blockquote type="cite">
<pre>Vijay
On Tue, Dec 13, 2016 at 9:17 AM, Patrick Shriwise <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:shriwise@wisc.edu" target="_blank"><shriwise@wisc.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre>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
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:paul.wilson@wisc.edu" target="_blank">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" target="_blank">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>
</blockquote>
<br>
<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" target="_blank">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" target="_blank">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>
</div>
</div>
</div>
</blockquote>
<br>
<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>