<div dir="ltr">Hi Normanius,<div><br></div><div>Yes, accuracy is a definite concern when clipping with curved implicit surfaces. Which is why I usually stick to planes.</div><div><br></div><div>Regarding the the use of squared metric for the implicit cylinder and sphere, maybe it was done for the sake of computational efficiency (avoiding the square root). Yes, a linear measure would be more accurate, and I'd definitely prefer it if the implicit functions used linear measures.</div><div><br></div><div>Implicit functions can fail in two ways that I'm aware of:</div><div>1) they clip the edge at the wrong position (i.e. the accuracy issue that you mention)</div><div>2) the implicit surface can intersect the polygon face without intersecting any edges</div><div><br></div><div>Your bisection search is a good way to can be used to fix issue (1), though Newton's method would be faster. Issue (2) is much more difficult to fix, because it requires a two-dimensional search rather than a one-dimensional search.</div><div><br></div><div>I think that implementing the bisection search as a direction replacement for VTK's current Clip() method is a non-starter because of efficiency issues. It would have to be implemented as an alternative method, so that people would have a choice of which method to use.</div><div><br></div><div>For example, a few years ago I wrote a class called vtkClipClosedSurface (see <a href="http://www.vtk.org/Wiki/index.php?title=VTK/Closed_Surface_Clipping">http://www.vtk.org/Wiki/index.php?title=VTK/Closed_Surface_Clipping</a>) that implemented a new clipping method specifically for polydata cells (polygons, triangle strips, and lines). The fact that this change was done in a single class made it much easier to integrate into VTK. If I'd tried to change all of the vtkCell classes, my chances of getting the change into VTK would have been very low. Also, by writing my own class, it meant that I could use std::vector as the container in my algorithms.</div><div><br></div><div>So that's my advice: write a new filter class, rather than modifying vtkTriangle or the other cell classes right off the bat.</div><div><br></div><div> - David</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 4, 2016 at 8:20 AM, Cory Quammen <span dir="ltr"><<a href="mailto:cory.quammen@kitware.com" target="_blank">cory.quammen@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Normanius,<div><br></div><div>I'm CC'ing David Gobbi for his expertise in geometry operations in VTK as he likely has some insight in the issue and what you've done.</div><div><br></div><div>Looking at the other implicit functions besides vtkPlane, it looks like most evaluate the squared distance rather than the linear distance, so this appears to be by design. I'm not familiar with the history of the classes, but, as you suspect, I wouldn't recommend changing the current behavior of vtkCylinder because it would be a backwards-incompatible change. Instead, for your application, I would recommend subclassing vtkCylinder and overriding the EvaluateFunction() and possibly EvaluateGradient() if you need it to compute the non-squared distances.</div><div><br></div><div>Regarding your second patch, I am intrigued by using a bisection method or other solver to find the zero-crossing of the implicit function. Your results with the combined cylinder and planes look very nice. I might recommend changing from specifying the clipping function from vtkImplicitFunction to something more general, like a callback function, though I'm not completely sold on that, and moving the setting/getter to vtkCell so that other cells might someday make use of the zero-crossing function.</div><div><br></div><div>Thanks for the interesting work,</div><div>Cory</div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Fri, Jan 1, 2016 at 8:10 AM, normanius <span dir="ltr"><<a href="mailto:juch@zhaw.ch" target="_blank">juch@zhaw.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi VTK-developers<br>
<br>
I implemented a hack that solves the above problem for me. See the result<br>
(before and after):<br>
<br>
<<a href="http://vtk.1045678.n5.nabble.com/file/n5735721/comparison.jpg" rel="noreferrer" target="_blank">http://vtk.1045678.n5.nabble.com/file/n5735721/comparison.jpg</a>><br>
<br>
Below the two patches. The second patch is the important one. The first one<br>
just implements the suggested linear distance metric for vtkCylinder. (I<br>
branched off from the revision git-hash ac7a28f).<br>
patch-001-linear-cylinder-function.diff<br>
<<a href="http://vtk.1045678.n5.nabble.com/file/n5735721/patch-001-linear-cylinder-function.diff" rel="noreferrer" target="_blank">http://vtk.1045678.n5.nabble.com/file/n5735721/patch-001-linear-cylinder-function.diff</a>><br>
patch-002-clippolydata-triangle-clipping-fix.diff<br>
<<a href="http://vtk.1045678.n5.nabble.com/file/n5735721/patch-002-clippolydata-triangle-clipping-fix.diff" rel="noreferrer" target="_blank">http://vtk.1045678.n5.nabble.com/file/n5735721/patch-002-clippolydata-triangle-clipping-fix.diff</a>><br>
<br>
Here is what I did roughly: In vtkTriangle::Clip(), use the bisection method<br>
to correctly find the "zero-crossing", as an alternative to the linear<br>
interpolation that is the method of choice in the current release. The<br>
bisection method requires a handle to the implicit function and the<br>
iso-value used in vtkClipPolyData. If in the cell traversal in<br>
vtkClipPolyData::RequestData() the current vtkGenericCell turns out to be of<br>
triangular type, it gets dirty-casted into vtkTriangle and the implicit<br>
function and the iso-value are set. This will trigger the advanced<br>
interpolation scheme in vtkTriangle::Clip().<br>
<br>
Obviously, my fix works only for triangular meshes. I haven't spent a<br>
thought on how to generalise and implement this properly. Let me know what<br>
you think. Shall create an issue in your bug-tracker?<br>
<br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://vtk.1045678.n5.nabble.com/Problems-with-vtkClipPolyData-and-vtkImplicitBoolean-tp5735713p5735721.html" rel="noreferrer" target="_blank">http://vtk.1045678.n5.nabble.com/Problems-with-vtkClipPolyData-and-vtkImplicitBoolean-tp5735713p5735721.html</a><br>
<div><div>Sent from the VTK - Users mailing list archive at Nabble.com.<br>
_______________________________________________<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>
Please keep messages on-topic and check the VTK FAQ at: <a href="http://www.vtk.org/Wiki/VTK_FAQ" rel="noreferrer" target="_blank">http://www.vtk.org/Wiki/VTK_FAQ</a><br>
<br>
Search the list archives at: <a href="http://markmail.org/search/?q=vtkusers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtkusers</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/vtkusers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/vtkusers</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div>Cory Quammen<br>R&D Engineer<br>Kitware, Inc.</div>
</font></span></div>
</blockquote></div><br></div></div></div>