Remove vtkContourFilter's `ComputeNormals = -1` hack
In my work adding VTK_USE_FUTURE_BOOL
, I noticed vtkContourFliter's ComputeNormals
ivar looks like it should be boolean, but is in fact tri-state: 0, 1 and -1.
The ctor does:
this->ComputeNormals = -1;
later there is this:
// -1 == uninitialized. This setting used to be ignored, and we preserve the
// old behavior for backward compatibility. Normals will be computed here
// if and only if the user has explicitly set the option.
if (this->ComputeNormals != 0 && this->ComputeNormals != -1)
Computing normals is expensive, so ideally the ctor should set ComputeNormals = 0
. If you do so it today's master, one test fails: IOGeometryPython-testHexaPenta
.
There are clearly code paths that this test exercises that expect normals to be computed by default. Those should I guess be changed to explicitly request that normals be computed.