[vtk-developers] Adding ComputeArea() to vtkTriangle

Tue Dec 22 16:03:30 EST 2009

On Tue, Dec 22, 2009 at 3:31 PM, John Platt <jcplatt at dsl.pipex.com> wrote:

> Hi,
>
> Have you considered computing the cell size numerically? I seem to recall
> that Gaussian quadrature will give the exact area/volume for polynomial
> edges provided the integration order is set appropriately. This can be done
> with one function for triangles & quads, another for pentahedrons & hex's
> and possibly a 3rd for tetrahedrons & pyramids (including the nonlinear
> variants). You should expect the size to be negative if the cell is
> inside-out, or severely distorted with the determinant of the Jacobian
> changing sign between integration points.
>
> Just a thought.
>
> John.
>
> ----- Original Message ----- From: "Bill Lorensen" <
> bill.lorensen at gmail.com>
> To: "Berk Geveci" <berk.geveci at kitware.com>
> Cc: "VTK Developers" <vtk-developers at vtk.org>; "Moreland,Kenneth" <
> kmorel at sandia.gov>
> Sent: Tuesday, December 22, 2009 5:24 PM
> Subject: Re: [vtk-developers] Adding ComputeArea() to vtkTriangle
>
>
>
> I agree with Berk. ComputeArea() for triangle is enough. Maybe also
> for vtkPolygon. There is already a TriangleArea method in vtkTriangle
> and a ComputeArea() in vtkPolygon.  David D's ComputeArea() is a good
> convenience addition.
>
> On Tue, Dec 22, 2009 at 12:12 PM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
>
>> I don't think that this is a good idea. Users will expect a method
>> that computes "size" in vtkCell to do it "right". However, unless you
>> are subdividing adaptively, simple subdivision is likely to be very
>> inaccurate for higher order cells. Having a default implementation
>> that may be inaccurate for bunch of subclasses is a bad ideas unless
>> you have the time and resources to go to all subclasses and override
>> the default implementation.
>>
>> We started with a very simple request: add ComputeArea() to
>> vtkTriangle. Now, we are talking about going down a path that is long
>> and somewhat researchy - without resources to go all the way. Unless
>> David is willing to spend some significant amount of time figuring out
>> how to compute the volume of higher order elements accurately, I'd
>> suggest going back to the original ComputeArea() and skipping the
>> ComputeSize() idea.
>>
>> -berk
>>
>> On Tue, Dec 22, 2009 at 10:03 AM, Moreland, Kenneth <kmorel at sandia.gov>
>> wrote:
>>
>>> Why not have a default implementation that breaks the cell into simplicia
>>> (line segments, triangles, or tetrahedra)? That’s what vtkCellIntegrator
>>> (attached) does.
>>>
>>> -Ken
>>>
>>>
>>> On 12/22/09 7:53 AM, "David Doria" <daviddoria+vtk at gmail.com<daviddoria%2Bvtk at gmail.com>>
>>> wrote:
>>>
>>>
>>> On Mon, Dec 21, 2009 at 10:53 AM, Moreland, Kenneth <kmorel at sandia.gov>
>>> wrote:
>>>
>>> Yes, but the vtkCell classes (of which vtkTriangle is one) is not really
>>> like the vtkDataObject objects. These classes are designed to hold
>>> methods
>>> for common computations. For example, they already hold methods for
>>> computing interpolation, derivatives, contours, and intersections. In
>>> this
>>> regard, a method to compute the length/area/volume of the cell is wholly
>>> appropriate.
>>>
>>> My only criticism (everyone has to have an opinion, right?) is that it
>>> would
>>> be helpful if there was a pure virtual method in vtkCell, perhaps called
>>> ComputeSize, that returned the length, area, or volume (depending on the
>>> dimensionality of the cell). That way you would not have to down cast the
>>> vtkCell to some known subclass and hope the implementation is there.
>>>
>>> Now that I write this, it occurs to me that somewhere there is a
>>> vtkCellIntegrator in ParaView that does something similar. Perhaps the
>>> implementation of that could be duplicated in vtkCell.
>>>
>>> -Ken
>>>
>>>
>>>
>>> On 12/18/09 12:15 PM, "Berk Geveci" <berk.geveci at kitware.com
>>> <http://berk.geveci@kitware.com> > wrote:
>>>
>>> I think Mathieu brings up an important point. I don't think this has
>>> any direct impact on the issue here but it is still a good one. VTK
>>> usually separates computation from the data structures. There is a
>>> good reason behind this. For example, when you are computing the
>>> volume of a polyhedron or performing some other numerical integration
>>> over it, there may be more than one way to do it numerically. Some
>>> more accurate but more costly, others less accurate but faster. This
>>> is why you don't find a lot of computational geometry related methods
>>> on vtkPolyData.
>>>
>>> On Fri, Dec 18, 2009 at 11:09 AM, Mathieu Malaterre
>>> <mathieu.malaterre at gmail.com <http://mathieu.malaterre@gmail.com> >
>>> wrote:
>>>
>>>> Ok, my bad. I thought this was introducing a new framework to compute
>>>> 2D area which seem difficult to extend to 3d cell.
>>>>
>>>> thanks for clarification.
>>>>
>>>> On Fri, Dec 18, 2009 at 5:05 PM, Bill Lorensen <bill.lorensen at gmail.com
>>>> <http://bill.lorensen@gmail.com> > wrote:
>>>>
>>>>> Mathieu,
>>>>>
>>>>> vtkTriangle is a cell. It is not filter. It currently has a
>>>>> TriangleArea() method, but it is cumbersome to use. David is proposing
>>>>> a convenience method to do the computation. It calls the
>>>>> TriangleArea() method but save the user from setting up the parameters
>>>>> for that call.
>>>>>
>>>>> Bill
>>>>>
>>>>> On Fri, Dec 18, 2009 at 10:54 AM, David Doria <
>>>>> daviddoria+vtk at gmail.com <daviddoria%2Bvtk at gmail.com>
>>>>> <http://daviddoria+vtk@gmail.com> > wrote:
>>>>>
>>>>>> On Fri, Dec 18, 2009 at 10:51 AM, Mathieu Malaterre
>>>>>> <mathieu.malaterre at gmail.com <http://mathieu.malaterre@gmail.com> >
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> Hi David,
>>>>>>>
>>>>>>> I do not have a strong opinion on this particular case.
>>>>>>> However here is a couple of thoughts, I have from my modest
>>>>>>> understanding of VTK.
>>>>>>> 1. I would really separate source/sink from filter. You are writing a
>>>>>>> partial filter (aka algorithm) in a data object.
>>>>>>> 2. You are duplicating (possibly) code from vtkMeshQuality.
>>>>>>>
>>>>>>> 2cts
>>>>>>> -Mathieu
>>>>>>>
>>>>>>
>>>>>> 1) I'm not sure I follow. Isn't vtkTriangle an "object", not a
>>>>>> "source"
>>>>>> or
>>>>>> "filter"?
>>>>>> 2) That is likely the case and that is exactly my point here -
>>>>>> vtkMeshQuality (or anything else) should not have to implement this
>>>>>> code, it
>>>>>> should just be able to call ComputeArea() on a triangle object.
>>>>>> Thanks,
>>>>>>
>>>>>> David
>>>>>> _______________________________________________
>>>>>> Powered by www.kitware.com <http://www.kitware.com>
>>>>>>
>>>>>> Visit other Kitware open-source projects at
>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>
>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>>>>
>>>>>>
>>>>>>
>>>>>>  _______________________________________________
>>>>> Powered by www.kitware.com <http://www.kitware.com>
>>>>>
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Mathieu
>>>> _______________________________________________
>>>> Powered by www.kitware.com <http://www.kitware.com>
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>>
>>>>
>>>>  _______________________________________________
>>> Powered by www.kitware.com <http://www.kitware.com>
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>
>>>
>>>
>>>
>>>
>>>
>>> Per Ken's suggestion, I am trying to implement a virtual double
>>> ComputeSize() function for vtkCell. There are a lot of cells! Many of
>>> which
>>> I have no idea how to get their size. Is it acceptable to somehow commit
>>> these changes without having all of them implemented? Something like a
>>> filler "return 0" and a comment "this function has not yet been
>>> implemented"?
>>>
>>> The idea would be that then the framework is setup, so when a developer
>>> who
>>> is familiar with the particular cell subclass sees the missing
>>> implementation, they could easily fill it in.
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>>
>>> David
>>>
>>>
>>>
>>> **** Kenneth Moreland
>>> *** Sandia National Laboratories
>>> ***********
>>> *** *** *** email: kmorel at sandia.gov
>>> ** *** ** phone: (505) 844-8919
>>> *** web: http://www.cs.unm.edu/~kmorel
>>>
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>
>>>
>>>
>>>  _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>
>>
>>  _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
>
>
This is indeed a big project to implement correctly. I'll stick with the two
functions that I can handle well and leave the rest for a larger group
effort at a later date.

I have added ComputeArea() for vtkTriangle and vtkPolygon. Before I commit
them, I was going to add tests. There is an existing TestTriangle.cxx -
should I put the area test in there, or create a separate
TestTriangleComputeArea.cxx ?

There is no TestPolygon.cxx, so I was going to create one.

I was also going to add ComputeArea for vtkQuad, but I'm a bit confused. Why
does vtkQuad derive from vtkCell instead of vtkPolygon. It seems like both
vtkQuad and vtkTriangle are special cases of vtkPolygon. Is there a benefit
to the current structure?

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20091222/93b3cc0c/attachment.html>