Hi all, I came across 2 strange things that I think are worth sharing.
Application id
When I send geometry from Grasshopper the Speckle object doesn’t have an application id (see 2 orange lines in screenshot): Stream from GH
But when I send it from Rhino it does have an application id (see 2 purple circles in screenshot): Stream from Rhino
Geometry in viewer
When I was playing around with this, I noticed some geometry is not showing correctly in the 3D web viewer. I created a box, Speckle floor and sphere in GH and send it to Speckle. I believe the sphere is shown on the correct location (0,0,0), but the box and outline of the Speckle floor aren’t. When I receive it in GH it’s on the same and correct location. It’s all shown in the screenshot, hopefully the screenshot makes sense…
That’s because elements generated in Grasshopper don’t have an id, instead if generated in Rhino they have it. So, unfortunately, there’s not much we can do there!
This is also why in the GrasshopperBIM components of Speckle we are actually generating an application Id each time the component is instantiated.
Regarding the viewer bug, I’ll let other speckles comment! Maybe a sample file&stream would help.
Hi Matteo, thank you for the explanation! Would it be possible to modify the Grasshopper “To Speckle” component so it also generates an application Id just like the GrasshopperBIM components of Speckle? Could this solve the issue?
About the viewer, the example stream is here: Stream from GH
And an example file (the one from the screenshot): appid.gh (11.5 KB)
We could, but it would be unreliable as there wouldn’t be a safe way to know what element is what. For instance, you have 3 lines in GH and Speckle gives them ids A, B, and C before sending. If you reverse the order of the lines they’d still come through as A, B, C instead of C, B, A.
Therefore it might be best if the user manually assigns the ids to avoid unexpected behaviors… What do you think? What’s your use case in this instance?
The applicationId is used to keep track of the original object in the software it was in when it was converted ToSpeckle.
This makes sense in programs like Revit, Rhino, etc… where anything you create exists in the model. But not so much in GH where everytime you press F5, the entire thing is re-generated (and hence, will have new guid values (where available).
So adding the applicationId to conversions in grasshopper would be quite ineffective, as you’d never be able to map anything back to that specific object in GH once the solution was recomputed.
Maybe we’re not understanding fully your use-case though, could you share more details of what you intend to use the applicationId for?
I can see some exception where this could be directly applicable though: Objects referenced from a Rhino doc (i.e. if it’s not a GH geometry, but a referenced geometry from Rhino it should have a consistent guid you could track) Not sure what @teocomi and @dimitrie would think about this.
Thank you Matteo and Alan for your detailed and clear answer!
We want to send GH geometry and receive it in Bentley software. Then make changes in GH and update the objects in Bentley. Therefore, we need the applicationId in GH. As mentioned by Alan, manually assigning the applicationId works great (I’ve used this for V1 as well).
I brought it up because I thought it would make sense from a less experienced user point of view to always have an applicationId when sending objects from Grasshopper to Speckle, regardless of the type of object. It does makes sense where this “issue” comes from.
I just fixed the smaller edge-case were objects that are referenced from the Rhino document will have an applicationId.
As for the general behaviour of every object coming out of our connectors having an applicationId, I’m leaning towards giving it a try, as it will enable some nice use-cases.
I’ll try to come up with a proposal on how these should work in grasshopper and share it here!
