<div dir="ltr"><div><div><div><div>I have no better solution for topological cracks that what is currently implemented with the radius.<br></div></div>Actually i've looking at it too fast, there is no design problem in the current implementation, and I understand complettelly why we need to limit the walk.<br><br></div>However there is a typo !<br> if(cell->EvaluatePosition(x, closestPoint, subId,<br> pcoords, dist2, weights) == 1<br> && (dist2 <= tol2))<br> { <br> return cellId;<br> } <br><br></div><div>Should be :<br></div><br><div><div><div><div> int ret = cell->EvaluatePosition(x, closestPoint, subId,<br> pcoords, dist2, weights);<br> if (ret == 1 || ( ret == 0 && dist2 <= tol2))<br> { <br> return cellId;<br> } <br><br></div><div>Doesn't it ?<br></div><div><br></div></div></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Mathieu Westphal<br></div></div></div>
<br><div class="gmail_quote">On Thu, Jul 9, 2015 at 4:15 PM, Will Schroeder <span dir="ltr"><<a href="mailto:will.schroeder@kitware.com" target="_blank">will.schroeder@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Mathieu-<div><br></div><div>I am going to look this over on the weekend. There are several known issues due to a variety of complex reasons; and if I remember right there are pathological cases with what you propose (walking across neighbors) because if there is topological separation/cracks between neighboring cells it's possible to fail too.</div><div><br></div><div>Anyway I'll have a chance to look this weekend and we'll talk soon. I think the bottom line is that to 100% guarantee to find the containing cell a cell locator is needed, but for performance/memory reasons a point locator has been used in the past (unfortunately a performance tradeoff that comes back to bite us repeatedly). There may be more intelligent ways to consider the N closest points from FindPoint which may produce better results and don't cost too much in performance/memory.</div><div><br></div><div>W</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, Jul 9, 2015 at 6:10 AM, Mathieu Westphal <span dir="ltr"><<a href="mailto:mathieu.westphal@kitware.com" target="_blank">mathieu.westphal@kitware.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><div>There is a bug in vtkPointCell::FindCell<br><br></div>I copy here my mantis bug and associated notes:<br><a href="http://www.vtk.org/Bug/view.php?id=15573" target="_blank">http://www.vtk.org/Bug/view.php?id=15573</a><br><br>The current implementation of FindCell/ FindCellWalk is just wrong and not working in some case :<br>
<br>
See atached image.<br>
In the current implementation there is three pass :<br>
<br>
1 : FindPoint, Check CellPoint<br>
2 : Check first neighbor<br>
3 : Check CellPoint within tolerance<br>
<br>
In the associated image, one can see the the first pass will find red star and only check Cell 1<br>
the second pass will only check cell 2<br>
the third pass will not check anything more<br>
<br>
Cell 3 will never be found.<br><br><a name="14e732c80e2e5630_14e724b6ec8e85d8_bugnotes">I propose a solution based on
vtkStreamTracer surface implementation, which walk among neighbors more
smartly using pcoords and cell boundary.<br>
<br>
See :<br>
</a><a href="https://gitlab.kitware.com/vtk/vtk/blob/master/Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.cxx#L289" target="_blank">https://gitlab.kitware.com/vtk/vtk/blob/master/Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.cxx#L289</a> [<a href="https://gitlab.kitware.com/vtk/vtk/blob/master/Filters/FlowPaths/vtkAbstractInterpolatedVelocityField.cxx#L289" target="_blank">^</a>]<br><br></div>What do you think ?<span><font color="#888888"><br><div><br clear="all"><div><div><div><div><div dir="ltr">Mathieu Westphal<br></div></div></div>
</div></div></div></font></span></div>
<br></div></div>_______________________________________________<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
<br>
<br></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div>William J. Schroeder, PhD<br>Kitware, Inc.<br>28 Corporate Drive<br>Clifton Park, NY 12065<br><a href="mailto:will.schroeder@kitware.com" target="_blank">will.schroeder@kitware.com</a><br><a href="http://www.kitware.com" target="_blank">http://www.kitware.com</a><br><a href="tel:%28518%29%20881-4902" value="+15188814902" target="_blank">(518) 881-4902</a></div>
</font></span></div>
</blockquote></div><br></div>