Unstructured Spatial Field Extension

[griffin28]

See Unstructured Spatial Field Implementation for a concrete example implementing this proposed Unstructured Spatial Field extension.

[johguenther]

What about generic polyhedron cells?

[griffin28]

What about generic polyhedron cells?

As the draft is written you can represent any cell type to include generic polyhedron since cell.index marks the beginning of each cell and you can infer all of the points that belong to a cell from the beginning indices associated with each cell. I guess cell.type helps with determining connectivity. So the challenge here will be how do we represent connectivity in a scalable way. Trying to enumerate all of the generic polyhedron cells in the spec is not feasible. ~Maybe removing cell.type~ and using some combination of cell.edges, cell.faces and some associated indices. Alternatively, cell.type could be an Array1D of string and have the back-ends specify what cell type names they support.

[griffin28]

What about generic polyhedron cells?

Do you have a specific use case in mind? Some of the feedback is that you can convert (e.g. VTK filter) any unknown generic polyhedron cell into a supported type and then plumb through ANARI.

[griffin28]

Thinking about this more and looking at VTK's vtkPolyhedron class, to solve the connectivity problem, we would need to add an additional parameter cell.faces of type ARRAY1D that indexes into the vertex arrays with a structure similar to what's specified for vtkPolyhedron::SetFaces(). Now we would only need to support one additional cell.type enum POLYHEDRON which corresponds to VTK's VTK_POLYHEDRON enum. cell.faces would only be required if cell.type is POLYHEDRON, otherwise the connectivity can be inferred from cell.type.

[griffin28]

As far as use cases for generic Polyhedron: tecplot and Devil Ray?

[johguenther]

As for usecases for generic polyhedrons: we got a request, see https://github.com/RenderKit/openvkl/issues/16

[jeffamstutz]

Greg's response seems to indicate the reality that renderer vendors aren't motivated to directly support generic polyhedra -- I've still yet to see an example of a renderer which does this in practice.

[johguenther]

The hardest issue to support generic polyhedra seems to be the interpolation when sampling inside the generic cell. Here, "mean value interpolation" (Ju et al., "Mean Value Coordinates for Closed Triangular Meshes") is an established answer, used e.g. in Muigg et al. "Scalable Hybrid Unstructured and Structured Grid Raycasting".

[jeffamstutz]

If you read the Muigg et al. paper, they still have a fixed number of cell types that are supported (see Table 1): tets, pyramids, prism, octahedrons, and hexahedrons. While the math is described using Ju et al., they do not describe an volume renderer that actually implements fully arbitrary polyhedra cells. I think there is a misunderstanding that Ju et al.'s solution can be iteratively computed with O(1) storage -- meaning that it appears you need at least O(N) for the weights per-face. You can do this with stack allocation when the interpolation kernel has a known number of faces, but I think you'll hit a very hard wall trying to implement this for an unbounded number of faces.

IMHO, this continues to add to the argument that it is prohibitively expensive to implement arbitrary numbers of faces for an unstructured spatial field in a renderer, thus I strongly urge someone on the WG to actually implement it first so we don't naively walk into a DOA extension.

[ingowald]

Can we re-open this discussion about the actual enum values for the cell types? Agree we should have explicit enums for readability, but since these are not yet in the header file - not even with some '#ifdef _ANARI_EXTENSION_UNSTRUCTURED' or something - everybody that does want to implement this extension currently has to define his own enums, and if everybody uses different values then that's a nightmare both now (incompatible viewers and backends) and also later (once we do adopt values and existing backends use different values).

As such, I'd argue we need to agree ASAP about what values we use. I'd personally prefer using the same values that VTK uses - because every app that may possibly use this will likely already have used VTK, too - but whichever set of numbers we choose will be infinitely better than "don't know what it'll be".

Suggest we take a poll, and go with majority vote by end of this week (or sooner if a consensus appears). As said above my vote is on VTK values, but I'll take anything as long as we put a nail in this coffin.

[ingowald]

Note I'll actually amend my vote from "my preference is vtk" to "if ospray already uses another numbering, and there are already apps that use that, then i'd go with whatever existing ospray and apps already use". Whatever is easiest, as long as we make progress here.

[johguenther]

OSPRay uses the values from VTK, as apparently is the vtkAnari wrapper from @griffin28 in the original post (unless it was changed recently).