BlenderBIM Experimental IFC Git add-on

brunopostle

As everyone knows by now, BlenderBIM is a Free and Open Source tool for working with Native IFC files. IFC is the open standard for BIM models, and Native IFC is a technique for working with IFC directly as first class data rather than as an exported dump of a proprietary database.

Native IFC applications keep data in place, only regenerating parts of the model that have been changed by the author. This has lots of advantages, among them are that it is easy to compare two versions of the same model and tell exactly what has changed between them, it also allows for very efficient storage and transmission of just the changes between versions.

Git is universal in the IT industry for distributed version control. Git is robust and secure, it can store large amounts of data, tagging and retrieving versions in an instant, branching and sharing data is reliable, every revision has a unique cryptographic hash allowing full verification and traceability.

Native IFC and Git are a perfect fit, the combination already works well, but existing GUI tools are designed for
source-code management not BIM workflows.

IFC Git is a new add-on that lets you manage your BIM data in a local Git repository without leaving BlenderBIM. Instead of just saving a file, with IFC Git you can create revisions with descriptions. These revisions are browsable and retrievable, changes between two revisions can be visualised in 3D. Any revision can be forked, creating a branch for developing options or playing with designs. IFC Git even has an experimental tool to merge branches using an IFC specific three-way merge for conflict resolution.

This short screencast shows all these IFC Git features in action:

Ace

Amazing amazing amazing going to try this out today!

Coen

This is absolutely amazing, this just proves open-source is the way forwards.

brunopostle

Note this isn't a single download install, yet. You will need git, GitPython and ifcmerge. I think something like this will work on Windows:

Install git

Using the cmd.exe command-line (hit the Windows key and type 'cmd'):

winget install --id Git.Git -e --source winget

This should install git, close cmd.exe and start it up again, now git should be in your %PATH%.

Install ifcmerge

Download and unzip the ifcmerge.exe file:

https://github.com/brunopostle/ifcmerge/releases/tag/2022-06-20

...and put it somewhere in your %PATH%, like this folder here just created by installing git:

C:\Users\John Doe\AppData\Local\Programs\Git\cmd

Install GitPython in blender

I have no idea if this is the recommended technique, in the blender python console:

import pip
pip.main(["install", "GitPython"])

Install IFC Git

Download the single ifc-git.py file and install using blender Edit > Preferences > Add-ons:

https://raw.githubusercontent.com/brunopostle/ifc-git/main/ifc-git.py

brunopostle

..also don't expect too much from the branch merging. BlenderBIM is not quite as Native IFC as it could be yet, and conflict resolution in a three-way merge is asymmetrical, so the order that you merge multiple branches is important.

bernd

how about usage from python only?

brunopostle

@bernd GitPython is a partial git implementation, mostly it interacts with the git database directly, but for some stuff it forks out the git binary.

The ifcmerge.exe windows executable is actually a compiled perl script that doesn't have any library dependecies. I'm sure it can be rewritten in python, contributions welcome, you need to be good with regular expressions ;)

theoryshaw

works!
A small addition...

...and put it somewhere in your `%PATH%`.  The path might look like (1) of the following. 

- `C:\Users\John Doe\AppData\Local\Programs\Git\cmd`
- `C:\Program Files\Git\cmd\`
- If you don't know the path, use the command `where git.exe` in the `cmd.exe`.  

Coen

Could this be used for collaborating on a remote git server as well?

brunopostle

@Coen yes! but at the moment there are no remote commands (fetch, remote, pull, push, clone etc..) in the GUI (contributions welcome).

This shouldn't stop you from using an external tool (a Git GUI or even the command-line Git) for this stuff, no need to restart blender. ie, if you clone a remote repository the 'origin' will be set in the repository, so you can push any locally committed work to the 'origin'. You can add a remote for somebody else's version of the same project, and fetching this will create a branch in your local repository that you can browse/diff/merge within the blender add-on just like any other local branch.

Moult

I've recently been using this website to help people deal with how %PATH% works, maybe someone might find it useful: https://superuser.com/questions/284342/what-are-path-and-other-environment-variables-and-how-can-i-set-or-use-them

Bimlooser

Really useful. I have a question: "how are data changes handled: they are only highlighted or I can see details somewhere?"

brunopostle

@Bimlooser at the moment all it does is highlight blender 3d objects where the corresponding IFC element has changed or is new.

It isn't looking any deeper, so in practice the object will only be highlighted if its name, location, or representation etc.. is different ie. it is literally only looking to see if the entity text has changed. As it happens, blenderbim will always create a new representation or location entity whenever there is a change, so this works, for now. It wouldn't be hard to look a bit deeper and check to see if entities that reference or are referenced by the 3d element have changed, and this would give a bit more coverage.

Regarding pure non-3d data, the add-on knows which entities are changed/added/removed, but there is no obvious way to show this in blenderbim because the data is presented in different parts of the gui (if at all). We could offer a list of entities and browse them by id in the IFC debug panel, but that would be no fun :(

Bimlooser

Thanks. No matter. The add-on rocks

brunopostle

A quick update: the add-on has had a number of fixes and enhancements in the last week. I've also added some items to the github tracker for things that need some more thought, basically I'm asking for input on: tagging, visual diffs, remote operations, and merge conflicts.

tlang

@brunopostle love this project. Some questions: Regarding merge assymetry as explained on github, would it be helpful to first assign GUID's instead of relying on instable STEP-ID's? And, regarding attribute change lists, changed attributes might be highlighted as in Tekla Structure change managment? ()?

brunopostle

@tlang Using GUIDs instead of step IDs ought to work, but it would need a lot of heuristics and assumptions to track down and compare non-rooted entities (which don't have GUIDs). BlenderBIM preserves step IDs for other good reasons, and this add-on is exploring the potential of this new Native IFC world where we don't have to deal with IFCs as data dumps from proprietary databases. For instance, the function that identifies all the added/modifed/deleted entities between two git versions of a Native IFC model is 25 lines of code and runs in milliseconds, this functionality would be a lot more complex and maybe even not fully resolvable if it had to work with GUIDs only.

Having said that, you are right, a tool that did this job using GUIDs would help with merging IFCs where step IDs had already been rewritten to accomodate a Native IFC three-way-merge conflict resolution.

Another way to avoid asymmetrical merge resolution (and I'll add this to the github issue) would be for authors to pre-agree working ranges of step IDs - currently BlenderBIM allocates new step IDs based on the highest existing number, but if my BlenderBIM was configured to only create entities in the range 10000001, 10000002, etc.. and your BlenderBIM was configured for 20000001, 20000002 etc.. then the asymmetrical nature of the merge conflict wouldn't apply, since there would be no need to rewrite local IDs to make space.

The Tekla demonstration is very impressive. We should have a list of added/modified/deleted entities, where selecting an element in the list would select the equivalent object in the 3d vew and would therefore display info for the element in Blender Object Properties. This wouldn't help for entities that don't have a 3d object representation, which is the point I was trying to make (and which Tekla have conveniently ignored) - What if the only thing that has changed between the two versions is a material pset? the material doesn't appear as a 3d object and the material psets are actually under Blender Material Properties, not Object Properties - Access to non-object entities such as materials is scattered across the BlenderBIM GUI for logical reasons.

This doesn't get prettier, if you are viewing a material pset changeset, you want to be able to show all the objects, layersets and profilesets that use this material.

cvillagrasa

This thing of the non-rooted entities in IFC has always bothered me. Wouldn't it be possible to bypass it somehow? May the IFC gods forgive me for these thoughts, but what about a certain IfcPropertySet per project, with a bunch of IfcPropertySingleValue, whose Name happens to be a GUID, and its Specification a Step ID. And then having one of such properties per non-rooted entity, thus linking all of them to a GUID?

Well, the filesize could become a problem I guess, as well as additions/deletions outside of software taking this into account (assuming that external software exports all entities which were imported, which perhaps is a lot to assume). Ahh, too dificult. When will IFC have all rooted entities? IFC5?

brunopostle

@cvillagrasa I don't know if proprietary BIM tools would be able to attach GUIDs to everything, in IFC even a single coordinate can be a separate entity. It would be as easy to ask them to preserve step IDs.

Maybe you could write a tool that traverses the graph of a traditionally exported IFC, and maps all the non-rooted entities to equivalent entities in a previously exported IFC, this would bring all the benefits of native IFC.

cvillagrasa

@brunopostle said:
@cvillagrasa I don't know if proprietary BIM tools would be able to attach GUIDs to everything, in IFC even a single coordinate can be a separate entity. It would be as easy to ask them to preserve step IDs.

Sure, proprietary software is not going to follow any possible community originated IFC unofficial approach. I was more thinking on a workflow between open source and proprietary software, where at each loading in the open source one, new non-rooted entities were tagged on that artificial pset, and properties of that pset corresponding to deleted non-rooted entities were deleted accordingly.

That would allow to keep track of every entity, but it very well could be that proprietary tools ingested that invented pset, but never exported it out again. Maybe that risk could be minimized by instancing a dummy IfcTypeObject and referencing the pset from it. But yes, the alternative of preserving Step IDs may be easier to achieve in practice.

I really don't particularly enjoy neither of them... the elephant in the room is that every entity should be rooted (in my view). Because an IfcDirection from an IfcAxis2Placement can refer to the global X or the global Z, and there's no need to have it repeated endlessly for every new IfcRepresentationMap. Or in similar ways, individual entities like IfcCartesianPoint can almost always have meaning by themselves and hence be subject to be referenced and tracked.

@brunopostle said:
Maybe you could write a tool that traverses the graph of a traditionally exported IFC, and maps all the non-rooted entities to equivalent entities in a previously exported IFC, this would bring all the benefits of native IFC.

I guess that rabbit hole leads to the Weisfeiler-Lehman isomorphism test and so on. I guess that the downside is that it could really last for a while in large files.

theoryshaw

If you'd like to help fund the development behind Bruno's GIT/IFC Interface in BlenderBIM.
https://opencollective.com/osarch/projects/git_ifc

brunopostle

@theoryshaw said:
If you'd like to help fund the development behind Bruno's GIT/IFC Interface in BlenderBIM.
https://opencollective.com/osarch/projects/git_ifc

Note also that this funding matched by osarch is available to anyone who wants to work on these IFC/Git tools, this could be porting the add-on to be part of BlenderBIM, any of the items on the ifc-git tracker, FreeCAD integration, a web app for interacting with IFC/Git repositories, etc.. etc..