Could this add-on also be used to make a different view between a structural and architectural model? Could you also use feature tags to swap between different design variants?
@Coen swapping visibility of elements depending on classification, phasing etc.. is already possible in blenderbim.
If you have design variants in separate Git branches then you can use this add-on to swap between them without changing the camera viewpoint, but note that it is reloading the whole project each time, so it isn't going to be very fast.
@theoryshaw this is a perfect example of the asymmetry in the conflict resolution. In order to merge a remote branch, any local step IDs that conflict need to be rewritten to make space, basically anything added after the fork.
ifcmerge isn't just doing a three-way merge, it is resolving a conflict in a three-way merge.
So you can merge ryan_branch into master, but this involves rewriting recent history in the master branch, which would be fine except bpo_branch was forked during this recent history - bpo_branch is now an orphan and can never be merged :(
Solution would be to merge bpo_branch into master, then ryan_branch into master, this isn't a problem because you are not rewriting any history that ryan_branch cares about.
Similarly, you could merge bpo_branch into ryan_branch, then merge ryan_branch into master.
I don't want people to have to keep track of this sort of thing, Git is hard enough as it is. We need some kind of warning that merging a particular branch will orphan some other branch.
@theoryshaw now we don't have to rewrite the local data to accommodate the remote data - just switch the second and third arguments in the ifcmerge command and it will rewrite the remote and keep the local pristine, then you can merge as many forks into master as you like in any order.
One problem with this is that it will then orphan these forks, they will have to be abandoned once merged - which is probably fine if that is how you want to run your project.
But the main problem with doing this is that it is more polite to rewrite your local data when doing collaboration. If you are collaborating with someone else you want to be able to merge their fork, then they can merge yours etc.. in this circumstance you need to treat the other person's data as sacrosanct.
@theoryshaw it is not so cool, a normal software three-way-merge is symmetrical - but you have no idea if it has introduced bugs or if the software will even run. An ifcmerge three-way-merge is asymmetrical, which is a pain, but at least the resulting file will be a valid IFC (there may be physical clashes or doors into nowhere, but this is why we do coordination).
And this note in the BBim update thread: https://community.osarch.org/discussion/26/blenderbim-add-on-new-release#latest
FC Git version control integration
Incredible work by Bruno Postle and Bruno Perdigao have led to an integration with the IFC Git project. This allows you to track changes on an IFC project, merge changes from multiple users, and jump to points in the project change history.
You can now manage your BIM data in a local Git repository without leaving the BlenderBIM Add-on. Instead of just saving a file, 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. There is an experimental tool to merge branches using an IFC specific three-way merge for conflict resolution.
And the fact that this little drop down appeared in BBim a few iterations ago:
Am I right in assuming that the IFCGit experimental addon has been fully incorporated into BlenderBim? Without the need for a separate install?
Yes, thanks to help from @bruno_perdigao add-on has been moved into BlenderBIM, so if you have the old add-on installed you should uninstall it.
However we still have no way of shipping the git executable with BlenderBIM, so you do need to install this separately. On a Linux system you probably don't have to do anything, but on Windows you need to download git ( @Ace you don't need to do anything, you already have it). Similarly, if you want to use the experimental merge functionality, you need ifcmerge in your PATH, windows executable downloadable from here: https://github.com/brunopostle/ifcmerge/releases/tag/2022-06-20
@brunopostle said:
Yes, thanks to help from @bruno_perdigao add-on has been moved into BlenderBIM, so if you have the old add-on installed you should uninstall it.
However we still have no way of shipping the git executable with BlenderBIM, so you do need to install this separately. On a Linux system you probably don't have to do anything, but on Windows you need to download git ( @Ace you don't need to do anything, you already have it). Similarly, if you want to use the experimental merge functionality, you need ifcmerge in your PATH, windows executable downloadable from here: https://github.com/brunopostle/ifcmerge/releases/tag/2022-06-20
The Git module now has some remote tools, so you can now clone a repository, fetch and merge branches, and push (if you have permissions).
Try it out: open blender, in the IFC Git panel, enter https://github.com/brunopostle/ifc-test.git as a URL, select an empty local folder, then Clone repository will download and open this project in one click.
In theory, could you store for example an IfcWindow in a git submodule and use the submodule as an IfcProjectLibrary in your main repository (where the acutal IfcProject is)?
@Coen You could do this (the Git panel doesn't know anything about submodules, but only because I hadn't thought of it). The problem is that IFC has no concept of xrefs, so any window type has to be imported into the project file and used from there.
You could definitely use submodules for storing heavy files such as laser surveys etc.. that are not of general interest to all project participants.
I would like to show IFC git to my colleagues, they are developers, product managers, testers
But I am thinking of a nice use-case scenario which shows all the possibilities on collaborating with an IFC through git source control.
Does anyone have a cool idea?
For me IfcGit has a few distinct advantages:
1.) Versioning (even if you use it solo, the versioning is super useful)
2.) Design alternatives with branches (Being able to explore different ideas of the design and return to the old one if necessary)
3.) Simultaneous working with others decentrally through GIT with branches
4.) Merging different branches together
5.) a written record of commits / changes with who authored them
These are clear and simple winners. A million others regarding comparisons to BIM 360 and similar stuff, we once tried to do a central revit model through google drive, it worked but it was waaaay too weird.
So from my description:
an example project that has 2 design versions, that you need to load an older version authored by another person in another country, (check authoring) and return to a version before the roof was changed or something, then merge a branch with a neighbouring building modelled ,
A kinda 5 min demonstration that demos all the best stuff , that would be my approach
The fact that it only works with IFC is a kinda selling point aswell as the files will always be super small compared to a revit file or something
@Coen a lot of the features are obscure and difficult to show, Git is conceptually hard, I've been using since forever, and CVS and Svn and Hg before that, and it still makes my head hurt.
Though the git clone URL above is very impressive, here it downloads the entire repository history, reconstructs the most recent revision, and loads it in blenderbim, all in about 5 seconds. You can then browse the existing history, make a change, commit it, visualise diffs, and open any past revision quickly and easily.
What I would like to see is: an IFC.js viewer of Git repositories, so you can push a change and see it immediately in a browser - this won't be a difficult project. It would also be fun to push changes from blenderbim, fetch them in freecad, make changes and push them back. Merging two branches that have diverged in different software would be a knockout demonstration, but we are not there yet. Commit hooks that publish drawing sets, do IDS checking etc.. would be something. There is still 'bounty' money for any of these, it's only a few hundred dollars, but it isn't nothing.
Like a release branch which is able to produce drawing sets through a release pipeline trigger for example?
Yes, drawings could be generated automatically server-side every time you tag a revision and push it to the repository - no need to collect PDFs in a zip file to upload somewhere, it would be already done, dated, attributed and downloadable.
Comments
Thanks Bruno, added issue here: https://github.com/IfcOpenShell/IfcOpenShell/issues/2971
Could this add-on also be used to make a different view between a structural and architectural model? Could you also use feature tags to swap between different design variants?
@Coen swapping visibility of elements depending on classification, phasing etc.. is already possible in blenderbim.
If you have design variants in separate Git branches then you can use this add-on to swap between them without changing the camera viewpoint, but note that it is reloading the whole project each time, so it isn't going to be very fast.
From https://gitlab.com/openingdesign/clothing-boutique-20230412-for-testing
I was able to merge
ryan_branchinto themaster, but was not able to getbpo_branchto merge intomasterI only added a few annotations in
ryan_branch, so i feel it should merge.If you look at the
Merged branch: ryan_branchcommit...https://gitlab.com/openingdesign/clothing-boutique-20230412-for-testing/-/commit/64f48c7b11b046d652dc5540bd6954ad26f64eac#d225491e139055cdedbe451486d6c3e1b12500b1
You can see a lot of ifcwalls changed, but I feel they shouldn't have, as the
ryan_branchdid not change these.@theoryshaw this is a perfect example of the asymmetry in the conflict resolution. In order to merge a remote branch, any local step IDs that conflict need to be rewritten to make space, basically anything added after the fork.
ifcmerge isn't just doing a three-way merge, it is resolving a conflict in a three-way merge.
So you can merge ryan_branch into master, but this involves rewriting recent history in the master branch, which would be fine except bpo_branch was forked during this recent history - bpo_branch is now an orphan and can never be merged :(
Solution would be to merge bpo_branch into master, then ryan_branch into master, this isn't a problem because you are not rewriting any history that ryan_branch cares about.
Similarly, you could merge bpo_branch into ryan_branch, then merge ryan_branch into master.
I don't want people to have to keep track of this sort of thing, Git is hard enough as it is. We need some kind of warning that merging a particular branch will orphan some other branch.
cool, cool... i think i get it. Good to know!
@theoryshaw now we don't have to rewrite the local data to accommodate the remote data - just switch the second and third arguments in the ifcmerge command and it will rewrite the remote and keep the local pristine, then you can merge as many forks into master as you like in any order.
One problem with this is that it will then orphan these forks, they will have to be abandoned once merged - which is probably fine if that is how you want to run your project.
But the main problem with doing this is that it is more polite to rewrite your local data when doing collaboration. If you are collaborating with someone else you want to be able to merge their fork, then they can merge yours etc.. in this circumstance you need to treat the other person's data as sacrosanct.
okay... i think. :)
I'm not sure I understood your last post so closely. :) We'll get there, though!
@theoryshaw it is not so cool, a normal software three-way-merge is symmetrical - but you have no idea if it has introduced bugs or if the software will even run. An ifcmerge three-way-merge is asymmetrical, which is a pain, but at least the resulting file will be a valid IFC (there may be physical clashes or doors into nowhere, but this is why we do coordination).
@brunopostle
From this commit:
https://github.com/IfcOpenShell/IfcOpenShell/commit/cc9777b1e838481f42c5fcedd04ef8a60206f69f
And this note in the BBim update thread:
https://community.osarch.org/discussion/26/blenderbim-add-on-new-release#latest
FC Git version control integration
Incredible work by Bruno Postle and Bruno Perdigao have led to an integration with the IFC Git project. This allows you to track changes on an IFC project, merge changes from multiple users, and jump to points in the project change history.
You can now manage your BIM data in a local Git repository without leaving the BlenderBIM Add-on. Instead of just saving a file, 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. There is an experimental tool to merge branches using an IFC specific three-way merge for conflict resolution.
And the fact that this little drop down appeared in BBim a few iterations ago:
Am I right in assuming that the IFCGit experimental addon has been fully incorporated into BlenderBim? Without the need for a separate install?
Yes, thanks to help from @bruno_perdigao add-on has been moved into BlenderBIM, so if you have the old add-on installed you should uninstall it.
However we still have no way of shipping the git executable with BlenderBIM, so you do need to install this separately. On a Linux system you probably don't have to do anything, but on Windows you need to download git ( @Ace you don't need to do anything, you already have it). Similarly, if you want to use the experimental merge functionality, you need
ifcmergein yourPATH, windows executable downloadable from here: https://github.com/brunopostle/ifcmerge/releases/tag/2022-06-20There is also some basic BlenderBIM Git documentation
Amazing! Thanks @brunopostle and @bruno_perdigao !
@Ace This will be one of your very best videos :)
Hahahha yes it will!
Can't wait, actually, on a serious note this is (to use an annoying and overused cliche but in this case appropriate) a game changer in the BIM world.
@Nigel
I thought you were going to use the word 'disruptive' ?
there are so many stupid cliches and buzz words to choose from
@Nigel
You have think outside the box, it wil be a win-win situation. Keep me in the loop on the IFC git.
Sorry
The Git module now has some remote tools, so you can now clone a repository, fetch and merge branches, and push (if you have permissions).
Try it out: open blender, in the IFC Git panel, enter
https://github.com/brunopostle/ifc-test.gitas a URL, select an empty local folder, then Clone repository will download and open this project in one click.In theory, could you store for example an IfcWindow in a git submodule and use the submodule as an IfcProjectLibrary in your main repository (where the acutal IfcProject is)?
https://git-scm.com/book/en/v2/Git-Tools-Submodules
@Coen You could do this (the Git panel doesn't know anything about submodules, but only because I hadn't thought of it). The problem is that IFC has no concept of xrefs, so any window type has to be imported into the project file and used from there.
You could definitely use submodules for storing heavy files such as laser surveys etc.. that are not of general interest to all project participants.
I would like to show IFC git to my colleagues, they are developers, product managers, testers
But I am thinking of a nice use-case scenario which shows all the possibilities on collaborating with an IFC through git source control.
Does anyone have a cool idea?
For me IfcGit has a few distinct advantages:
1.) Versioning (even if you use it solo, the versioning is super useful)
2.) Design alternatives with branches (Being able to explore different ideas of the design and return to the old one if necessary)
3.) Simultaneous working with others decentrally through GIT with branches
4.) Merging different branches together
5.) a written record of commits / changes with who authored them
These are clear and simple winners. A million others regarding comparisons to BIM 360 and similar stuff, we once tried to do a central revit model through google drive, it worked but it was waaaay too weird.
So from my description:
an example project that has 2 design versions, that you need to load an older version authored by another person in another country, (check authoring) and return to a version before the roof was changed or something, then merge a branch with a neighbouring building modelled ,
A kinda 5 min demonstration that demos all the best stuff , that would be my approach
The fact that it only works with IFC is a kinda selling point aswell as the files will always be super small compared to a revit file or something
@Coen a lot of the features are obscure and difficult to show, Git is conceptually hard, I've been using since forever, and CVS and Svn and Hg before that, and it still makes my head hurt.
Though the git clone URL above is very impressive, here it downloads the entire repository history, reconstructs the most recent revision, and loads it in blenderbim, all in about 5 seconds. You can then browse the existing history, make a change, commit it, visualise diffs, and open any past revision quickly and easily.
What I would like to see is: an IFC.js viewer of Git repositories, so you can push a change and see it immediately in a browser - this won't be a difficult project. It would also be fun to push changes from blenderbim, fetch them in freecad, make changes and push them back. Merging two branches that have diverged in different software would be a knockout demonstration, but we are not there yet. Commit hooks that publish drawing sets, do IDS checking etc.. would be something. There is still 'bounty' money for any of these, it's only a few hundred dollars, but it isn't nothing.
Like a release branch which is able to produce drawing sets through a release pipeline trigger for example?
And a link to the funding page, if anyone is interested in pitching in...
https://opencollective.com/osarch/projects/git_ifc
OSarch matches all individual donations.
Yes, drawings could be generated automatically server-side every time you tag a revision and push it to the repository - no need to collect PDFs in a zip file to upload somewhere, it would be already done, dated, attributed and downloadable.
Is there a very basic tutorial somewhere? I am getting a bit lost switching between branches.