I’m trying to figure out whether I can pass information back and forth in the object model via non-visual properties. For example, I want to create an object that represents an electrical transformer. There are lots of visual parts to that, but there is a lot of information that I want to use in systems upstream or downstream of Speckle that rely on non-visual properties. Things like operating temperatures, oil capacity, voltage ratings - stuff that would be on an equipment nameplate that denotes the operating parameters of the equipment.
Can I do this, assuming I create a new Kit with Base objects that reflect my particular industry/domain? Today that type of information is stored on files in various ways, typically reflected by some custom property sets on a particular file. To illustrate, in Autodesk Inventor, they are called iProps, in AutoCAD these properties might be in 1 to N custom blocks in the drawings as attributes in the block(s) or even extended file attributes. Conversion would likely mean pulling those out of Speckle properties and populating them back into whatever file mechanism is there.
Hi @Shawn_Weekly , this is an important aspect of how we handle our object model: in additional to the props you define in your class (which can be of any type), you can also dynamically add props on conversion to speckle and then check for dynamically added props when receiving into your target application. This means you can add whatever combination of types of props you’d like to best suit your workflow.
To use your example, you can define a Transformer speckle base class with for example, a List<Mesh> property representing the geometry of the transformer, a Int prop for the voltage rating, and a double for oil capacity, and a custom enum for insulation type.
All Transformer objects defined by your kit can be expected to have these properties when receiving them back in your target application. However, you can dynamically add any combination of additional properties (string for manufacturer and cooling system, or a Dictionary<string, object> representing AutoCAD XDATA) from specific source applications that may not be present on Transformers sent from other applications.
When receiving, the conversion can check for whether or not a dynamically added property exists, and handle that accordingly. This is already being done in our Civil3D connector, another Autocad vertical, where property sets are dynamically attached to elements sent from Civil3D and then recreated as property sets on the element when receiving in Civil3D. The checking process is more complicated when moving objects between applications, but hypothetically possible - we’ve recently released a beta of a mapping tool for our Revit connector to test use cases where people would want to map specific properties on receive
