[vtkusers] recent vtkClipDataSet can give non-tets?

[Adrian Umpleby]

>> I've been using vtkClipDataSet with version 4.2 of vtk to cut off a 
>> hexahedral mesh at a scalar value of zero. This gives all tets... 
>> just as the (latest) documentation says...
>> However, I've recently been using it on some upgraded Linux boxes 
>> which have version 4.4 of vtk, and now I find a whole load of wedges 
>> coming out of vtkClipDataSet!
>> Is this the way vtkClipDataSet is supposed to behave now? Is there a 
>> way to choose to switch it back to tets? (Couldn't see anything in 
>> member list.)
>
> That's correct. Try to clip a tetra, you'll realize that there are a 
> bunch of possibilties for the clip to return a wedge.

Note that I said I'm clipping hexahedra, so the possible polyhedra can 
be quite mind-boggling - vtkClipDataSet would have to return such 
polyhedra in a split up configuration just to get down to even mostly 
hexas again...

(I'm guessing, though, that vtkClipDataSet first splits up the mesh 
into tets [using something like vtkDataSetTriangleFilter?] before 
clipping - so wedges make sense if nothing else is done to the clipped 
cells. Having said that, I'm curious what happens in the case of 
quadratic cells? - quad-tets can end up with more than one cut 
[strictly not even planar!] for a single scalar value... it's 
interesting to note that even cutting a linear hexa isn't necessarily 
planar - I'd expect the results from vtkClipDataSet can depend a lot on 
which way the original hexas are split. But I'm getting off the subject 
here...)

> So yes wedge is the general output of clip ( vtkClipDataSet even 
> return wedges with two edges collapsed (=tetra), but vtkGeometryFilter 
> handles those 'fake' tetras).
>
> What is your problem ?

Note that it's not actually a problem - I need tets at the end, so all 
I've done to get around it is put the clipped dataset through 
vtkDataSetTriangleFilter.

However, the issue is that the latest documentation says vtkClipDataSet 
produces an all-tet mesh. This was correct under vtk 4.2, but appears 
to no longer be correct for vtk 4.4.

I was simply wondering if this could be acknowledged as "the way it's 
supposed to be" now (i.e. the docs need updating), or maybe some sort 
of bizarre bug (resulting mesh appears to conform correctly, so I find 
this hard to believe), or an oversight after some recent change.

Hope that makes it clearer!

Adrian