Generic operators

[markus-stoll]

There are operators task that could be applied on different mesh types (e.g. polyData and unstructuredGrid). And there are vtk representations (e.g. point data) that could be used for passing in this datatypes.

Does this fit into our type concept? Should we add a point data type? For example: Can we merge https://github.com/CognitionGuidedSurgery/msml/blob/d1373c198c54b2d586c5027101f24b85464a959c/share/alphabet/msml_operators/misc/TransformSurfaceBarycentric.xml and https://github.com/CognitionGuidedSurgery/msml/blob/d1373c198c54b2d586c5027101f24b85464a959c/share/alphabet/msml_operators/misc/TransformMeshBarycentric.xml ?

[wadoon]

Current type model:

One Operator has one input sequence of input types returns struct with fixed output types.

operator( int, str ) -> {'a' : int, 'b': str}

Types can be inherited.

Not implemented is overloading or parametrization.

[markus-stoll]

Oky then we can use a basetype like vtkPointData as input type for an operator an pass e.g. vtkPolyData to that operator, when we define that vtkPolyData extends vtkPointData? Tha would be nice.

How about the return type? Because such an operator would return vtkPolyData in a vtkPointData output type defintion and the next operator migh have only a vtkPolyData input type definition.

[wadoon]

• Yes, Liskov substitution principle
• If the next output, only takes vtkPolyData, but you return vtkPointData.
  We need normally a cast, but something we haven't yet. (Currently an error should be displayed)

Something I would target in MSML 2.0

[dschauba]

I now have a similar problem.
Operators i wrote use vtkpolydata as input and output (if they produce any vtk data).
Now connecting these operators to others, like mesherCGALi2v (produces vtkunstructuredgrid) is not possible.

Would it be helpful to add an explicit conversion operator, for now?
(Since common type/generic operators is targeted for MSML 2.0)

[wadoon]

The idea is not to need an explicit conversion.
We need more like an downcasting, to say that the returned output is in that particular case a sub type of the promised one.

A quick solution is to create an Operator with the identity function, but it is ugly:

<operator name="PolyData2UGrid">
<runtime><python module="xxx" function="identity" /> </runtime>
<input>     <arg name="a" physical="vtp"> </input>
<output>     <arg name="a" physical="vtu">  </output>
</operator>

Nevertheless, your programm should work, but give you an error message about the type mismatch.

[markus-stoll]

VTKReadPolyData and UnstructuredGrid are usually not easily convertable.

For UnstructuredGrid -> VTKReadPolyData
If you use the IOHelper:ReadPolyData to read in VTKPolyData, you can also pass a UnstructuredGrid file where ReadPolyData will automatically generate a surface representation of the UnstructuredGrid on c++ via MiscMeshOperators::ExtractSurfaceMesh.
What is done here is more than a conversion - because the boundary surface elements will be created, if they do not exist, yet - (e.g. when volumes were created by mesherCGALi2v)
If you do not only need to outer surface but also iterfaces between tetrahedrons of different material ids, you should use the extractAllSurfacesByMaterial operator first. It appends traingles to the UnstructuredGrid.

Vice versa: VTKReadPolyData -> UnstructuredGrid
This should be avoided - we should use UnstructuredGrid only for volumetric data.

[dschauba]

Okay, thanks to both of you!
MiscMeshOperators::ExtractSurfaceMesh is what i ended up using.

For downcasting, vtkPolyData is narrower than vtkUnstructuredGrid, right?
I think i get it now: Markus already told me, packing everything into the most generic data structure (like, vtkUnstructuredGrid) is not really desired.

Looking at this from an operator like CalculateSubdivisionSurface, it makes sense.
This operator is only usefull for surfaces, so vtkPolyData as in-/output fits nicely.
A vtkUnstructedGrid could transport the same surface data, but also stuff like tetrahedral meshed data (possibly no usefull input for CalculateSubdivisionSurface).

[markus-stoll]

I think these are very important points, maybe we can have a short discussion at the hackfest to make sure we have the same understanding of this topic and can answer the following questions:

-How to implement Operators that only care for points in data (polyData and unstructuredGrids)
-How to implement Operators that care for (points and) triangles (polyData and UnstructuredGrids)

But like areku, I would target the 2.0 for the actual implementation of discussed concepts.