If you're reading this, we've just migrated servers! If anything looks broken please email dion@thinkmoult.com :)

Brainstorm on projects we'd like to be able to fund

2»

Comments

  • edited September 2022

    IFC git interface

    [I mentioned this at the meeting last week and realised it wasn't written down anywhere. This is a proposal for somebody else to pick up]

    Firstly, I'm writing this is in the context of Native IFC: blenderbim and other applications read and write IFC files without an import/export process, this behaviour makes storing IFC files in git repositories extremely attractive, it brings efficient storage, full versioning, three-way merging, and collaboration using git-forges like github as a CDE. Read this Native IFC whitepaper for all the gory details.

    Git needs some additional tools to make this experience great, currently if you click on an IFC file in github, your web-browser offers to download the file rather than opening it for viewing (is there a blender command-line option that can be used to associate IFC files with blender? so you can just double-click an IFC file, or click a link, and have it open in blenderbim? that would be nice, I'll add this to the tracker done..).

    An obvious thing you should be able to do with IFC files in online git-repositories is to open them in the browser with IFC.js. There is a proposal somewhere to create an add-on for gitea that would do this. This wouldn't be hard, but one of the advantages of putting BIM data in git is that information can be federated over different services, so what is needed is an IFC.js web-application (or module that all IFC.js applications can use) that can access any online git repository. There are other options, but isomorphic-git is a complete git client written in javascript, it can clone all or part repositories in your browser data store, it seems to be able to do most git stuff that we need. So here are some things that can be done, in order of easiness:

    1. An application where you provide the address of a git repository (either networked or local), the repository is cloned, available IFC files are listed somehow, selecting one opens the HEAD revision as a 3D model.
    2. The same as (1), but with a scrollable changelog, selecting an item from the changelog displays that revision of the model.
    3. Visual diff between revisions. This will only work with Native IFC files, as tracking STEP IDs is easy (see whitepaper above). A visual diff can't be achieved with a single static model, it needs to work something like this: two views are required, a 'before' and 'after', and it should be possible to toggle between them without changing the 3d viewpoint. The 'before' view would show unchanged elements with no colour, modified elements with a colour (green or something), and deleted elements with another colour (red). The 'after' view would show unchanged elements with no colour, modified elements using the same colour as before (green), and added elements with another colour (blue or something). The two views are necessary because a modified element may have moved between revisions, and you can't show this in a static scene. Inspecting changes in non-graphical elements is a whole other problem, a lot of work.
    4. Visual diff between revisions in different repositories.
    5. Three-way merges between branches. Initially this could just indicate if a three-way merge is possible without conflicts. A three-way merge between Native IFC forks is straightforward and deterministic (again, see whitepaper above).

    All the above is needed as an IFC.js web-application, or better as a module that can be plugged-in to any IFC.js application. But, it could also be usefully added into blenderbim, along with a basic commit functionality (creating branches, pushing, cloning etc.. may be better done with a separate git client).

    NigeltheoryshawtlangArv
  • @brunopostle hopefully this will become an official proposal when we get that process up and running :-)

    brunopostleNigeltheoryshaw
  • @duncan said:
    @brunopostle hopefully this will become an official proposal when we get that process up and running :-)

    agreed!
    @brunopostle are you open to boiling this down into 200words and posting here?

    duncan
  • edited January 2023

    @brunopostle @Moult can one of you find a link to that guy on LinkedIn who is working on a similar idea of making incremental edit/merges with IFC data? I can't find it or remember what he called his idea.

    also @geometrygym has this 2017 GitIFCPrototype repository which may be relevant and offer ideas for implementation.

    I have added some links on this project to our wiki https://wiki.osarch.org/index.php?title=IFC_-_Industry_Foundation_Classes#See_also

Sign In or Register to comment.