FreeCAD BIM development news 07 September 2017
Hi everybody! Here we are for another monthly report about the development of BIM tools for FreeCAD, our favorite open-source 3D CAD modeling platform. The coding I am doing for FreeCAD is now more and more heavily supported and funded by many of you via my Patreon page, thanks once more to everybody who contributes to this, it is incredibly motivating. We won't stop until we get a proper open-source, multiplatform BIM modeler!
As expected in last month report, this month I had very little time to dedicate to FreeCAD coding itself, because our WikiLab project construction started, and it swallowed almost all of my time. I am saving the Patreon money of this month, though, and as soon as the WikiLab is finished (about two more weeks to go) and I'm back from the GSOC mentors meeting (see below), I'll be back at FreeCAD coding with full dedication and twice the money to spend (and I really miss coding already).
This time spent on the WikiLab is not lost at all for FreeCAD, though. First, the project were entirely developed on FreeCAD. The whole project files are open-source, hosted here. Check the two FcStd files in the main repo folder, one contains the base WikiHouse module, called "Wren", that file was used to generate the CNC cut sheets, and the other is the complete assembled model, that was used to generate the construction manual, documents for aproval, etc.
Second thing, everything happening during the construction (changes from the original project, difficulties, etc) is being recorded, documented, and is onlien on the same github account. There will be several reports written at the end of it all about the different aspects of the experience (technical, financial, etc..)
Also, the construction of a WikiHouse building is an amazing experience, and this is giving us a wealth of useful information, feedback, ideas. We used one of the main WikiHouse designs (the Wren module) almost without any modification, to stay on the safe side. However, we added many experiments around it, for example the "rain cover" that we're currently placing around it, or our hybrid construction model, part made by volunteers, part made by a professional construction team.
This all is too much information to be resumed here in a couple of paragraphs, but count on me to write detailed articles about all this after the dust settles. To resume a bit what's going on, the WikiHouse construction itself is a wonderful thing. People with no experience at all in building come, need only two tools (a rubber hammer and a flat screwdriver to "help" hammering the joints in), and in 2 hours everybody has turned into a WikiHouse building professional, able to build without even looking at the plan. There was no difficulty, no accident, and no "gambiarra". The result is very solid, while still manageable (the biggest parts, once assembled, can still be moved around by a 10-people team).
The rain cover is being built now, I'll have more to tell about it next month, but it is a very simple, cheap (whole cover costs less than 4000 BRL/1300 USD/1100 EUR), ansd easy to build solution. The polypropylene sheets we used can be cut with a pair of scissors. And they give a nice look (kind of cheap SANAA ;) )
The hybrid construction system, half professional, half volunteers works up pretty well to some extend, but it is the hardest part to manage. They are very, very different types of construction. The volunteers part is very, very fast, but requires everything to be very well planned ahead. The traditional system with a professional contractor, however, is slower, but they take care of a big part of the planning themselves, and there is much more experimentation and and on-site modifications possible. Really, both have their strengths, and I'm still very much convinced that it is a good way to go. But their different rythms are really hard to sync and "compatibilize", specially that we did this in three parts, first part with the contractor, second part with the volunteer team, and now the third part with the contractor again. This scheme should realy be simplified in the future.
Also one other thing stiked my mind, that I hadn't fully realized before: You don't make this with a team of volunteers to save money. You do it because people want to build their own house. The construction itself is the "product", not the finished house. The disappointment of the team when their "task" is over is big :) In the future we'll need to find smart solutions that allow the team to stay on-site up to the very end.
Both the professional and volunteers teams also need very different kinds of documents. Professionals are used to architecture drawings, and they feel more at ease opening a plan, that has everything on a single sheet, than browsing through a book. However, the book makes the whole construction easier to understand by volunteers. If you have both kinds of teams, you need both.
This started from a discussion that I had with a friend this month, about "all that BIM stuff", and several other discussions I stumbled upon on the net go in the same direction, so let's sum some of it here, no doubt it's a subject all of use are interested in ;)
The basic point we started with was "What about all that fuss, BIM here, BIM there, at the end where is the big gain?" Everybody who works in a BIM-enabled architecture office has a lot to rant about. BIM makes project organization actually MORE difficult than before, BIM is just a commercial concept idealized by software vendors to make you pay more, BIM actually RESTRICTS creativity (Some things were avoided in your project because they were hard to do with the BIM software being used, don't tell me this never happened to you), collaboration works "more or less" when everybody uses the same software, but becomes so complicated when different software is used that you end up needing a "BIM manager" to sort things out, etc.
Compare this with the 2D-based era, there are clear steps back IMHO.
However, what we're trying to do goes beyond the mere BIM term. I mean having a project that is fully (and reasonably accurately) modelled in 3D, and that is organized semantically (this cuboid shape is a wall, that other is a beam, both belong to the same floor, etc), and that contains as much non-geometrical data as possible/needed (this wall is made of 20cm of concrete block with specific thermal and structural properties), so that model can be used in many ways (to generate drawings, to study structural resistance or thermal behaviour, etc). Basically, a model that can be understood and used by others.
When you tell all this to mechanical engineers they usually look at you like, what's the fuss, we're doing that since a long time, and we still call it CAD.
But there is something interesting happening now: More and more you hear or read similar opinions. And far from being something negative, I think it actually serves the general direction. Many BIM gurus are having new looks at IFC, the good, old, clumsy, ugly, all-in-one BIM format that everybody likes to hate. That format should already have died a long time ago, by commercial standards. However, not only it doesn't die, but many people are having a new go at issues like versionning (or this one) or, like in a previous article I wrote, parametric files. And more and more people are also using it (I think) the way it is meant to be used: controlled and validated by rules.
It turns out the good old IFC format, even being ugly and clumsy, has surprisingly more tools than previosuly thought to deal with these "advanced" issues. In the case of versionning, I also think that the problem is beyond the file format itself, versionning CAD/BIM files is a complex problem where a change can be significant for a machine but not for a human, and vice-versa, unlike code. So the problem is actually larger, and when you look deeper at it, the IFC format contains many stems and tools that could at some point give birth to realiable solutions. We'll probably need to invent a revision control system that is very much based on semantics too (a way to "tell" or "describe" what has changed in a model).
All in one, I hope all the "myth" around BIM is beginning to fail/die, and I think it's a good thing for BIM...
I've not been able to do much in FreeCAD this month, apart from a couple of bug fixes. But I managed to work on one feature that needed a bit of love, which is the Arch Survey tool. This tool allows you to quickly take a couple of measurements by clicking on a model, like traditional quantity surveyors would do on a plan, by measuring the lines.
Until now you had to sum things up yourself. Now, the tool has gained a proper interface that sums lengths and areas as you click them. So it becomes very easy to measure, for example, the total length of walls that you have, or the total area of concrete slabs. And the final result is exportable as a CVS file, that you can import in a spreadsheet.
There are many more possible improvements, be sure to add your voice to the forum thread!
Finally, next month I'll be in the San Francisco Bay Area for the Google Summer of Code Mentors Summit. I'm really curious to see the inside of Google (Count on me to reveal all the secrets I'll be able to grab!), and it will be a great opportunity to meet the BRL-CAD people too, with who we're participating to the GSOC program for the second time, I hope we can set up more ideas to work together with other free and open-source CAD projects.
If you are in San Francisco around october 15-19, be sure to tell be and let's have a beer or coffee somewhere!