Normal problem with vtk Boolean Operation PolyData Filter

Development
1

Apologies up front for this being rather long and possibly somewhat difficult to understand.

I hope that someone can suggest a course of action for this.

I’ve been trying to model and render various geometric bodies with boolean operations using vtkBooleanOperationPolyDataFilter and have run into a problem with the normals not being right in the final object.

I have 2 objects, a sphere that is built using vtkSphereSource and a cube using a modification that I made to vtkCubeSource. When rendered individually, everything appears fine, but when I use vtkBooleanOperationPolyDataFilter and take a bite out of the cube with the sphere, a good number of the normals aren’t right as can be seen in the picture.

bad_normals_on_cube
bad_normals_on_cube927×948 50.6 KB

The black indicates where the normals aren’t correct. My opinion is that the system didn’t copy them over correctly from the original bodies. When one looks at just the mesh, it appears correct.

Because vtkBooleanOperationPolyDataFilter is based upon the work at
https://www.vtkjournal.org/browse/publication/797
and this article discusses the steps that are needed under the hood, I decided to look at the individual steps to see what was causing the problem. The following code is what generated the picture above.

Cube2.cxx (2.6 KB)

In the several steps (filters) that the journal paper discusses in building the vtkBooleanOperationPolyDataFilter, it appears that with the vtkIntersectionPolyDataFilter the normals aren’t being handled correctly. From the code listing one can see that I needed the step with vtkDistancePolyDataFilter in order to setup the mapper, but vtkIntersectionPolyDataFilter appears to be responsible for the heavy lifting for the triangle intersections, etc. and processing of the polydata.

It appears to me that vtkIntersectionPolyDataFilter isn’t re-calculating the normals, but I suspect that because there is so much inheritance going on that something up the chain is responsible for handling the normals in the new body. I not sure how to debug this to find the culprit.

I’m hoping that someone with more experience with these routines and the inheritance can shed some light on this. Its possible that one of the inherited routines is messing up (and I don’t know which) or I need to somehow further process what I have. But, I had expected vtkBooleanOperationPolyDataFilter to handle this correctly without an further manipulation needed on my part.

Am open to suggestions as to what to try next.

BK

2

Maybe you need to apply vtkPolyDataNormals to the output from your sssSuperCubeSource. Check some of the online examples in the documentation for vtkPolyDataNormals for its usage.

3

Hi Andrew,

Your suggestion worked, but not on the direct output from the cube. In the source file (Cube2.cxx), this is what I added / changed:

vtkNew<vtkPolyDataNormals> normals1;
normals1->SetInputConnection(distance->GetOutputPort( 0 ));

mapper->SetInputConnection(normals1->GetOutputPort( ));

The normals were okay before the vtkIntersectionPolyDataFilter worked its magic. Sending the cube’s output channel from vtkIntersectionPolyDataFilter to the vtkPolyDataNormals filter was all I needed to do. (Or, at least it appears so.)

Thanks a bunch!

BK

4

Glad to see it worked for you.

5

I want to clarify one point on this for anyone who runs across this item in the future.

The code I posted went to all of the trouble to dissect vtkBooleanOperationPolyDataFilter (based on the paper cited) so that I could see (more or less) where the problem was occurring. As I found out, one can take the output from vtkBooleanOperationPolyDataFilter and run it through the vtkPolyDataNormals filter and solve the problem. I’m glad to see that worked.