My team is currently looking at Speckle as a potential platform for a project related to timber construction.
Specifically, we’ve been looking at Speckle Kits. Being able to create a collection of custom types and their converters and then use them across the wide variety of existing Speckle connectors seems like a very attractive idea and could potentially be a good fit for our needs.
As I’m trying stuff out, I’ve noticed that I’m using the speckle-sharp which is deprecated. Looking at the Speckle3.0 codebase, I was not able to find any references to the Kit system.
Are Kits something that’s still going to exist in Speckle in the future? Has it been moved elsewhere or perhaps dropped completely?
Hey @chenkasirer! Welcome. Kits have been deprecated, as we haven’t really seen anyone pick them up in their original form. They were introducing a lot of complexity in our codebase that was difficult to maintain, and it was working against speckle rather than for speckle.
If you need to create custom object models, we’d love to know more: where to and wherefrom? There are easier ways to do so without the whole shebang of kits, especially if you’re using grasshopper.
To expand a bit on what Dimitrie mentioned (He snuck in stealthily as I was typing) kits introduced a lot of complexity without seeing actual adoption outside of a few Grasshopper-only instances to unify seed objects for computationalists, so they’ve been phased out. That said, the fundamental structure of the Speckle object model remains unchanged in Next Gen.
TL;DR:
Kits are no longer a thing.
Custom base objects are fully supported as strongly typed or dynamic objects with properties.
Speckle 3.0 retains flexible data modeling while improving developer experience.
What’s new is a refined set of top-tier object classes designed to provide a better developer experience, particularly for analysis tools, automation scripts, and new connectors. These are included in speckle-sharp-sdk.
For example:
NavisworksObject : DataObject
RhinoObject : DataObject
This structure ensures that business intelligence and data extraction workflows can rely on a consistent pattern where:
There’s a properties dictionary (Dictionary<string, Any>) for metadata.
A geometry definition follows Speckle’s established model.
In the future, we might return to a structured schema similar to the original object Kits, where we have, for example:
RevitWall : RevitObject : DataObject
And possibly something like SpeckleWall as a generic schema layer.
We’re taking a more deliberate approach to defining these classes, rather than auto-generating them at scale like in v2.
If you’re exploring how to define custom objects for your timber construction workflows, it’d be great to hear more about your specific use case; where the data comes from and how you want to use it. I’m happy to help you figure out the best approach!
So, if I get it right, there’s are no more generic Speckle representations for specific entity types (such as walls, beams etc.) but rather a specific base type per host, where Speckle geometry + dict based metadata live?
I’d love to hear more about your new approach regarding moving between native and Speckle types. Is there already some kind of a documentation covering this? (I guess some of the things currently on Introduction | Speckle Docs are no longer relevant). Also, may I ask what’s the timeline for Speckle3?
To give more context, we have been developing COMPAS Timber where we define timber related entities semantically and we wanted to explore the possibility of transporting our schema across different CADs using Speckle.
With Kits gone, assuming we define our own custom base objects, what would be a way to make it available over the available connectors? I would love to hear any thoughts you have on that.
So, if I get it right, there are no more generic Speckle representations for specific entity types (such as walls, beams, etc.), but rather a specific base type per host, where Speckle geometry + dict-based metadata live?
Right now, yes. DataObject inherits from the OG Base, which remains a dynamic object, meaning arbitrary properties can still exist outside the structured pattern. However, for user and developer friendliness, we generally recommend keeping things structured within the new top-tier object hierarchy.
This is where future specialization comes in.
For example, let’s say there’s a Wall schema similar to how v2 had SpeckleWall. If we define:
RevitWall inheriting from both RevitObject and SpeckleWall,
We get baseline consistency and strongly-typed classes.
That’s not just theoretical—it’s an extrapolation of where things are heading. I hope that makes sense!
Moving Between Native and Speckle Types
For sending and receiving, applications that support Multiplayer Modelling (as @clrkng has described elsewhere) will provide the best experience. However, the aim is that as many applications as possible will understand DataObjects—even if they don’t natively support something like a RevitInclinedCurvedWall.
In practice, this means:
All Next Gen connectors will publish DataObjects.
Where necessary, they’ll publish more nuanced versions per application.
On receive:
Some applications will use them contextually for coordination and collaboration.
A few can translate a subset or superset of typed objects when there’s a common understanding (think Multiplayer Modelling workflows).
I don’t have a concrete timeline for you yet, but restructuring the zoo of object classes from v2 into something sustainable and scalable has been a necessary (and occasionally painful!) effort.
Hope that helps! Let me know if anything needs further clarification.
We have another line of comms for the COMPAS project, but thank you for asking this out in the open.