I tried to make a minimalistic proof-of-concept for a Speckle workflow. Goal was to confirm that I can push elements into Speckle from one SW, receive and edit them elsewhere and then update the original. Instead of updating, I ended up with a duplicate instance at the end.
The process went like this:
Create beam HEA 160 in Revit 2024. Dimension in floor plan. Send to a Speckle stream.
Receive beam in Revit 2025. Change type to HEA240. Send back to same stream.
Receive beam back in Revit 2024. I expected the type of the existing beam to change which would be confirmed by the width dimension adjusting accordingly. Instead, a new beam is created.
As far as I can understand, I got all the settings correct to get the desired result. Unfortunately, it did not work out. What am I doing / expecting wrong?
While Speckle supports doing ping pong between some apps, it wasn’t designed to work that way.
Where Speckle does a really good job is data extraction and specific A>B workflows (leaving aside the web collaboration & automate features for now).
In your proof of concept the problem is that when the beam is received in Revit 2025, it gets created with a new ID set by Revit. When you send this back into 2024, the IDs don’t match anymore and the update feature thinks it’s a new beam.
What you can do instead, is keep sending updates from 2024 into 2025, and the update functionality should keep working that way. Speckle doesn’t aim to keep track of elements and all their transofmations globally, we believe this is not very feasible nor the best aproach.
What specific workflow were you hoping Speckle could solve for you? Let me know if you have other questions!
thanks for the reply. I understand now that things are the way they are by design. Alas, it’s a bit disappointing. My actual irl workflow is as folows:
Architect works on his own, creates a rudimentary structural model in ArchiCAD.
We come in, get data (their structural model) via a bidirectional interface (thought this could be Speckle). We make adjustments - edit/add/remove elements. We send data back.
Architect receives data - their structural model is updated.
After the initial pingpong the data will actually continue to flow from us to the Architect only, so it still probably makes sense to use Speckle. I just think it would be cleaner/smoother if we could go both ways as this would make the workflow homogeneous. As it is, the beginning is distinct from the rest.
This whole idea started as model conversion from ArchiCAD to Revit, which we previously did thru ifc, but weren’t quite satisfied with. Basically, Revit is poor at importing beam elements from ifc. Instead, we use structural analysis software that has a direct link to Revit to get the beams, but that’s like scratching your right ear with your left hand. I thought Speckle could solve this, and more. My means of testing are limited, though, because I don’t have ArchiCAD. I still want to know as much as possible before trying to get the architects onboard, though.
I’ve been using Speckle for some time mainly as means of sharing basic geometry between Rhino-Revit-AutoCAD, because it’s significantly more convenient than file-based data transfer (no clutter, reliable coordinate system management). I realized this was a niche usecase, but for some reason I thought that bi-directional data exchange was the key concept, maybe because I saw Speckle being compared to git in some article I can’t specifically recall anymore. Why is it not feasible? I imagine the data structure would become too unpredictable if you allowed the same data to be changed from any software? So does each stream actually have exactly one source and it gets reset if data is sent from somewhere else? That would be consistent with what happened in my initial example.
This is good feedback for us! We can definitely do better at explaining how connectivity works in Speckle.
Using the current nomenclature, a project (previously stream) is a collection of models.
A model (previosuly branch) has one or multiple versions (previously commits).
Speckle is designed to be forward-only, so every time you publish a new version, it’s added to the model history, without affecting any previously published versions.
This means that effectively, a model can have as many sources as you want, it’s up to you to keep any sort of consistency, if required. Our connectors, when publishing to Speckle do the hard work of diffing data and only uploading what is new or changed, this way we optimize storage in the server and at the same time each version published represents the model in its entirety and is not dependent from previous versions (like git).
Now let’s look at the opposite mechanism, every time you load a version inside a host application (Revit, AutoCAD etc) the connector does its best to recreate geometry and metadata, but most times there is some sort of data loss because of how incompatible tools are (think of BIM > CAD). As a consequence, Speckle doesn’t try to centrally manage each object, but essentially when you receive data it creates NEW objects. For this reason ping pong like Revit > AutoCAD > Revit is not supported.
between some apps, it wasn’t designed to work that way.