Please feel free to give me a slap on the wrist and send me on my way. I was hoping that attached data would be seen on clicking the object… in the same way that area etc. are shown? Or if the inclusion of the geometry in a speckle object is more of a link then would there be an option to have “This object you have clicked on is a member of the following speckle objects…” with some way to then see that?
Instead of Create Speckle Object (CSO) and passing the geometry as one of its properties, you want to extend the geometry object with the data. There are times when both options are correct, when the data tree is perhaps more complex. But for viewer interaction point-and-click data viewing the Extend Speckle Object (ESO) is the node you want
The first data point is expecting a Speckle Object. If you pass it a native object, such as a Brep, it will first convert this to Speckle, and then the additional props you add will directly inject data properties into that object.
To replicate and extend your GH definition, I am showing both CSO and ESO nodes in action:
The panels and the Deconstruct Speckle Object (DSO) nodes show the nature of the data that will be sent to Speckle. The CSO path includes the data props alongside the geometry, whereas the ESO adds the data props to the geometry object. Which is the web viewer experience reproduced:
While this is an immediate solution @jjsolly it isn’t the perfect outcome.
Extending geometry objects like this will achieve the point-and-click data view, but those data points will not be meaningfully received in any of the Speckle Connectors - including Grasshopper.
If you want the purist approach, you must add geometry to the displayValue of the previous CSO example. Ideally, this would be Mesh or Linework, but technically, it could be the Brep object.
If you enable the NativeToSpeckle conversion as an isolated tool (under Developer Components)
You can plug the converted object’s displayValue (a mesh) into your CSO object with a similarly named prop. Whether or not you retain the original Brep is up to you and if you want to keep its Breppiness.
@jonathon thanks so much for all the options for how to do this. It makes sense and we’ll give the various options a whirl.
Can i ask - as perhaps I’m now confused… when using “create speckle object” in gh - am I actually creating a linked group of speckle objects - i.e. an object that contains three objects?
Compared to “extend speckle object” - which adds data to the single object itself?
Hope that question makes sense. If there’s a better explanation of this somewhere that I’ve missed or forgotten about please feel free to just point me there.
You’ve missed nothing. We could do a better job of recording this. The GH and Dynamo docs are overdue a refresh following the “Great Rename.” I’ll add it to the to-do list.
Your question isn’t silly, and I apologise if it is confusing.
All object conversions to and from Speckle to Native follow the base object schemas. Speckle objects at the data layer are flexible and open, but the conversions look for the expected properties and values.
However, in conversion, the conversions will traverse the data ‘tree’ until all convertible objects have been processed.
The web viewer knows nothing about object schemas and will present to the observer the first displayable object it finds on each ‘branch’—this is why the extend object node on a Mesh shows the data properties. But where the mesh object is a ‘child’ of another object, such as the one you first made, the ‘clickable’ object is just on the mesh and not the parent, which had the data properties.
The final purist or belt-and-braces solution I shared is creating a ‘displayable’ object that satisfies the viewer and contains the convertible objects, which will be converted into receiving connectors.
It is eminently flexible but also reliant on a few internal rules. This means that when you make objects from scratch, what you’ll use them for will impact how much care you need to put into them.
There are still edge cases and gotchas in all of this, like a Beam element with its displayable mesh but also carries the profile and extrusion paths as lines, which are also technically displayable.
