Time for a new report on the development of Architecture and BIM tools for FreeCAD. Remember, you can help me to spend more time working on this, by sponsoring me on Patreon, Librepay or directly (ask me for a PayPal email or bitcoin address).
Since I just recently opened the Librepay account, and the Patreon campaign is progressing much (I'm receiving above US$ 600/month already, thanks so much everybody!) I think it's time to be a little more serious and transparent about it, and give you guys some more "accountable" feedback on how the money is used. I'll start using this report to give a sum of how much I receive each month, all crowdfunding accounts together, and also make a bit of a better plan.
As you know if you read my last article, I just returned from the US, and we are also now finishing the WikiLab project (Grand opening is on next friday, november 10th). So I have been a bit away from FreeCAD coding for some time. But I've been saving the money from this campaign, and I'm now getting back to it, and it's quite refreshing! I have many ideas to work on, that I'm in the process of classifying. Basically I am currently working on two main ones (see below), and I'll also start attacking my overdue issue queue on the FreeCAD tracker, and I also have this "small" list of smaller items/issues that have either to be checked further or solved or implemented:
I should really transfer all this to the bug tracker...
I'm currently working on two things, that are not finished yet and therefore not ready to be used:
One is a new FreeCAD importer for Blender, that allows Blender to import FreeCAD files. A prototype exists already, but the Python3 version of FreeCAD that is needed by this importer still gives me problems (crashes on opening, etc). But once that is solved, we should have a proper importer again. And it will have a couple of more advanced features too, such as Cycles support and the ability to re-import a FreeCAD file later, and keep all your existing materials (only update the geometry of existing objects).
The other feature I'm working on (I have no code that is good enoough to test to share yet) is adding Appleseed as a new renderer to the Raytracing workbench. In a first step I am simply looking at producing an .appleseed file from FreeCAD, that can be fed to the renderer externally (same as we do with PovRay and LuxRender), but Appleseed has a powerful and elegant python (and C++) API too, that can in the futre allow a much more seamless integration, and litterally control and display the rendering progress within FreeCAD. But first things first. I'm also extending a bit the Raytracing workbench code, which is currently C++ only, to allow to add new renderers in python code, which will make it much easier for other people to help and add more renderers.
That's it for this month I'm afraid, thanks once again to everybody who helps me with money, and for your patience with me this last months during the WikiLab construction, I'll make sure it was not lost and reverts into concrete, usable material to push the development of BIM projects with FreeCAD closer to what we all wish it to become!
By the way, if you haven't yet, check the amazing work that Regis is doing with recreating one of Aravena/Elemental open-sourced projects in FreeCAD...
Last week was the Google Summer of Code Mentors Summit, a yearly event organized by Google, where they invite mentors of the Google Summer of Code program, a program that pays students to work on open-source projects. This year, like last year, FreeCAD participated to GSOC. This year we had 4 really good students, and the one I have been mentoring, Amritpal Singh, has done a really remarkable job with his Reinforcement Bar add-on for FreeCAD.
The two years, FreeCAD participated to GSOC together with other open-source CAD, CAM or 3D-related projects, under the "umbrella" of BRL-CAD (they basically did all the organizing). Each year, Google invites a certain number of mentors from each organization to the Mentors Summit, at Google headquarters, in California. So this year, I applied and was lucky enough to get selected. We were five in the BRL-CAD group: Sean, Vasco, Gauravjeet and Inderpreet from BRL-CAD, and myself from FreeCAD.
My main motivation to go was, beside a huge curiosity to see Google inside, I was really eager to know and chat with the BRL-CAD people, our umbrella organization. This project is quite fascinating, it is the first ever registered project on Sourceforge, it is very hard to see it progressing (their website doesn't show much), but it is a huge and powerful application, that stays a bit arcane, and hard to explore by newcomers. But I had a good contact with Sean over the years, and was really curious to know more.
So, the said day, after a pleasant flight (not so pleasant because at he last moment they changed my São Paulo -> Mexico -> San Francisco flight to São Paulo -> New York -> San Franciso, which added 2 or 3 hours of flight time), I landed at San Francisco and shared a ride to the Google headquarters with other people going there (everybody chatting and arranging these things beforehand through a quite interesting open-source chat system called Zulip that got used quite extensively throughout the event. Another chat app, RocketChat was there too, there has been quite interesting debates between the two, I still didn't make my mind fully).
So we arrived at Google HQ, landed to our hotel (conveniently located INSIDE the Google campus (which is not really one campus, they basically own half the cities of Sunnyvale and Mountain View). This is located at the southern tip of the San Francisco Bay (San Francisco being at the North).
And it began immediately, right there. You get your badge, and immediately you can start eating and drinking and chatting, because they reserved some rooms of the hotel and stuffed them with food. After a little while, a transfer bus takes you to one of the Google building, where there is a dinner (two large restaurants plus many cafés, food trucks, etc where everything is for free were available for us basically the whole time), then an opening session, then a couple of lightning talks (3 minutes talks to present GSOC projects), then more beer
I couldn't get a chance to showcase our GSOC projects of this year though, there were around 300 people wanting to present theirs, and only 50 or 60 slots.
There was also a cool table where everybody dropped chocolate brought from all over the world.
The next day started early, around 7h, with a breakfast at Google, and a whole day packed with "unconferences" (basically small spontaneous lectures or workshops organized by the mentors themselves), more food, more coffee, more chat, more lighning talks, and at the end, of course, more beer, and even roast marshmallow on the open fire, maybe the most epic moment for us non-Americans.
The last day was like that again, and ended up with a closing session in the afternoon.
Like I guess most people there, I didn't attend many unconferences. I basically stayed most of the time in the common areas chatting with people. My impression is that I never chatted so much in two days. At the closing session, the event organizers said they were happy, because they almost never saw anybody alone with his computer, which is something you see a lot in other open-source events. Everybody just kept talking with everbody, all the time.
This is really a magic that Google operated. There were no "boot camp" crap, or "socializing games" or any of those activities to make people socialize. They just provided space, food, drink, and a friendly atmosphere. That's it. Even me who is not a very social person, kept playing that game of going sitting for lunch each time to a different table with unknown people and talk about our projects. I've never seen an open-source event like that.
I also tried to get a glimpse at how life is at Google, but couldn't do much. The security schema was tight, no pictures allowed inside buildings, we were only allowed in a very small zone of the Goolge campus, you gave one step out of it and a security guard came to herd you, etc. But all in all I believe they do their publicity extremely well. In my mind everybody at Google would just lie on colored sofas, picking free drinks in an open fridge, would cycle around marvelous campuses on Google bikes, etc. The reality seems actually much more normal, you just sit on your computer and do computer work, and have meetings with your colleagues. But the atmosphere seems really relaxed, there really is free drink and coffee Other than that, my spying mission at Google failed miserably.
Ah, there were ice cream sandwiches too.
I talked a lot with Ton Roosendaal, the father of Blender. I met him other times already, he always keeps an eye on FreeCAD too. Ton made me a bit anxious, because he told several horror stories about big companies threatening to sue open-source project developers about patents, and in some cases managing to scare developers away of coding completely. We really need to start thinking about that at FreeCAD, and think of strategies to protect ourselves as much as possible.
But we also talked about things we could do together with Blender. The big game engines out there are moving towards offering more tools for CAD software, and we should do something similar, like an easy/1-click, template-based export from FreeCAD to the new stunnigly realistic view mode they are preparing in Blender, called Eevee. Just do a small search on youtube for "blender eevee" and your jaw will drop
Another person I hanged a lot with if François Beaune (Franz) from Appleseed, a stand-alone rendering engine, similar to Luxrender. I knew Appleseed for some time, and I had a vague idea of trying to integrate it in FreeCAD some day, but this has now become a much better and more realistic plan, after François showed me around the renderer, its API and file format. It is definitely doable, and could become easily the best integrated renderer in FreeCAD. It is in fact possible to make it totally seamless, as if FreeCAD itself would do the rendering. But first things first, we'll start with exporting an appleseed file from the FreeCAD Raytracing workbench first, like the other engines we support already. I'll also take the opportunity to make the Raytracing workbench a bit more pythonic, so new render engines with a python interface will be much easier to add.
And the third really interesting talk I had was with Sean from BRL-CAD. BRL-CAD is a very old project, started by the US Army, which later on released it as open-source. I really thought BRL-CAD had become a pretty inactive project, but this is very far from the truth. The thing is, BRL-CAD's main user is still the US Army, so almost everything that is modelled with it is classified, so it is very hard to publish anything that was done with it, which explains the very sparse image galleries, social media, etc.
However, it is an extremely interesting project. It consists of about 700 commands, a bit like a Unix/Linux operating system where all the base commands you use in a terminal, such as ls, mount, chown, etc.. are actually each one a file, or individual program. Then higher-level tools, such as the desktop environment, uses these commands under the hood to list directories contents, move files, change file permissions, etc.
BRL-CAD works exactly like that, it's a bit like a Unix of CAD... It has a graphical interface, but its real power resides in the vast array of command-line tools. And a modelling tree in BRL-CAD is in fact a shell script!
Another interesting feature in BRL-CAD is that it is capable of managing absurdly huge models. Since it doesn't really have a graphical modeling interface, which must display the model (and therefore compute it and triangulate it, because most computer 3D visualization systems around, such as OpenGL, rely on triangles), they can produce raytracing directly from the model definition and not from a triangulated version of it. This removes a big part of the process that FreeCAD has to do.
So there is much interesting stuff there that maybe we could do something with in FreeCAD. I am not sure what exactly yet, but only the "command line" system itself could easily be integrated into FreeCAD, it's not very different than what we do at FreeCAD level itself between App and Gui.
And BRL-CAD and Appleseed are also working on integration.
After the mentors summit ended, I got really curious about something I read in The Circle, the main character, who works at "some computer firm close to the south tip of the San Francisco bay", likes to take her kayak, go behind the office and paddle in the bay. I saw that the Google campus lies at a few minutes by foot to the bay, and there are many trail paths around, so I went there for a walk, and wasn't deceived. The area is magical, lots of channels and water ways, with here and there a stand-alone, man-made artifact, like a radar, a ship lock, etc...
After that I spend a couple of days in the lovely San Francisco, which I decided should integrate my list of magical cities, together with Barcelona, Venice, Cape Town and Rio de Janeiro. I did a bit of drawing too, and checked a couple of architecture icons like the Federal Buiding by Morphosis (impressive "concretization"of everything Morphosis has been saying, but big doubts about the so-called "green building" stuff and the very poor attempts at making the building users "socialize"...), Libeskind's Jewish Museum (really disappointing, very little more than just a "funny space", or the MOMA by Snøhetta (couldn't enter unfortunately, wrong planning).
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!