<div dir="ltr"><div>Hi,<br><br></div>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:<br><ol><li>The unstructured (and probably polydata) version doesn't compute a gradient.</li><li>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.</li><li>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).<br></li><li>There seems to be inconsistent attributing (e.g. Normals and Vectors) for the output arrays.</li></ol><p>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:</p><ul><li>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.</li><li>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.</li></ul><p>The reason I bring this up though is that making this consistent will break backward compatibility for the behavior.</p><p>Thoughts?</p><p>Thanks,</p><p>Andy<br></p></div>