I am having issues when I want to ‘update’ my geometry in Rhino.
I have a massing which I load into the file and when I then ‘update’ this with a new stream, rather than overwriting the old geometry with the new (assuming it has the same layer structure) it simply returns both the new and old geometry (but on the same layer).
I am also getting the same issue when I do this with a grid, but in this case the grid is a block. It does not update, it simply returns a duplicate of the original block.
I have the most recent verison installed.
Can you please let me know why I am experiencing this- this would be a fantastic workflow- if we could simply update, rather than get duplicates.
is the massing originally created in Rhino or in another software? what is your workflow for updating this massing?
are you receiving the new commits in update mode instead of create mode?
are you having issues getting other types of geometry to update?
Regarding our general approach to updating, we’re looking to only support forward-moving workflows, which means workflows that are one-directional with speckle as the only mode of exchange (vs file import and export).
What this means is that if your workflow is:
import massing into file 1
import massing into file 2
change massing in file 2 and send to a speckle stream
receive changed massing in file 1
Then we can’t update the massing in file 1, since the two massing will have different guids in their respective files on import.
Currently updating behavior with blocks will take the existing block definition and update the location of the instance, rather than updating the block definition geometry itself. We can look into improving this behavior, though it may be encapsulated in a receive setting as some users may prefer to keep the original definition. Hope this helps!
We are creating the grid (as a block) / massing surfaces in Rhino and then passing them up to Speckle. This massing is then interacted with in grasshopper which is working fantastically. We are updating rather than creating-
Where our issue comes is the following workflow.
A member of our team pulls down a version of the grid/massing into what could be a blank rhino file (this is one of the advantages we see with speckle- as we can then pull into empty or working files, rather than having to open up a base file.
A new version of the grid is then passed up to speckle, from our base grid model.
What we want to happen is that the user can simply press update and the updated grid or massing then superseded the old one. This could be for anything- say a new feature stair using the same layer structure.
The example you give, lets say we update the massing but the file name has changed, does that also mean that the GUID will be different. I am more than happy to catch up to show you how this workflow works- but I would think its quite standards.
Ah I see, it sounds like the grasshopper connector may be stripping the applicationIds from the rhino objects in your workflow - do you see an applicationId property with a value in your grids/masses after you send them from grasshopper?
If this is the case I’ll check with @AlanRynne when he’s back from vacation to see if there’s a quick fix
Also regarding this note:
As far as I’m aware, changing the file name shouldn’t change the object guids so updating should still work in this case.
Just to clarify, we are not sending the geometry in from grasshopper, just receiving, all geometry is made in rhino. I am happy to send you over some of the links to test?
So let me explain a bit the differences between Rhino and GH in terms of applicationIDs, as there are some limitations on the GH side
Grasshopper has no notion of “applicationIDs or GUIDs” as there is no persistence for objects (everything gets executed again on every run), so we can’t keep track of what Grasshopper was a Rhino object before (at least… not automatically)
When we convert an object ToNative , we’ll loose that application ID as Grasshopper doesn’t have support for object metadata
I’m not really sure how your interaction between Grasshopper and Rhino is happening. So let me just ask for some clarification.
You are creating some massing geometry (I guess BREPS) in Rhino
You are sending this to Speckle
You are receiving that sent data in Grasshopper
Some operations are made in Grasshopper
Here’s where I’m not sure about the details
Since you said you’re not sending, I’m assuming you use Grasshopper to bake geometry onto the Rhino file? How is the interaction between GH and Rhino happening?
If you’re using GH to bake, that bake operation will most definitely create new GUIDS for each baked object (even if you use Elefront, you’ll face the same issue on the first bake)
If instead you are sending from Grasshopper to Speckle to Rhino, you can have total control over the applicationIDs of the objects sent from Grasshopper, and if these are found when receiving in Rhino, they will be properly updated/replaced.
Just to clarify, this is not an issue with grasshopper- I am simply recieving in grasshopper and that works fine.
The issue is recieving new updates in rhino which have the ability to override the previous commits- rather than simply giving me a version of both the new commit and the old commit (updates which are originally sent from rhino also).
Your explanation of the different was interesting though! thankyou
I hope this makes sense, but I think its a lot less technical.
Forgot to reply to you here but on the following release, receiving in Rhino in update mode will have the desired result (the objects will land on the same layers as the initial commit), which allows you to successively receive as many times as necessary.
Here’s where I’m not sure about the details