# vtkHDF: Add support for polyhedron cells
**URL:** https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089
**Category:** Development
**Tags:** file-formats
**Created:** [January 17, 2024, 4:32pm UTC](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089 "2024-01-17T16:32:10Z")
**Posts on this page:** 20
**Page:** 2
### Author:  [@lgivord](https://discourse.vtk.org/u/lgivord)
#### Post date: [March 5, 2025, 7:24am UTC](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089/21 "2025-03-05T07:24:19Z")
we converge with @MicK7 @Dieke and some others folks about what the spec could be.
AFAIK nothing more that what we talk in this discourse post has been made so the next step will be to write it in the spec directly, then we can see to support it in the vtkHDFReader/Writer. Unfortunately, I personally don’t have funding for this.
---
### Author:  [@Dieke](https://discourse.vtk.org/u/Dieke)
#### Post date: [May 14, 2025, 1:18pm UTC](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089/22 "2025-05-14T13:18:23Z")
[longBox.hdf](https://discourse.vtk.org/uploads/short-url/3naazmi9GcxJT8t3QrNbG66OmD0.hdf) (1.3 MB)
To contribute to the discussion, I have uploaded a VTKHDF file containing MultiBlockData. This file contains 13 Blocks with face data.
Each block contains the connectivity, offsets and types. Further cell1 and (where applicable) cell2 DataSets are provided denoting the cells a face contributes to (cell2 is in reverse order).
This file can be displayed in ParaView.
With the programmable source below, the corresponding polyhedrons can be created and displayed. There might be still room for improvement.
Maybe it is possible to implement something similar in the VTKHDFreader.
Greetings Dieke
```auto
import vtk
reader = vtk.vtkHDFReader()
reader.SetFileName('longBox.hdf')
reader.Update() # Needed because of GetScalarRange
blocks =reader.GetOutput()
cells = {}
for iBlock in range(blocks.GetNumberOfBlocks()):
block = blocks.GetBlock(iBlock).GetBlock(0)
# only blocks with cell1/2 DataSet are considered
cell1 = block.GetCellData().GetArray('cell1')
cell2 = block.GetCellData().GetArray('cell2')
for i in range(cell1.GetNumberOfValues()):
icell = cell1.GetValue(i)
ids = block.GetCell(i).GetPointIds()
c = []
for p in range(ids.GetNumberOfIds()):
c.append(block.GetCell(i).GetPointId(p))
if not icell in cells: cells[icell] = []
cells[icell].append(c)
c = []
if cell2:
icell = cell2.GetValue(i)
ids = block.GetCell(i).GetPointIds()
c = []
for p in range(ids.GetNumberOfIds(),0,-1):
c.append(block.GetCell(i).GetPointId(p-1))
if not icell in cells: cells[icell] = []
cells[icell].append(c)
# create the unstructured grid with polyhedra
output = vtk.vtkUnstructuredGrid()
output.Initialize()
output.Allocate(len(cells))
points = blocks.GetBlock(0).GetBlock(0).GetPoints()
output.SetPoints(points)
for key in sorted(cells.keys()):
faceIds = vtk.vtkIdList()
cell = cells[key]
print(key,len(cell))
poly = vtk.vtkPolyhedron()
poly.Initialize()
faceIds.InsertNextId(len(cell))
for c in cell:
faceIds.InsertNextId(len(c))
for p in c:
faceIds.InsertNextId(p)
output.InsertNextCell(vtk.VTK_POLYHEDRON, faceIds)
```
---
### Author:  [@dcthomp](https://discourse.vtk.org/u/dcthomp)
#### Post date: [May 14, 2025, 1:34pm UTC](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089/23 "2025-05-14T13:34:48Z")
Although VTK doesn’t currently support non-simple polygons/polyhedra (i.e. with holes/voids and concavities), is there any thought to the file format supporting them?
---
### Author:  [@lgivord](https://discourse.vtk.org/u/lgivord)
#### Post date: [May 16, 2025, 12:32pm UTC](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089/24 "2025-05-16T12:32:02Z")
currently we have an issue with what the file format could be in VTK:
[https://gitlab.kitware.com/vtk/vtk/-/issues/19228](https://gitlab.kitware.com/vtk/vtk/-/issues/19228)
Some improvement could be done later with compact storage version, see [https://gitlab.kitware.com/vtk/vtk/-/issues/19228](https://gitlab.kitware.com/vtk/vtk/-/issues/19228)
---
### Author:  [@Dieke](https://discourse.vtk.org/u/Dieke)
#### Post date: [May 20, 2025, 11:23am UTC](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089/25 "2025-05-20T11:23:12Z")
Based on my previous post I have an proposal for a specification to implement polyhedral.
The main addition is the introduction of a CellAssembly group in to the vtkUnstructuredGrid connectivity. This group contains links to vtkUnstructuredGrids with polygons.
The polygon vtkUnstructuredGrids should have a CellData cell1 and may have a CellData cell2.
CellData cell1 denotes the owner cell of the faces. The owner cells are always in the same partition as the respective faces. A CellData cell2 denotes the neighbour cells. The faces must be used in reverse vertex order for the neighbour cells. The partition of a neighbour cell may differ from the face but can be easily determined by the cell number.
My recommendation would be to separate the faces having owner and neighbour (internal faces) from those having only an owner (in most cases boundary face) into different grids. It is also possible to mark missing neighbour in cell2 array by negative numbers.
For post processing purposes it might be advisable to use one grid per boundary condition.
The polyhedron grid and the polygon grids should refer to the same Points and PointData.
The polyhedron grid can by this definition hold only polyhedron cells. But this seem to me a small limitation. In return we get a space efficient file format with little overhead.
Below is a sketch of the proposed dependencies.
---
### Author:  [@Dieke](https://discourse.vtk.org/u/Dieke)
#### Post date: [May 20, 2025, 11:33am UTC](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089/26 "2025-05-20T11:33:09Z")
I have prepared an example file. The 2D Groups can be displayed in paraview.
[boxHangingNodes.hdf](https://discourse.vtk.org/uploads/short-url/A5DDxx3xx5ng7SlC47w94L6JAyd.hdf) (396.4 KB)
---
### Author:  [@lgivord](https://discourse.vtk.org/u/lgivord)
#### Post date: [May 20, 2025, 11:38am UTC](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089/27 "2025-05-20T11:38:11Z")
It will definitively be useful when someone will try to support it in the VTKHDF File Format and in the reader/writer.
Is it possible to add the output of the h5dump in a .txt ?
---
### Author:  [@Dieke](https://discourse.vtk.org/u/Dieke)
#### Post date: [May 20, 2025, 11:40am UTC](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089/28 "2025-05-20T11:40:34Z")
[h5dfdump.txt](https://discourse.vtk.org/uploads/short-url/fVO7GdM2LxFK7nP5yeCeT8rprVy.txt) (19.8 KB)
There you go!
---
### Author:  [@dcthomp](https://discourse.vtk.org/u/dcthomp)
#### Post date: [May 20, 2025, 2:41pm UTC](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089/29 "2025-05-20T14:41:46Z")
> [@lgivord](#):
>
> Some improvement could be done later with compact storage version, see [https://gitlab.kitware.com/vtk/vtk/-/issues/19228](https://gitlab.kitware.com/vtk/vtk/-/issues/19228)
The specification you’ve linked does not have any support for non-simple polygons/polyhedra. That would require additional arrays, so that
- a polyhedron is a collection of one or more oriented shells (one outer shell with its orientation chosen to produce outward-pointing normals and zero or more inner shells with their orientations chosen to produce inward-pointing normals).
- each shell is a collection of facets, oriented so all the facets in the shell have the same normal direction (all inward or all outward).
- each facet is a collection of one or more oriented edge-loops (one outer loop with its orientation chosen to produce a counter-clockwise (CCW) set of edges; and zero or more inner loops with their orientations chosen to produce clockwise (CW) edges).
- each loop is a collection of one or more oriented wires chosen so that they form a closed loop of head-to-tail segments.
- each wire is a collection of two or more vertices.
The data structure in the link above presumes that there is only one shell (the outer shell) and each polygonal facet has a single loop (the outer loop). Adding the concepts of multiple shells and loops would be required to handle non-simple polyhedra. You might plan for this in advance by renaming `PolygonConnectivity` to `SimplePolygonConnectivity` and `PolyhedronToFaces` to `SimplePolyhedronFaces`, respectively. That way, support can be added later to include shell and loop connectivity in additional (non-simple) arrays.
Also, I am unsure why both `Connectivity` and `PolyhedronToFaces` exist. It seems that the `PolyhedronToFaces`/`PolyhedronOffsets` arrays are enough to specify a collection of simple polyhedra (since `PolygonConnectivity`/`PolygonOffsets` provide vertex connectivity for each of the faces making up a single polyhedron).
---
### Author:  [@olesenm](https://discourse.vtk.org/u/olesenm)
#### Post date: [October 28, 2025, 4:36pm UTC](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089/30 "2025-10-28T16:36:54Z")
I’m more than a bit late to this discussion, but only started trying to target vtkhdf very recently and stumbled over the missing polyhedral support.
As an intermediate step, would it not be possible to simply incorporate the equivalent of the `faces` and `faceoffsets`entries currently already used in the XML format? This may not be as elegant as the other specification being proposed, but could have some advantages:
- presumably relatively straightforward and rapid to implement (as reader and writer)
- easy to target for people (like me) trying to port existing non-VTK code
It _does_ continue to involve redundant information (ie, the connectivity values can actually be determined on-the-fly from the faces) and is missing out on any improvements, but could get something working quickly. I don’t know enough about the VTK internals, but perhaps the `Connectivity` array could also just have zero entries for the polyhedral cells, and they would be built on the fly when reading?
The “proper” extended support could still be added in the future as part of the spec.
I’ve attached a tiny polyhedral mesh for possible discussion purposes.
Cheers
/mark
[singleCell.vtu](https://discourse.vtk.org/uploads/short-url/81Ec3ZGSQYSoBQeHDeNgM9Hisgt.vtu) (2.2 KB)
---
### Author:  [@ahernsean](https://discourse.vtk.org/u/ahernsean)
#### Post date: [October 28, 2025, 5:49pm UTC](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089/31 "2025-10-28T17:49:07Z")
I’ll second Mark’s recommendation here. Since much of VTKHDF is already a transliteration of the structured data in the XML formats, wouldn’t it make sense to take the same approach for arbitrary polyhedra? I understand the motivation for alternative, potentially more efficient representations, but we could treat this as a first step and develop a roadmap for future enhancements.
---
### Author:  [@Louis\_Gombert](https://discourse.vtk.org/u/Louis_Gombert)
#### Post date: [November 3, 2025, 2:48pm UTC](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089/32 "2025-11-03T14:48:52Z")
@olesenm @ahernsean To make sure we’re on the right track, I’ve started implementing polyhedron support in the vtkHDFReader, based on [the specification suggested by](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089) @MicK7, which is very close to the XML format.
While there is definitely duplicated connectivity data, this is a good compromise because this specification is very close to the VTK Data model, we don’t have to build data arrays on the fly. Reading should be very fast this way, even if we waste some space.
Here is a sample of Mark’s polyhedral dataset using VTKHDF:
[polyhedron.vtkhdf](https://discourse.vtk.org/uploads/short-url/eBL9P2zBUNnObGZTvI8PZoFf2Nc.vtkhdf) (140.0 KB)
I have a very early reader prototype that supports basic polyhedron reading, as well as temporal datasets. [https://gitlab.kitware.com/vtk/vtk/-/merge\_requests/12578/](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/12578/)
I have a sample generation script here too: [https://gitlab.kitware.com/keu-public/vtkhdf/vtkhdf-scripts/-/merge\_requests/12](https://gitlab.kitware.com/keu-public/vtkhdf/vtkhdf-scripts/-/merge_requests/12)
---
### Author:  [@olesenm](https://discourse.vtk.org/u/olesenm)
#### Post date: [November 7, 2025, 7:45am UTC](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089/33 "2025-11-07T07:45:36Z")
Very late reply here.
I very much like the idea of negative indices to indicate a flipped face orientation. In fact, we use it frequently enough in our own code.
The only adjustment you need is to define it as `-idx-1`, (or as `-(idx+1) `if overflow isn’t an issue). This means that a flipped face 0 would be -1, a flipped face 1 is -2, etc.
Another convention we use is that a flipped face always retains its point 0 and only the rest of the list is reversed. This makes life much easier.
---
### Author:  [@Louis\_Gombert](https://discourse.vtk.org/u/Louis_Gombert)
#### Post date: [November 7, 2025, 4:43pm UTC](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089/34 "2025-11-07T16:43:28Z")
It’s a neat idea, but it does not play well with the current VTK data model. We would like as much as possible to keep the VTKHDF format close to how the VTK data model (and the XML format) is built, and avoid doing too much processing in the reader to keep it fast. In this case, the reader would have to parse and edit face connectivity arrays. It’s an improvement we can keep in mind if it’s a popular demand or a bottleneck. It would not break the current format, as negative ids are not something we support currently.
---
### Author:  [@olesenm](https://discourse.vtk.org/u/olesenm)
#### Post date: [November 17, 2025, 5:22pm UTC](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089/35 "2025-11-17T17:22:56Z")
Hi @Louis_Gombert
I definitely can see where you are coming from, even although we already have a few places where the XML format diverges from the vtkCell internal representation (eg, “offsets” and “faceoffsets” both being end offsets for XML, but the internal equivalent has begin/end for the connectivity offsets and the begin location for the faces).
If we go with the idea that it’s better to sacrifice disk space in favour of speed and write out duplicate faces _and_ assuming that we do need to write them with positive outward normals: do we actually need the `PolyhedronToFaces`entry at all? If I walk across the faces of each polyhedral, it seem that I invariably just generate a simple one-to-one mapping.
I’m not sure if I’ve missed something, but each polyhedral face is now unique (because the orientations are different), the order in which the faces are presented to vtkCell assembly is arbitrary, so where would we generate a `PolyhedronToFaces` that is not simply an identity map?
Cheers,
/mark
---
### Author:  [@cory.quammen](https://discourse.vtk.org/u/cory.quammen)
#### Post date: [November 18, 2025, 3:52pm UTC](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089/36 "2025-11-18T15:52:23Z")
Great discussion! It seems we are converging on initially supporting a polyhedra organization that matches the VTK data model, which is a good idea in my opinion.
I’d like to voice support for keeping open the possibility of other polyhedra organizations in the future that may offer space savings and write efficiency from codes that internally use a face-to-cell oriented data structure. Could the VTKHDF spec include an attribute that specifies the polyhedron organization type? If we have that, then other organizations besides the VTK-centric organization can be added in the future.
---
### Author:  [@Louis\_Gombert](https://discourse.vtk.org/u/Louis_Gombert)
#### Post date: [December 9, 2025, 2:02pm UTC](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089/37 "2025-12-09T14:02:32Z")
All, initial support for polyhedrons in VTKHDF [has been merged in VTK](https://gitlab.kitware.com/vtk/vtk/-/commit/ac6cb2b3550b7de9c9cfcd731098d453e9fab1b7). It will be available in ParaView soon.
---
### Author:  [@cory.quammen](https://discourse.vtk.org/u/cory.quammen)
#### Post date: [December 18, 2025, 3:54pm UTC](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089/38 "2025-12-18T15:54:25Z")
> [@cory.quammen](#):
>
> Could the VTKHDF spec include an attribute that specifies the polyhedron organization type? If we have that, then other organizations besides the VTK-centric organization can be added in the future.
Did anything like this make it into [https://gitlab.kitware.com/vtk/vtk/-/merge\_requests/12578](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/12578) @Louis_Gombert ?
---
### Author:  [@mwestphal](https://discourse.vtk.org/u/mwestphal)
#### Post date: [December 19, 2025, 7:45am UTC](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089/39 "2025-12-19T07:45:27Z")
It did not, although we plan to open a larger discussion in regards to polyhedron organization in VTK data model.
---
### Author:  [@cory.quammen](https://discourse.vtk.org/u/cory.quammen)
#### Post date: [December 19, 2025, 9:10pm UTC](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089/40 "2025-12-19T21:10:34Z")
Intriguing!
[Previous page](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089.md?page=1)
[Next page](https://discourse.vtk.org/t/vtkhdf-add-support-for-polyhedron-cells/13089.md?page=3)