Seems they’ve managed to achieve what AEC will take a long time to catch up to.
web-based, Version Controlled, Change based multi-player collaboration, Kits-of-Parts, Intent-Based vs. geometric only modelling, etc…
I am wondering why mechanical engineering is so far ahead in these things.
Anyways, is anyone aware of any of the details in their data-model? How they achieve meaningful version control?
It seems to me that the big question when it comes to version control is how you structure your data so that semantically unrelated changes lead to unrelated file change (where the unrelatedness has to be easy to determine, i.e. line-based, tree-based, …).
Bear in mind that may be a question better aimed at OnShape.
As far as I understand it, Onshape versioning & branching is even more closely aligned to Git than Speckle is.
A version is simply a defined snapshot of the totality of the model at that time. Essentially, read only. It doesn’t need any special Object model to achieve this. The WIP multiplayer model between versions is not part of the version control (ish) Between commits the Model is in sketch mode and multiplayer editing happens in this mode.
Also, while there may be an in memory representation of the objects, the OnShape format is the instruction set to generate the current model.
A branch uses a specific version as a jumping off point for a new model.
All that said I’m not aware of the internal data structure of the OnShape object model just how (i think) versioning is handled.
Beyond that I couldn’t quite work out what your second question was.
thanks for your insights into the OnShape model.
Right, The Event-based architecture (and data-model, i.e. an instruction set) makes sense for CAD-like applications.
The second question / note was on how to achieve version control to a finer grain than object-level. I.e. being able to have one person change the height of a wall and the other person change the color / material / … without the two changes conflicting.
What the ifc-merge uses is the natural structural of IFC into shapes / properties etc. in a line-based STEP file in order to allow such a merge behaviour. I found that quite cool.
Has anyone looked into semantic merging on top of Speckle? (depends obviously on the objects you’re updating and their object model) .
In short, no. And from your last point you have already answered it As Speckle allows for many multiple tools with many different interpretations of what data objects might contain (even when representing the same elements, and even reliable IDs!), the level of fidelity available in your described native-IFC-only world would be difficult to achieve.
More generally, your question raises a discussion around Data Provenance and Data Lineage that could be had. In the first instance elemental and in the second, as you describe, at a property level. In essence, the Speckle dataset allows for after-the-fact interrogation for both - but it would require an intensive post-change data analysis. (As I type this, it is food for thought to demonstrate later)
So, thanks for the question. Keep the interest alive!
As Speckle allows for many multiple tools with many different interpretations of what data objects might contain (even when representing the same elements, and even reliable IDs!), the level of fidelity available in your described native-IFC-only world would be difficult to achieve.