I’ve been thinking this over and I’ve got a slightly different approach for consideration!
An object that gets stored in Speckle can exist in three different forms:
Serialized Objects, the transport representation (i.e. pure JSON) - this is how the object is stored on the SpeckleServer, or in the local or in-memory transport.
Speckle Objects, the programming environment representation: this is a 1 to 1 mapping of the transport representation, but as an object of whatever programming environment you use. E.G. .Net object, python object, ruby object (did you know that InfoWorks, a hydraulic modelling package, uses ruby for scripting? It’s not just SketchUp!!!)
Tagged Native Objects, i.e. Rhino objects with additional properties. Every application that we write connectors for has some mechanism for adding additional data to the object, and for each application, there is some convention established for storing extra, Speckle-related properties. Revit properties, GSA sIDs, Rhino UserData, Microstation EngineeringContext, etc… all serve this purpose.
I think a lot of confusion is due to Grasshopper being both a programming environment and part of Rhino, so it’s not always clear if people are expecting Rhino objects with data (Tagged Native Objects) or straight up speckle objects (Objects built from a Schema).
In addition, I got confused by the SchemaBuilder creating Speckle Objects, but in the format of Tagged Native Objects: i.e. an
Objects.Geometry object with an
Objects.BuiltElement object on the
@speckleSchema property. I would expect that anytime a Tagged Native Object is converted to a Speckle Object, it will be turned into form 2. It makes sense for Rhino native objects to have speckle schema data attached, but these should always be translated directly into ‘proper’ SpeckleObjects (e.g. Rhino geomety tagged as Wall → Objects.BuiltElement.Wall), not to a Speckle.Objects.Geometry with a
While I agree that a right-click toggle on the Schema Builder allows everyone to move forward, I am concerned that it will not help the users build a consistent mental model of what is going on.
One way to get clarity is to say:
- In Rhino, we have Rhino native objects + additional data (form 3)
- In Grasshopper, we have Speckle Objects (form 2)
This means that the Grasshopper component only creates Speckle Objects (no toggle for tagging) and the Rhino commands (CreateWall, etc…) only every add data to Rhino Objects, and we can translate between the two forms with the
This is easy to explain, and easy to keep track of, and the Revit connector / kit doesn’t need to know anything about how we keep track of BIM data in Rhino.
Is there ever a need to create Speckle Objects that look like Tagged Native Objects?
Regarding the point about destructive sending: I’m not sure that’s a huge concern in real workflows. In most cases, you’ll be re-receiving the data after it gets processed by another program, so even if it gets sent out ‘losslessly’ by Rhino, once Revit processes it, and you send it back, the floor surface will have become a polyline anyhow.
I’m a little suprised at how long this post turned out! I hope it’s clear, and would be happy to jump on a call to discuss further. My underlying concern to keep the mental model needed to use Speckle as simple as possible, since any complexity really slows down adoption.
Here is how these ideas would look in some workflows:
Building a BIM model in Rhino only:
- Model Geometry (in Rhino)
- Tag the geometry with Speckle Schema (in Rhino)
- Send to Speckle (with the Rhino connector)
Building a BIM model with Rhino geometry and GH processing
- Model base geometry (in Rhino):
- Create Speckle objects in GH (with the Schema Builder / CreateSpeckleObject component). This will create Speckle Objects.
- (Optional) Add custom data parameters to the SpeckleObjects.
- Send to Speckle with the Grasshopper sender component.
Build model in GH, bake to Rhino, then send to Revit (does anyone do this?)
- Create a parametric GH model.
- Create SpeckleObjects in GH.
- Run the Speckle Objects through the
- Bake to Rhino.
- Send to Speckle server with the Rhino connector.
This last workflow could also be enabled by overriding
GH_Component.BakeGeometry in the Schema Builder / Create Speckle Object component, so that the created Speckle object would be convered to a Tagged Rhino Object then baked (and we could skip step 3).