Disable rendering of interior faces that are between cells of different order

Hello everyone.

I have an unstructured grid composed of two elements. One linear hexahedron ( 8 nodes ), and one tri quadratic hexahedron ( 8 nodes ). These two elements are side by side, and I have enforced the connectivity such that the 4 points at the interface corners are shared by the two elements (see picture plus vtu file attached ). Now, if I activate the transparency, we can see that the internal face is rendered. This is somehow expected, because the two faces do not possess the same number of nodes.

I am just showing here two elements, but in my real application, I have several thousand of them, and rendering is really slow due to these interior faces.

So how can I disable the rendering of these faces?

  • Can we specify somewhere to render the internal faces only based on the topology ( the cell corners )?

  • Can I specify a list of cell faces that I do not want to be rendered ?

If I look at this link, https://vtk.org/doc/nightly/html/classvtkGeometryFilter.html#details,
it is mentioned that the vtkGeometryFilter that is used for rendering can accept an optional vtkPolyData that represents a list of faces that are to be excluded from the output. If this is the direction to follow, how do I pass this list to ParaView ?

Any help would be appreciated. Thanks in advance.

Linear and tri quadratic connected hexahedron.vtu (1.9 KB)

@florian360 The surface filter correctly distinguishes between linear and higher-order faces as in the general case neighboring faces of different orders may not be entirely coincident. Adding tests that higher-order faces are flat would be expensive. However, I do see the need for some support where you can provide a guarantee of conformality.

While there is not a filter in VTK that does this, though you could certainly write one heavily based on vtkDataSetSurfaceFilter (or modify vtkGeometryFilter to handle higher-order cells as comments in the class mention – note that currently the geometry filter simply calls vtkDataSetSurfaceFilter when it detects higher-order cells).

I believe this is the section:


of the dataset-surface filter that is causing problems. If you want to contribute a change back to VTK, I would suggest templating vtkDataSetSurfaceFilter::UnstructuredGridExecuteInternal() on a boolean that triangulates higher-order surface boundaries (as is done currently) or ignores higher-order points.

In the future, I hope to have funding to add more support to vtkCellGrid to handle the situation you are describing. The new vtkDataObject subclass supports non-isoparametric elements (so you do not need a higher-order cell geometry to represent a higher-order field/attribute). There is not much provided with that class but several groups are currently funding development.

Hi David,

Thank you for the quick response.

I was playing today with vtkDataSetSurfaceFilter and here is what I have tried.

To remove the face between two nonlinear cells, my first idea was to remove subdivided triangles by using InsertTriHash.

  • But before doing that, the first step is to reconsider what is the subdivision level 0 for a high order cell. Currently, for instance, for a quadratic face, the subdivision level 0 corresponds to 4 quads subdivided into 2 triangles. My new definition is that it is a single quad subdivided into 2 triangles. I was able to do this step.

  • The second step is that when we are doing the nonlinear subdivision (triangulation) for the faces, instead of adding the newly created triangles directly into the output ( https://gitlab.kitware.com/vtk/vtk/-/blob/master/Filters/Geometry/vtkDataSetSurfaceFilter.cxx#L2110-2115 ), I am adding them via insertTriHash.

However, insertTriHash is working with input points, whereas the new points created via triangulation are output points, and they are not compatible ids. So I was able to do this step only for subdivision level 0, and I don’t see how to move further in that direction.

So for me, this is not the right solution.

What I was thinking instead, is a different approach.

Currently we do things in that order.

Iterated over the cells
   If the cell is linear, add its input ids to the hash table
   If the cell is nonlinear, triangulate the cell given the subdivision level, and add the point output ids directly to the output.
Process the hash table (remove internal faces)
Convert the remain faces to output ids and write these output points to the output

What if we change that as the following:

Iterated over the cells
    If the cell is linear, add its input ids to the hash table
    If the cell is nonlinear, add its corners to the hash table
Process the hash table (remove internal faces)
Convert the remaining faces to output ids. If the face is linear, do the same as before. If the cell is nonlinear, do the triangulation and then add it to the output.

The advantage of this second method is that we don’t add any subdivided triangle to the hash, so there won’t be any loss in performance. The disadvantage is that if two nonlinear cells are matching by their corners, it is not guaranteed that the internal nodes will match as well. It is by the way the behaviour we are looking for, but since it can be viewed as a regression with what is done before, I would keep this as optional.

Let me know what you think about this



@florian360 Your proposed solution (just hash the “linear corners” of nonlinear cells) sounds like a good one. As you suggest, I would make it optional since it would ignore pendant mid-edge/mid-face nodes.

@dcthomp I tried what I have proposed. It is working, but I don’t think it is the right choice to remove these cells with the vtkDataSetSurfaceFilter.
What I have noticed, is that when the two cells have the same degree, they are removed before the vtkDataSetSurfaceFilter by the filter vtkUnstructuredGridGeometryFilter.

And it turns out that to get it work, I simply need to comment the line that check that the two adjacent cells have the same number of points.

This approach is more correct, and much more simple.

I am not sure we care, but clipping is not working