[vtk-developers] Adding ComputeArea() to vtkTriangle

John Platt jcplatt at dsl.pipex.com
Tue Dec 22 15:31:26 EST 2009 

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> 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
>>>> <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

Follow this link to subscribe/unsubscribe:
http://www.vtk.org/mailman/listinfo/vtk-developers

More information about the vtk-developers mailing list