VTK Wedge Cell Types: Fix Point Ordering, Triangulation and Volume Correctness

spyridon97 · March 9, 2026, 8:09pm

It was brought to our attention by @user27182 in https://gitlab.kitware.com/vtk/vtk/-/issues/19639 that the point ordering implied by the parametric coordinates of vtkWedge, and utilized by its shape functions for interpolation/derivation, did not match what the vtk-book was showing

VTK-Book:

Parametric Coordinates

Because of this issue, many things were wrong:

Face winding of wedges was inwards not outwards
Tetrahedralization of wedges was producing tets with negative volume
several readers/and sources in VTK were generating wedges with the point ordering

Additionally, even though the VTK-book was showing the correct point ordering for vtkQuadraticWedges, vtkBiQuadraticWedges and vtkQuadraticLinearWedges which was matching their parametric coordinates, again several things were wrong because they were assuming the point ordering of vtkWedge shown in the VTK-book instead of the actual one:

Face winding of quadratic wedges was inwards not outwards
Tetrahedralization of quadratic wedges was producing tets with negative volume
Contouring/Clipping was using linear wedges with negative volumes
several readers/and sources in VTK were generating quadratic wedges with the point ordering

All that is being addressed in this MR https://gitlab.kitware.com/vtk/vtk/-/merge_requests/12988.

If backwards compatibility for vtkUnstructuredGridReader or vtkXMLUnstructuredGridReader is need for vtkWedges, please let us know.

mwestphal · March 11, 2026, 4:47pm

If backwards compatibility for vtkUnstructuredGridReader or vtkXMLUnstructuredGridReader is need for vtkWedges, please let us know.

Can you clarify what may break when you merge ?

spyridon97 · March 11, 2026, 4:51pm

If someone was passing wedges based on what the vtk book was saying, instead of what the parametric coordinates/shape functions say, they are gonna get the same interpolation because the shape functions did not change, but they would get with the old implementation positive volume, but now they will get negative volume because they use the wrong point ordering. Same goes for face winding and tetrahedralization.

Hopefully people were ignoring the vtkbook since all other places use the correct point ordering… but… people could be faithful to it. At least we were in several places.

mwestphal · March 11, 2026, 5:08pm

Noted, please highlight this in the release notes.

user27182 · March 11, 2026, 5:51pm

I think one such example is with the python meshio package, where the point ordering is currently swapped to match the old and incorrect ordering:

github.com/nschloe/meshio

src/meshio/_vtk_common.py

b2ee99842


      
          def vtk_to_meshio_order(vtk_type, dtype=int):
              # meshio uses the same node ordering as VTK for most cell types. However, for the
              # linear wedge, the ordering of the gmsh Prism [1] is adopted since this is found in
              # most codes (Abaqus, Ansys, Nastran,...). In the vtkWedge [2], the normal of the
              # (0,1,2) triangle points outwards, while in gmsh this normal points inwards.
              # [1] http://gmsh.info/doc/texinfo/gmsh.html#Node-ordering
              # [2] https://vtk.org/doc/nightly/html/classvtkWedge.html
              if vtk_type == 13:
                  return np.array([0, 2, 1, 3, 5, 4], dtype=dtype)
              return None

So these kinds of readers should probably be updated for VTK 9.7, right?

Notably, the code snippet above specifically makes reference to the nightly vtk docs VTK: vtkWedge Class Reference

But for this kind of change, it would be extremely useful if users could specifically reference the old VTK 9.6 docs, which should show the incorrect point ordering, and compare this to the new (unreleased) VTK 9.7 docs which shows the correct ordering. Which is to say that hopefully issue https://gitlab.kitware.com/vtk/vtk/-/issues/19953 can be resolved before the next release, and that separate docs for a VTK 9.6 release (maybe the 9.6.1 patch release?) can be published prior to the 9.7 release.

Unfortunately though, resolving https://gitlab.kitware.com/vtk/vtk/-/issues/19953 would only capture this change in the doxygen docs, but the actual VTK book changes from
https://gitlab.kitware.com/vtk/vtk-examples/-/merge_requests/443 would not be reflected, i.e. I don’t think there is a separate version of the book published for every VTK release.

Not sure how changes to the book are tracked and published (maybe only the latest version is available?), but IMO if the VTK book docs are published with Sphinx, it might be helpful to add a .. versionchanged:: 9.7.0 directive so that users are aware of this when referencing the book.

From my experience reviewing wedge-related issues such as https://gitlab.kitware.com/vtk/vtk/-/issues/19639, it seems the VTK book is often referenced as an authoritative source for the point order, and so knowing that the point order changed when referencing the book would help provide a lot of clarity. (e.g. I can image a situation where an old thread makes reference to the old version of the book, but when users click the same link today, it now shows the new version of the book with the new order, which may lead to confusion when trying to make sense of the old thread).

Just my two cents anyway.