Say I am building a Speckle object of a floor in a custom C# app, and I want users to be able to open that floor in Revit, Rhino, and ArchiCAD natively. What is the best way to structure that payload so that everything is picked up?
Polyline
- SpeckleSchema of RevitFloor
Seems to be the best way from an end user perspective, for Revit, but what about for ArchiCAD? Will ArchiCAD know that the Revitfloor is a floor and convert it?
Eventually, when the ArchiCAD floor needs its own schema fields, how will I differentiate between schemas?
This floor has a parent type that allows for dynamic expansion of said type, similar to Speckle.Base.
What we would like to do is map from say My.Floor to Objects.BuiltEnvironment.Floor | Objects.BuiltEnvironment.Revit.RevitFloor.
I noticed that with each “package-aligned” library, some properties exist and others don’t; Revit has family, parameters and type, for example. I have a resolver that can handle the resolving of which type is required.
For example, the resolver will return Objects.BuiltEnvironment.RevitFloor if Revit properties exist on my “expando” object, and will return another type if properties that match those types exist. The only issue I see is in the clashing of properties, in which a priority might be able to be provided… undecided on that one.
The key aim for me with the custom types is to define “as little as needed” on our custom types to and then to utilise the “expando properties” to extend the types where needed to get mapping/speckle conversion etc working (or at least that’s the desire on my end).
My proposed workflow is to:
Create an instance of my.floor
Provide a mapping of properties which are required by the speckle types (ie parameters, family, and type for going to revit).
Convert to speckle
Do whatever else
It makes sense to me that we perform an ETL-like process on our custom object model to get our data into a format that plays well with the speckle types we wish to convert to, and then convert them, rather than writing anything fancy using speckle libraries.
Just to clarify, you guys are talking about the @speckleSchema attribute that gets attached when using Rhino Mapper for example?
This was only designed to target a specific hostApp at a time. Upon receiving, the connector will detect this and flip the hierarchy so that
Polyline
- SpeckleSchema of RevitFloor
actually becomes in Revit
RevitFloor
- Polyline as the outline of said floor
In essence, it wouldn’t make a difference if you sent the polyline with the speckleschema attached, or directly the RevitFloor.
Sadly, we’re only ever expecting 1 schema to be applied to a geometry object, so you can’t really mix and match, an object is either a RevitFloor or an ArchicadFloor (both are Floor type, but that only provides minimum compatibility across apps)
Receiving a RevitFloor in Archicad will use the basic Floor conversion, and same on the other direction. Any revit specific info will not be used on the archicad conversion and viceversa.
I think right now, you don’t really. The easiest way to deal with this would be to have a revit and an archicad model that you send to, each containing specifically RevitFloor and ArchicadFloor (for example). In essence creating 2 different commits, each for it’s own purpose.
Not sure how this would align with your needs, so would be nice to know what is it you intend to do with this data after receiving it in both Revit and Archicad. Is this a final action or would you expect further interactions between Revit ↔ Archicad (if so, please elaborate)
In our case at the moment, we just want to be able to demonstrate an automate function to the business where we can author some geo in the cloud and then turn around and say “and you can pull this directly into your BIM software of choice” so just wanted to confirm any caveats around that - in this case, we’d just need to make 2 models, x/revit and x/archicad, (x/tekla, etc) which is totally fine for our purposes I think.
You may want to reference from the function a target set of shared/project parameters to be present in the receiving model. This is based on us not creating parameters where none exited from arbitrary properties.
The best likely first POC for this is to upload project information from a populated template project.