I’m taking a look into the updating of a model. Speckle somehow rearranges the data after receiving. Somehow the information got shaken up a bit during the updating process. Right now it is only a test, but this might also be an issue in future projects.
A. Input:
A Rhino file with two object types (direct shape vs real Revit geometry)
Solid geometry as piles on Layer 1 → used for creating generic model direct shapes (btw: you don’t have the foundation category in the grasshopper nodes)
Axe geometry as input for piles on Layer 2 → used for creating structural columns
filling out parameters in Revit (numbering to see what it does)
annotating the direct shape and the structural columns
D. I’m receiving the updated Rhino Geometry
Comparison:
The directshape geometry creates itself completely new after the update. As a result the annotations and parameters in Revit are lost, which is not ideal … but also means … never use directshape for drawing production. Same rule like for IFC imports. Directshape is
The columns of the column stream seem to be shaken up
Before:
… the numbers seem to be walking around … which they should not
Of course, things are easily solvable when the parameters are mixed in on the Grasshopper side, but in reality, maybe drafters are adding information in Revit, which then is lost.
I tested it out on an arbitrary file, which I can provide incl. the Grasshopper Script. It would be really cool if you could take a look at it.
Thanks a lot for the report; there are a couple of things going on here:
DirectShapes not updating: we’re aware and are planning to look into it; cc @gokermu and @connor not sure we have a GitHub issue already for it
GH element ids: Grasshopper is not automatically assigning IDs to elements (like RHino does), so we’re basically faking some IDs when sending to Revit, for the update mechanism to work. As a consequence, if your list of lines is edited, there’s no way for Speckle to know which ones have been added/removed. If the lines were instead Rhino elements, things should work as expected… One workaround would be to set your own IDs, but maybe @AlanRynne has additional insights or ideas on this.
The directshape update would be really cool. And for the updating … you are totally right with the Grasshopper list vs. the ID. Will try it out in an adapted way!
It would be nice to have a look at your script, but I’m fairly certain @teocomi’s answer is pretty much correct.
We use the internal interation number of the grasshopper component with some extra info to compute this fake “applicationId”:
As for the suggestion of assigning your own applicationId, this is the way to go in my opinion. It gives you total control over how these members are identified. You can do this after creating your elements with an Extend Speckle Object node by creating a non-detached property called applicationId and assigning whatever value you want to it.
Be careful with this though, all applicationId’s are supposed to be unique, so do make them as unique as possible. I recommend creating some GUID and pasting it in a panel as the base of your application id’s. That way you don’t risk them already existing anywhere else.
For reading the objects out of the layers a colleague of mine created a node to also read out their Rhino GUIDs. I have plugged the GUIDs in the “extend speckle object” node of yours and it was fine. @AlanRynne and @teocomi please contact us, in case you want to have the code snippet … in case it was not already tackled by you in your upcoming 2.10.
