[vtkusers] vtkContourFilter cleanup

[Bill Lorensen]

This is probably one of the most used filters in VTK and has been
there a very long time. I prefer we maintain backward compatibility to
avoid surprises in customers' code.

Bill


On Tue, Feb 7, 2017 at 3:22 PM, Andy Bauer <andy.bauer at kitware.com> wrote:
> Hi,
>
> I'm in the process of cleaning up vtkContourFilter to make it more
> consistent. The basic issue is that vtkContourFilter offloads the actual
> computation to other filters (e.g. vtkGridSynchronizedTemplates3D,
> vtkRectilinearSynchronizedTemplates, etc.) in order to maintain high
> efficiency for each dataset type. With each implementation though it seems
> like small idiosyncrasies/inconsistencies have crept in. A probably not
> inclusive list includes:
>
> The unstructured (and probably polydata) version doesn't compute a gradient.
> If ComputeGradient is enabled the structured grid version replaces an
> existing input "vector" attribute point data array with the Gradient array,
> but other implementations don't.
> The order of the output arrays can be different based on grid type for the
> ComputeScalars option (i.e. the unstructured grid version keeps the same
> order of input arrays and adds the requested Normal and Gradients array
> after them while the image data version moves the Scalars array).
> There seems to be inconsistent attributing (e.g. Normals and Vectors) for
> the output arrays.
>
> Not all of these should be considered bugs (certainly not #3) but can cause
> mistakes later on because of the differences. So the changes that I would
> like to make include:
>
> Make sure the output array order is the same as the input array order and
> then append the Gradients and/or Normals arrays, in that order, if they were
> requested and available.
> If ComputeScalars or ComputeNormals is enabled to label those output arrays
> as the scalars and normals attributes, respectively. For the Gradients
> output I would not specify them with the vectors attribute. These are my
> opinions though and should certainly be discussed and agreed upon before
> making changes.
>
> The reason I bring this up though is that making this consistent will break
> backward compatibility for the behavior.
>
> Thoughts?
>
> Thanks,
>
> Andy
>
>
> _______________________________________________
> 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
>



-- 
Unpaid intern in BillsBasement at noware dot com