Hope everyone is having fun speckling We’ve been wondering whether anyone would find the option of having a speckle object that has a displaymesh in the viewer and to be able to recieve it in mesh-supported connector.
What this means is that if I send something in Tekla Structures , you will now have two options, the default option will create a Revit Element accordingly with associated geometry . If this doesn’t convert fully , there will be another option that will enable receiving all the elements as meshes as would Rhino would by default.
This would apply in particular to connectors like Revit/Tekla Structures or connectors that support native mesh conversion to an object . The benefits of having something like this is that you have something to fall back in terms of conversion for objects.
I think this is necessary. While having native objects is great there will undoubtedly be problems where the objects in one BIM software cannot be exactly replicated in another. With the direct mesh you will at least get an accurate representation.
Example when we export from Tekla to Revit in our office (via IFC now) it is only for coordination. We don’t need to edit in Revit. And it’s very important to have it accurately represented since that’s how it will be built. So I would prefer to just get the direct mesh in Revit. And I’m sure some others would as well.
So I think it’s a great idea to have this as an option! The default can be native Revit objects but having this as a setting will be very useful. Certainly for me!
Is the proposal that each Connector will create both a) Speckle BIM geometry schema, and also b) a Mesh equivalent for each object committed?
Or that the option is for uses to commit a or b at commit time?
If it were that ALL objects have a mesh equivalent of their geometry included then I’m behind that.
Purely selfishly, I have a spatial analysis workflow that only uses mesh and am slowly adding conversions of Speckle.Geometys to mesh on receive albeit prioritising those I expect to receive from commits. It’s this sort of scenario that the proposal as I understand it would help with, to avoid the time impediments of prototyping such workflows.
From developing a Reader connector point of view, an early release of a new Reader can begin with supporting meshes and incrementally add as many conversions over time as is possible/logical depending on the internal Schemas/APIs of the receiving application.
Well there’s a display mesh equivalent for each object committed by default on send, but the proposal is that on recieve that this display mesh will be used to generate an object as opposed to a native object. So it’s just an option to generate b for now if possible by as opposed to a which is the default.
We’ve been wondering whether anyone would find the option of having a speckle object that has a displaymesh in the viewer and to be able to recieve it in mesh-supported connector.
behind that.