[vtkusers] Problems with vtkClipPolyData and vtkImplicitBoolean

[David Gobbi]

Hi Normanius,

Yes, accuracy is a definite concern when clipping with curved implicit
surfaces.  Which is why I usually stick to planes.

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.

Implicit functions can fail in two ways that I'm aware of:
1) they clip the edge at the wrong position (i.e. the accuracy issue that
you mention)
2) the implicit surface can intersect the polygon face without intersecting
any edges

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.

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.

For example, a few years ago I wrote a class called vtkClipClosedSurface
(see http://www.vtk.org/Wiki/index.php?title=VTK/Closed_Surface_Clipping)
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.

So that's my advice: write a new filter class, rather than modifying
vtkTriangle or the other cell classes right off the bat.

 - David

On Mon, Jan 4, 2016 at 8:20 AM, Cory Quammen <cory.quammen at kitware.com>
wrote:

> Hi Normanius,
>
> 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.
>
> 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.
>
> 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.
>
> Thanks for the interesting work,
> Cory
>
> On Fri, Jan 1, 2016 at 8:10 AM, normanius <juch at zhaw.ch> wrote:
>
>> Hi VTK-developers
>>
>> I implemented a hack that solves the above problem for me. See the result
>> (before and after):
>>
>> <http://vtk.1045678.n5.nabble.com/file/n5735721/comparison.jpg>
>>
>> Below the two patches. The second patch is the important one. The first
>> one
>> just implements the suggested linear distance metric for vtkCylinder. (I
>> branched off from the revision git-hash ac7a28f).
>> patch-001-linear-cylinder-function.diff
>> <
>> http://vtk.1045678.n5.nabble.com/file/n5735721/patch-001-linear-cylinder-function.diff
>> >
>> patch-002-clippolydata-triangle-clipping-fix.diff
>> <
>> http://vtk.1045678.n5.nabble.com/file/n5735721/patch-002-clippolydata-triangle-clipping-fix.diff
>> >
>>
>> Here is what I did roughly: In vtkTriangle::Clip(), use the bisection
>> method
>> to correctly find the "zero-crossing", as an alternative to the linear
>> interpolation that is the method of choice in the current release. The
>> bisection method requires a handle to the implicit function and the
>> iso-value used in vtkClipPolyData. If in the cell traversal in
>> vtkClipPolyData::RequestData() the current vtkGenericCell turns out to be
>> of
>> triangular type, it gets dirty-casted into vtkTriangle and the implicit
>> function and the iso-value are set. This will trigger the advanced
>> interpolation scheme in vtkTriangle::Clip().
>>
>> Obviously, my fix works only for triangular meshes. I haven't spent a
>> thought on how to generalise and implement this properly. Let me know what
>> you think. Shall create an issue in your bug-tracker?
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://vtk.1045678.n5.nabble.com/Problems-with-vtkClipPolyData-and-vtkImplicitBoolean-tp5735713p5735721.html
>> Sent from the VTK - Users mailing list archive at Nabble.com.
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the VTK FAQ at:
>> http://www.vtk.org/Wiki/VTK_FAQ
>>
>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtkusers
>>
>
>
>
> --
> Cory Quammen
> R&D Engineer
> Kitware, Inc.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160107/7da5e134/attachment-0001.html>