[IFC] Multi user editing

This discussion was created from comments split from: Spoted Academic Papers.

Comments

  • @lukas said:
    https://publications.cms.bgu.tum.de/2022_Esser_advei.pdf or https://publications.cms.bgu.tum.de/2022_Esser_advei.pdf
    Graph-based version control for asynchronous BIM collaboration
    Sebastian Esser, Simon Vilgertshofer , André Borrmann, TU _ München
    Asynchronous collaboration, object-based version control, BIM Level 3, Common Data Environment

    You seen this @brunopostle @theoryshaw ? They might be worth reaching out to for multi editor work.

  • @duncan I think they are doing this the hard way.

    The assumption is that all BIM software has their own internal proprietary data model and that IFC is used to dump a version of this in whatever random serialised order. In this situation the only hope of matching data between two different files is to start with the GUIDs of rooted elements and trace the web of references in the file to figure out where the rest of the entities (that inexplicably don't have GUIDs) belong. This is necessarily slow, relies on heuristics, and has to cope with the same data structure being re-serialised using possibly a completely different set of entities.

    Now we have Native IFC software (like blenderbim) that blows these assumptions away - when you edit a file in blenderbim it is easy to identify exactly which entities have been modified, deleted or added - no need for graph analysis or heuristics. A three-way merge of Native IFC file versions is completely deterministic.

    I think that instead of trying to get these old assumptions to work, we should just advocate Native IFC. If the big proprietary platforms can't or won't adopt Native IFC then that is their problem. Blenderbim is Native IFC because IfcOpenShell made it possible. I have no idea if IFC.js does Native IFC, we ought to find out because people are already creating BIM applications in IFC.js.

    Nigel
  • @brunopostle said:
    [...] I have no idea if IFC.js does Native IFC, we ought to find out because people are already creating BIM applications in IFC.js.

    Yeah, it's worth asking them. Somewhat related, I read on Discord that they are now supporting a hybrid schema between IFC2x3 and IFC4, so maybe the writing of IFC files from IFC.js BIM applications is still in its early days. But yeah, if Express IDs are kept upon dumping to disk, ifcmerge should work well in the meantime, regardless of the specific version of the schema.

  • @agviegas can you comment here?

  • Hi! Sorry for the late reply, it has been a busy month. As you might know, until now IFC.js has been focused more on reading than on writing (although it's capable of editing any data on any IFC). However, we are now finishing a first version of an IFCExporter (that allows creating IFCs from Three.js scenes) and the idea is to add more layers of abstraction to make this much easier.

    The way IFC.js handles IFC data is to store it as a buffer in memory, using the Express IDs as identifiers (because not everything has a GUID). It works like an in-memory database: you can make queries to the buffer (which return a JSON object) or pass a JSON object to override / add new data. Regarding the schema, right now we use IFC2x3 with some IFC4, but we will start supporting separate versions in the future.

    I think that this should make multi-user work relatively easy, because if we rely on technology like socket.io (we are making a tutorial on this right now), whenever a user edits the IFC file, we could update the data buffer of all the users in real-time.

    cvillagrasa
  • @agviegas multi-user simultaneous access would be awesome.

    It sounds like IFC.js is already doing Native IFC in a way that allows three-way merging and easy change tracking i.e preserving express IDs, editing attributes in-place, and not reusing IDs from deleted entities.

    A project that we ought to consider sponsoring would be a web-interface to an IFC git repository. This would be able to display arbitrary versions, show changes between commits/tags, show changelogs/blame, and (given how straightforward it is) perform three-way merges between branches, all in the browser.

    theoryshawbasweinbruno_perdigaocvillagrasa
  • A project that we ought to consider sponsoring would be a web-interface to an IFC git repository. This would be able to display arbitrary versions, show changes between commits/tags, show changelogs/blame, and (given how straightforward it is) perform three-way merges between branches, all in the browser.

    Would be awesome. Could we play off of IFC Merge?... which I think has a lot of potential!

  • @theoryshaw yes, as far as I can tell it should be easy to replicate the three-way merge functionality of ifcmerge using web-ifc (the part of IFC.js that handles STEP files). Extracting modified/added/deleted entities (for displaying git revisions) can be done the same way.

    theoryshaw
Sign In or Register to comment.