Hi David,
YES! This is definitely worth a discussion.
It sounds similar to a bit of a dilemma I’m having on the Speckle-Unreal side also.
I’m going to take this opportunity to piggyback some of my issues into this discussion because I imagine they will be the same in Unity.
An issue I’m facing with Speckle-Unreal, is there are several types of native meshes that a user might want to convert to.
Secondly, I want to allow users to write their own converters without having to modify the Speckle-Unreal plugin’s source code.
Thirdly, some objects, like point-clouds and breps aren’t natively supported by Unreal Engine, but they are through a plugin. I’m hesitant to make the Speckle-Unreal connector dependent on plugins (particularly third party ones) that most users won’t even need, and so I’m currently toying with this idea of modular converters.
In my (half baked) idea of modular converters, we would have Mesh, Camera, Blocks, Point-Cloud etc conversion, all in separate classes implementing an interface (eg. ISpeckleTypeConverter)
We would store the active ISpeckleTypeConverters in a TMap (c# equivalent would be a Dictionary) that maps a Speckle Type (eg. "Objects.Geometry.Mesh") as a string, to an ISpeckleTypeConverter.
During receive, we then use the Speckle Type of our object to get its converter using the TMap.
I think Unity has some similar issue with point clouds being dependent on a third party plugin. And the need to modify source code to extend conversion.
In Unity, these ISpeckleTypeConverter could be serialisable, and grouped into kits using ScriptableObjects.
What do you think (have I gone too far? is this a separate discussion?)