[Paraview] [EXTERNAL] default behavior change for contour filter

[Andy Bauer]

Hi Alan,

I can't tell what type of blocks are in the multiblock data set of can and
disk_out_ref but I'm guessing some of them are either unstructured or
polydata and if they are, those options get disabled since they're only
available for topologically structured input grids.

As for the contours of wavelet, I didn't check that out before but that's a
good point. I'm playing around with adding normals for unstructured grid
inputs since the current set up doesn't allow that but maybe it should.

Andy

On Wed, Aug 15, 2012 at 10:01 PM, Scott, W Alan <wascott at sandia.gov> wrote:

> Andy,
> I tried this with can and disk_out_ref, and didn't have the option to
> change these settings (not sure why).  Then, I tried wavelet, and without
> normal, lighting is messed up (it now looks like flat shading).  I am
> thinking we don't want lighting messed up for contours.
>
> Alan
>
> From: paraview-bounces at paraview.org [mailto:paraview-bounces at paraview.org]
> On Behalf Of Andy Bauer
> Sent: Wednesday, August 15, 2012 10:02 AM
> To: paraview at paraview.org; paraview-developers at paraview.org
> Subject: [EXTERNAL] [Paraview] default behavior change for contour filter
>
> I'd like to change ParaView's default behavior of the contour filter.
> Currently the default is to compute normals and not compute gradients or
> scalars. These defaults are only used for structured data sets (i.e.
> vtkStructuredGrid, vtkImageData, and vtkRectilinearGrid) and are not
> options when isosurfacing for vtkPolyData or vtkUnstructuredGrids. When the
> input data set is a multiblock data set that contains both structured and
> unstructured data sets the output for the current code results in a
> multiblock data set with partial arrays (Normals for the structured data
> sets and the contoured variable for the unstructured data sets). The change
> I'd like to make is to make Compute Normals off by default and Compute
> Scalars on by default so that the output is a bit more consistent.
>
> Does anyone think that this is a significant change and shouldn't be done?
>
> Thanks,
> Andy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20120816/260bd1ec/attachment.htm>