[vtkusers] algorithm performance

Sun Aug 4 11:12:23 EDT 2013

Gerrick,

Here are two examples.
1) Uses vtkCutter and a CutFunction to cut a model with a plane
2) Computes scalars from the plane and uses vtkContourFilter to do the
cutting. This approach might speed up your application since it only
computes the scalar field once for a given plane.

1)
http://itk.org/Wiki/VTK/Examples/Cxx/VisualizationAlgorithms/CutWithCutFunction
2)
http://itk.org/Wiki/VTK/Examples/Cxx/VisualizationAlgorithms/CutWithScalars

Bill

On Sat, Aug 3, 2013 at 2:25 PM, Bill Lorensen <bill.lorensen at gmail.com>wrote:

> That functionality was just a convenience. Apparently it s gone. I'll have
> to change the documentation.
>
>
>
> On Sat, Aug 3, 2013 at 10:31 AM, Jeff Lee <jlee1549 at gmail.com> wrote:
>
>> The only real difference between vtkCutter and that and vtkContourFilter
>> is that Cutter computes the scalar field from the implicit function
>> internally.  Not clear what the benefit is to have vtkCutter cut with a
>> supplied scalar field when you already have vtkContourFilter...
>>
>>
>> On Sat, Aug 3, 2013 at 10:11 AM, Gerrick Bivins <
>> Gerrick.Bivins at halliburton.com> wrote:
>>
>>> Ok. When I looked at the source for vtkcutter I didn't see a code path
>>> that allowed execution without specifying an implicit function. Is this
>>> what you mean?
>>>
>>> Sent from my Android phone using TouchDown (www.nitrodesk.com)
>>>
>>> ________________________________
>>> From: Bill Lorensen
>>> Sent: Saturday, August 03, 2013 2:00:06 PM
>>> To: Jeff Lee
>>> Cc: Gerrick Bivins; vtkusers at vtk.org
>>> Subject: Re: [vtkusers] algorithm performance
>>>
>>> I just checked vtkCutter. I don't think it will use supplied scalars.
>>> Used to work. I think it is a bug I'll need to look into.
>>>
>>>
>>>
>>> On Fri, Aug 2, 2013 at 5:16 PM, Bill Lorensen <bill.lorensen at gmail.com
>>> <mailto:bill.lorensen at gmail.com>> wrote:
>>> Exactly. ANd I'm saying you can compute that scaalr data ONCE outside of
>>> vtkCutter and possibly save some time. If you specify a CutFunction
>>> vtkCutter will recompute the scalar data every time you change the plane.
>>> If you provide point data scalars (of the plane), you can just change the
>>> isovalue to "move the plane".
>>>
>>>
>>>
>>>
>>> On Fri, Aug 2, 2013 at 5:06 PM, Jeff Lee <jlee1549 at gmail.com<mailto:
>>> jlee1549 at gmail.com>> wrote:
>>> I mean point scalar data array reperesenting the evaluation of the
>>> implicit function f(xyz) at every node.
>>>
>>>
>>> On Fri, Aug 2, 2013 at 5:02 PM, Gerrick Bivins <
>>> Gerrick.Bivins at halliburton.com<mailto:Gerrick.Bivins at halliburton.com>>
>>> wrote:
>>> I think part of my confusion was “point data scalars”.
>>> I initially read that as Scalars of vtkPointData but now I think you are
>>> meaning scalar data arrays that represent grid node coordinates.
>>> Is that correct?
>>> Gerrick
>>>
>>> From: Bill Lorensen [mailto:bill.lorensen at gmail.com<mailto:
>>> bill.lorensen at gmail.com>]
>>> Sent: Friday, August 02, 2013 3:34 PM
>>> To: Jeff Lee
>>>
>>> Cc: Gerrick Bivins; vtkusers at vtk.org<mailto:vtkusers at vtk.org>
>>> Subject: Re: [vtkusers] algorithm performance
>>>
>>> You can also compute the scalar data once and use that for cutting. You
>>> would need to generate the point data scalars programmaticly. I'm not sure
>>> there is a filter to do that.
>>>
>>> On Fri, Aug 2, 2013 at 4:19 PM, Jeff Lee <jlee1549 at gmail.com<mailto:
>>> jlee1549 at gmail.com>> wrote:
>>> The cutter just evaluates the implicit function at every point in the
>>> input dataset, then contours that scalar field at the requested value
>>> (usually 0).  It is equivalent to generating your own point scalar field of
>>> the implicit function on the dataset and running it through a
>>> contourfilter, and ScalarTreeOn should produce the speedup of subsequent
>>> contour values assuming you are just changing the contour value.  For
>>> multiple cuts of the same function you would set multiple values in the
>>> filter, that would get you the multiple parallel slice case.  The scalar
>>> tree won't help if you are changing the implicit function (i.e. the scalar
>>> field), but extracting different contour values for a single field should
>>> show improvement.  The contour values would be the offset from the zero
>>> contour, so values of 0.0, .1, .2, etc.. would generate multiple planes
>>> including the original implicit definition.
>>>
>>> On Fri, Aug 2, 2013 at 4:03 PM, Bill Lorensen <bill.lorensen at gmail.com
>>> <mailto:bill.lorensen at gmail.com>> wrote:
>>> I'll try to find an example that does not use a cut function, but uses
>>> the scalar point data. I know I did this years ago when we first wrote
>>> vtkCutter and vtkClipPolyData.
>>> You should be able to compute point data scalars for your dataset and
>>> use those scalars for cutting rtaher than a cut function.
>>> At least that is how it used to work.
>>>
>>> On Fri, Aug 2, 2013 at 3:44 PM, Gerrick Bivins <
>>> Gerrick.Bivins at halliburton.com<mailto:Gerrick.Bivins at halliburton.com>>
>>> wrote:
>>> Bill,Jeff,
>>> Currently, the slices will be orthogonal slices, parallel to the
>>> Cartesian axes (x,y,z).
>>> Next request will be multiple arbitrarily oriented slices but probably
>>> parallel to each other (same normal).
>>>
>>> Still absorbing this. It’s not quite clear how I’d generate a planar
>>> slice using vtkCutter from the scalar data.
>>> Can either of you point me to some example code?
>>> Gerrick
>>>
>>> From: Jeff Lee [mailto:jlee1549 at gmail.com<mailto:jlee1549 at gmail.com>]
>>> Sent: Friday, August 02, 2013 12:01 PM
>>> To: Bill Lorensen
>>> Cc: Gerrick Bivins; vtkusers at vtk.org<mailto:vtkusers at vtk.org>
>>>
>>> Subject: Re: [vtkusers] algorithm performance
>>>
>>> IIRC the unstructured grid algorithm doesn't use a cell locator to find
>>> candidate cells, it runs over all cells and checks the scalar range of the
>>> cell and then contours it if the range is satisfied.  Its faster than
>>> blindly contouring every cell but not as good as it could be.  A better
>>> approach would be to use a scalar tree (where the function value is the
>>> scalar) and use that to locate candidate cells.  It will be expensive to
>>> build the tree the first time, but subsequent contours of the same function
>>> will typically be much faster, as the candidate cells have been sorted in
>>> bins by range in the scalar tree.  You would have to modify the algorithm a
>>> bit to do this, but i've had success with that approach in the past...
>>>
>>> On Fri, Aug 2, 2013 at 11:46 AM, Bill Lorensen <bill.lorensen at gmail.com
>>> <mailto:bill.lorensen at gmail.com>> wrote:
>>> Are the slice planes parallel to each other, or are they arbitrarily
>>> oriented?
>>> If they are parallel, then you could compute point data scalars once and
>>> leave out the implicit function. Then Cutter will use the scalar data for
>>> cutting. This would avoid recomputing the scalar field for each slice.
>>>
>>>
>>> On Fri, Aug 2, 2013 at 11:31 AM, Gerrick Bivins <
>>> Gerrick.Bivins at halliburton.com<mailto:Gerrick.Bivins at halliburton.com>>
>>> wrote:
>>> Hi Bill,
>>> We are building release. Our grids are large at least 10’s – 100’s of
>>> thousands of cells.
>>> I’m seeing the behavior in a Paraview  install as well,
>>> with auto-apply on. Trying to move the slice plane through
>>> the dataset becomes less and less interactive as the dataset cell count
>>> increases.
>>> So I was hoping there were some ways to speed this up.
>>> Any other suggestions?
>>> Gerrick
>>>
>>> From: Bill Lorensen [mailto:bill.lorensen at gmail.com<mailto:
>>> bill.lorensen at gmail.com>]
>>> Sent: Friday, August 02, 2013 10:18 AM
>>> To: Gerrick Bivins
>>> Cc: vtkusers at vtk.org<mailto:vtkusers at vtk.org>
>>> Subject: Re: [vtkusers] algorithm performance
>>>
>>> Also be sure you build VTK and your app Release and not Debug.
>>>
>>>
>>> On Fri, Aug 2, 2013 at 11:08 AM, Gerrick Bivins <
>>> Gerrick.Bivins at halliburton.com<mailto:Gerrick.Bivins at halliburton.com>>
>>> wrote:
>>> Hi All,
>>> I’m looking for suggestions on how to speed up an algorithm on large
>>> unstructured grids, like vtkCutter.
>>> I thought I could build an octree (or similar structure) from the input
>>>  and execute the vtkCutter on the octree
>>> but it’s not obvious to me how to do it. Is something like this possible?
>>> How can I improve the speed of the algorithm? Performance seems to go
>>> down as cell count grows.
>>> Gerrick
>>>
>>> ________________________________
>>> This e-mail, including any attached files, may contain confidential and
>>> privileged information for the sole use of the intended recipient. Any
>>> review, use, distribution, or disclosure by others is strictly prohibited.
>>> If you are not the intended recipient (or authorized to receive information
>>> for the intended recipient), please contact the sender by reply e-mail and
>>> delete all copies of this message.
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com<http://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
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>
>>>
>>>
>>> --
>>> Unpaid intern in BillsBasement at noware dot com
>>>
>>>
>>>
>>> --
>>> Unpaid intern in BillsBasement at noware dot com
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com<http://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
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>
>>>
>>>
>>>
>>> --
>>> Unpaid intern in BillsBasement at noware dot com
>>>
>>>
>>>
>>>
>>> --
>>> Unpaid intern in BillsBasement at noware dot com
>>>
>>>
>>>
>>>
>>> --
>>> Unpaid intern in BillsBasement at noware dot com
>>>
>>>
>>>
>>> --
>>> Unpaid intern in BillsBasement at noware dot com
>>>
>>
>>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
>

-- 
Unpaid intern in BillsBasement at noware dot com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20130804/56ab72d4/attachment.htm>