Recovery of Built Elements Support in Grasshopper (Archicad Connector)

Hi team,

I’ve been testing Speckle Next-Gen with the Archicad connector and noticed that all elements are now received in Grasshopper as generic meshes (Objects.Geometry.Mesh) instead of structured built elements like ArchicadColumn, ArchicadWall, etc., as was the case with previous versions.

This loss of built element schemas significantly limits what we can do downstream in Grasshopper. Previously, I could rely on specific object types (e.g., ArchicadColumn) to extract base lines, assign parameters, or build logical filters based on type. Now, with everything coming in as a mesh wrapped in DataObject, these workflows are broken or extremely difficult to reproduce.

This situation seems similar to what other users (Revit users like @eestrado and @karim-daw) are reporting in the Next-Gen Connectors: Changelog, Supported Workflows and FAQ — where the lack of schema objects like RevitBeam, RevitColumn, or RevitFloor in Next-Gen has removed a key part of what made Speckle powerful: structured data interoperability.

The flexibility of sending models from Archicad to Grasshopper, applying logic and filters, and then forwarding data to other platforms was a huge strength — and much of that depended on built element typing.

I understand this might be a known limitation even in the alpha release, but I wanted to add my voice from the Archicad + Grasshopper side to ask:

  • Will built elements (or structured schemas) return in upcoming releases?

  • Is there any roadmap or workaround to access element-specific properties (like base lines or classification) without relying on generic mesh data?

Thanks for all the work on Next-Gen — it’s exciting to see it evolve — and specially to @clrkng for all the help and her feedback. But I believe recovering this layer of structured data is key to maintaining the practical value for BIM workflows.

2 Likes

Continuing our convo here, I appreciate that the removal of BuiltElements schemas requires some adjusting to, especially if you are approaching it from our old interop perspective. Our team internally needed quite some time to adjust mindsets as well, but in summary our reasons for doing so are as follows:

  • optimization: most of these properties were removed from the schemas precisely because they were often duplicated inside the parameters on the object
  • standardization & simplification: our Next-Gen approach means these properties will always be found inside the properties field of the DataObject coming out of each application, not found under different properties and names in different application schemas

That being said, we want to make sure we are extracting all important properties for you, even if they appear in different places now.

  • for Archicad, classification info is now inside Properties (one element can have many classifications, which was a limitation of the old schema)
  • all application DataObjects will have their type on the object, in the type property (not speckle_type)
  • We are publishing location curves and points from Revit, but currently aren’t doing so in Archicad. If this was essential for many people, I can definitely add a basecurve field to the ArchicadObject schema and see what we can extract from our new connector

What’s currently missing (and planned for Next-Gen Grasshopper beta release):

What’s currently missing (and not yet planned):

  • Support for creating native Revit elements, from any source, whether it’s via old builtelements schemas or some other mechanism
3 Likes

Hi Claire!

Tanks so much for the thoughtful and detailed answer — I really appreciate the clarity behind the shift in approach.

The move toward standardizing and simplifying how properties are structured in DataObjects makes a lot of sense. It’ll definitely help when building automations that work across different applications, regardless of where the data comes from.

That said, one thing I found very useful in previous workflows was access to generative geometry — like slab boundaries or reference lines for columns, beams, and walls. In Grasshopper, this was essential for building logic and filters.

The upcoming deconstruction feature for the Next-Gen Grasshopper beta release you mentioned sounds great. Just to clarify: will it allow us to access those kinds of geometries, assuming they’re present on the parent object?

I saw you mentioned these are already published from Revit but not yet from Archicad. From my side, having access to base curves and boundaries in Archicad would be hugely valuable. If adding something like a baseCurve or boundary field is possible, it would really help maintain the power and flexibility Speckle brings to BIM workflows.

Thanks again for the great work !