The goal of this post is to inform others about the ongoing efforts regarding serialization/deserialization in VTK.
@alexy.pellegrini and @jaswantp started separate efforts to address slightly different use cases , and after sharing ideas, we identified a list of requirements that should allow for addressing as many use cases as possible.
The table below presents how both approaches address the requirements.
While it is likely that the automated approach is preferred, we would love to hear your opinion about it. The goal is to try to get the best of both worlds.
The idea is also to gather other potential use cases to extend this list of requirements.
 Use cases:
Jaswant: trame based server communicating with a VTK-wasm client
Alexy: VTK OpenXR application with multiple clients (XR collaboration)
|Serialization of vtkObject properties
|Fully automated using wrapping infrastructure + manual exceptions
|Fully manual using new virtual methods introduced in vtkObject
|Auto-generated properties relies on David Gobbi’s property parser in Wrapping/Tools(controlled by an exclusion list documented with reason for exclusion)
|Only objects reimplementing the virtual methods are serialized (provides control)
|Non-intrusive: Serializer code outside the class. (Register generated serializers in a manager class automatically)
|Intrusive: Serialization code at the vtkObject level, this provides access to private members without any friendship or trick
|Autogenerated Serialize/Deserialize function pointers are registered with typeid.
|Only properties explicitly serialized in the overridden method are serialized: Provides control, shortcuts (e.g. serializing a matrix as a double array instead of a whole object), only what is needed (some properties are redundant or not relevant)
|Instantiation of vtkObject (deserialization)
|Constructors identified with class name
|Objects identified with class name
|“Factory” to create vtkObjects from class name is auto-generated
|Factory to create vtkObjects from class name listed (hardcoded) in serializer class. To be improved.
|data arrays in separate blobs, referenced in the json with a unique hash.
|Input data in json, base64 encoded. Data strategy class available to change this behavior in subclasses
|Incremental and asynchronous (new clients get the whole scene upon connection, existing clients only get what changes)
|Supported using MTime
|Supported using MTime
|Context is local to the vtkObjectManager instance
|Context is local to a serializer instance
|User code registration (serialize VTK custom subclasses from the application side)
|Marshaling is possible externally by providing user VTK modules to the vtk_module_marshal function in CMake.
|Public functions available to add new types to the hardcoded factory
|CMake helper functions auto-generate registration code for (de)serialization handlers and constructors.