Time for our monthly development update. This month again, no new feature has landed in the FreeCAD codebase, because we are still in "feature freeze mode", which means no new feature (that might break something) can be added to the FreeCAD source code, only bug fixes.
We hoped to release version 0.17 in February, but, as usual, this has been delayed a bit. There are still some bugs remaining, and there is also some documentation missing. The whole community is working hard to fix this, so it won't take long and we will have a release with the documentation in a very good state, much better than it has ever been before.
Translations are also basically done, we have 16 languages over 90% translated and 5 100% done, which is more than we ever had in the past. It is still time to help us!
I have myself been busy touching all these areas, and also done more bugfixing in Arch and Draft. I think these two workbenches are getting pretty robust now, which is basically the level I wanted to reach at this point. My intention after the release is not to touch these features too much anymore, and concentrate on building better UI tools to manipulate them.
By the way, TechDraw is becoming more and more useful for BIM work, hopefully we will soon be able to retire the old section planes system for something much better... It is still a bit slow and not totally adapted to architecture/BIM (you must produce the elevation before the plan, for example), but those are all solvable issues. The results are very nice already...
As promised last month, I tried to record a video this time. Let me know what you think of it, sorry about the non-professional quality, I'm not a professional youtuber yet I propose to do more later on, about specific parts of the Arch workbench.
Since I was in Europe last month to attend FOSDEM (read about it in my previous post, and the video of my talk is here), I also took the opportunity to visit the Pionierswoning (Pioneers housing), another WikiHouse-based construction that happened in the same time as the WikiLab (We even had a dummy "competition" to see who would finish first) and talk with Vincent and Ivar who are behind the project.
This was a very, very interesting visit. The Pionierswoning is part of a bigger experience in Almere, to build experimental tiny houses. The number of single-person houses is climbing strongly in the Netherlands, and this becomes a very real question to solve. On the same site as the Pionierswoning are 5 or 6 other tiny houses made for one person, all of them with different approaches and solutions, definitely a very interesting place to visit if you are in the area (it's only a 15 minutes train ride from Amsterdam).
The Pionierswoning itself is definitely a very interesting achievement. Contrarily to our WikiLab, where we tried to be didactical and keep the wooden construction as apparent as possible, the aim of the Pionierswoning was opposite, they try to show that it could make a house like any other. As a result, you don't see the WikiHouse structure anymore. Most solutions that they adopted as finishings, both inside and outside, follow the same direction. It is amazing to see two projects built basically on the same structure, give such different results.
And I must say, the finishings they did are gorgeous. While on the WikiLab we had principally to deal with very short money (the whole construction cost no more than 15000 EUR / 20000 USD), which led to drastically simple solutions, they made a point to demonstrate the validity of the WikiHouse technology for "day-to-day" construction.
The other interesting thing is that both them and us came to the same conclusions afterwards: If the built result is not particularily impressive, in either cases, it is the process that is potentially revolutionary. The fact that it is possible for non professional people to build their own house, without any super-human skills or equipment.
All of us also had to deal with a construction that had phases dones by volunteers and other phases done by professional builders, and we all think much more should have been done by the volunteers, and things should be organized in a manner that lets the volunteers finish the construction. It was very frustrating on both sides for the volunteers to participate to the building, feel all the excitment, only to have to leave the field at some point, to let the professional team finish the job.
This is an experiment I am currently working on, and that you can already test. It is basicalyl an effort to re-think the whole organization of BIM tools and workflow in FreeCAD, with the aim of making it easier to learn and use. The basic idea is not to modify any of the existing tools of FreeCAD, just gather them in a more intuitive way, and provide a couple of useful macros to glue it all.
If using FreeCAD 0.17, you can test it immediately by installing it from menu Tools->Addon Manager. Or manually from here
So this workbench is, at the moment, a collection of tools from several workbenches: Draft, Arch, Part, Flamingo and Fasteners. There will be more later on. On top of that, a simple "setup" screen that will set all the most common FreeCAD settings used for BIM, and later on a couple of interesting macros from the Macros repository.
As I often say in these reports, building User Interfaces for BIM or CAD work is a very complicated task. Simple tools, like Sketchup or TinkerCAD have very good, simple and intuitive user interfaces. In FreeCAD, especially when dealing with BIM, we deal with much more complex situations. If we look around, other BIM apps also have very complex interfaces, and the learning curve is also steep. And when you look at, for example, BIM plugins for Sketchup, you also see that the complexity raises very quickly.
So there is no easy, straightforward answer to "solve" the steep learning curve of FreeCAD. But that doesn't mean nothing can be done either. But it needs some experimentation and step-by-step improvements. That is precisely what I want to achieve with this workbench: Find the good parts that run well, identify what doesn't work as smooth, and what can be done. It's all about details. The rest, the technical part, will stay in Arch.
I had this aim for the Arch workbench at first, to be the "all-in-one" BIM solution of FreeCAD. But the exponential growth of the addons being developed around FreeCAD, made me rethink that approach. The Arch tools, as said above, begin to be reasonably solid. They lack some polish, and better interface. That will be a main focus point for me this year. But it might be time to also think better in more global "BIM workflow". I have no clear idea of what that would be, that is the reason of existence of this new workbench.
Another motivation behind this is also to split things more between the "technical" part (the Arch Workbench), and the "interface" part (the BIM Workbench), and make the latter much more simple, so hopefully more people will be able to contribute to it, without having to merge much into the FreeCAD source code.
So, please use it, test it, be aware that it willbe an experimental test bed so it might change often, and share with me any thought you might have (that is reasonably doable, please!) to make the BIM workflow better, and the learning curve smoother.
Sorry about the late news again, but it would have been a pity not to include a fresh feedback from the FOSDEM that happened this weekend. So here are the main topics that happened in the last month. Once again, thanks a million to eveybody who helps the effort by contributing to my Patreon campaign or on LibrePay. Not only it's highly appreciated, but it allows to do more and more long-term planning, and 2018 promises to be rich in BIM features in FreeCAD. I also believe we are really closing the gap with commercial BIM apps out there.
Since FreeCAD is close to the next official release, that we plan to unleash this month, the development is now in "feature-freeze mode", which means nobody is adding new features (to avoid the risk to break anything and introduce new bugs) and instead concentrates on fixing bugs. Consequently, this month was pretty low on new features, so there won't be much appetizing BIM stuff to show here. On the other hand it was intense in coding and bug fixing.
Basically I have been busy thoroughly testing the BIM functions and workflow in FreeCAD, and fixed a lot of bugs on the way. I think it is now pretty stable, more than it has ever been in the past. Also all the main Arch/BIM objects (Walls, structures, windows, etc...) now have their base code pretty well consolidated and reliable, so the next step, which is working on making them a bit more user-friendly, can now begin.
To do this testing, I have built 3 house projects with FreeCAD. The internal organization of these files differs a bit from one to the other, but they are all pretty simple. I think they show well the "stage" you can now reach with FreeCAD easily and reliably, and extract from it all the data you need (2D drawings, decent IFC files, spreadsheets/schedules, and mesh models for rendering). Not yet a full large-scale building with all its details, but we'll get there.
In any case this is already a full BIM workflow, all objects are parametric, all export to IFC with all the properties you wish to add to them, everything can be modified, and the 2D drawings update automatically (or not if you choose not to, to have a faster workflow).
You will notice that these models don't use TechDraw for the 2D views, but that is because I specifically needed DXF files from these 2D views, which are at the moment easier to produce with the Draft workbench.
But that doesn't mean TechDraw is not up to the task, far from it. If you wish to produce good-looking documents right from within FreeCAD, give it a try, it works impressively well already.
There are also several interesting things that are available to you due to the very generic nature of FreeCAD, that are sometimes hard to obtain in commercial apps, such as mixing 2D and 3D elements in your models. You can easily keep these 2D elements out of IFC export (or not, your choice), simply by grouping things the way you like best. In FreeCAD, you don't really need to use Floors/Storeys/Levels. You can, if you need (for example to produce sounder IFC files), but you can perfectly well stick with groups. I often think BIM and IFC files would give much less headache if everything was simply properly named and organized.
The whole cycle of placing section planes, getting 2D views from it and exporting them to DXF/DWG is now pretty straightforward and hasn't given me anymore problems recently. Draft Shape2DViews objects now have a switch to disable automatic recompute, so they won't be recalculated automatically everytime you change an object, which can have a huge impact on performance if you have a lot of views. You can then recompute them manually whenever you want.
As we are coming close to our 0.17 release, there are a few areas which would welcome some help, if you have a bit of time to spare. The main one is to finish the translations, so we can include them in the release files. As I'm writing this, 6 languages are fully done already, and 10 others are at more than 90%. The other 34 also need some love. We won't wait for all of them to reach 100% ofcourse, but the more we get, the better!
There is also currently heavy work being done on the documentation to update it with all the latest changes that have been added mainly to FEM, Path and TechDraw, and to make it easier for users of earlier versions to make the transition to the new Part Design workflow. If you know some of these tools reasonably well, please help us to make sure the documentation is accurate and up to date!
So this weekend I was at the FOSDEM in Brussels, and gave a talk about the WikiLab project we've been doing last year, and how FreeCAD was used in it. The talk went pretty well, lots of people in the room (some FreeCAD forum members were there!), and very interesting questions raised. Thanks to FOSDEM blazing fast video processing, the recording of the talk is already available (the slides are here):
Right-click -> Play to play the video above or watch it here
Other than that, I watched a couple of talks (a big part is online already, browse here), hanged around the different booths, and because the FOSDEM is so huge, couldn't meet almost anybody I knew was there.
I got a bit surprised how the FOSDEM is still predominently a male event (around 95% males, my own estimation), while many IT/open source events around the world (FISL in Brazil for example) are very close to 50/50%. Mystery... But there were fries!
That's it for this month, stay tuned for the FreeCAD 0.17 release annoucement (or follow it on the forum), and after that, expect new BIM features to land in!
First off, sorry for the delay, I was trying to finish the new Render workbench (see below) before posting this report, because otherwise there is not much exciting stuff this month, and it ended up taking more time than I thought, because I kept experimenting a lot until arriving to a good solution. And since not much more will be happening this year, given the coming new year events (a good friend of mine calls this The Great Intoxication) I'll exceptionally make one report for two months, if you don't mind. But I'll give you some more news before the January report.
I'd also like to take this opportunity to thank you all who contributed to my Patreon campaign (or Librepay) this year, it has triggered some big changes for me, which took (and are still taking) more time than I thought, you don't turn into a part-time programmer overnight, but it is a really cool process, and, truth be told, during last year's dire economical crisis in Brazil, this FreeCAD "job" I now have thanks to you guys helped me a lot to keep the boat afloat. Thanks a million for that.
Basically FreeCAD development has now entered "feature freeze" mode, in preparation to the upcoming 0.17 release. I can hear the question rushing from your hearts: When???
There is unfortunately no answer to this yet, as some of you know, a motto we have at FreeCAD, that we really like a lot is: "It's done when it's done". This can be interpreted in many ways, you might think "lazy developers don't want to work hard enough!" but it is not that. It is very important to all of us to be able to release when we think it has reached the correct level of quality. As the project grows too, there are more and more developers involved, and more and more features weren't touched at all by one of the core developers, and it takes time to have everybody focus on fixing bugs. In a sense, FreeCAD has its own rythm, and we try to make sure everything that needs to be done is done before releasing.
Also, but this is more my personal opinion, working on an open-source project is awesomely cool. You don't have a boss telling you how you must do your job, no schedule, no deadline, no need to do this or that today, you decide what you want to do, how you want to do it and when. Total freedom. And I believe one of the main reason why open-source projects thrive well is this. People like to work on them, they have cool communities full of entusiast people who stick there for a very long time. And I think it is important to keep an open-source project a very cool and awesome place for developers to be. And I'm not sure very strict projects with lots of schedules and roadmaps are as cool to work with as FreeCAD I'd like to hear it if you have a different opinion, though.
Also in the case of FreeCAD we have a pretty permeable workflow. Development versions are easy to obtain and install, even side-by-side with the current "official" release, and are usually very stable. Most long-time FreeCAD users only use development versions. So the urgency to release official versions is low.
So, we are now in feature freeze mode, which means we don't add new features to the code anymore (at least we try to), we concentrate on testing and fixing bugs. There are still a couple of nasty ones to be fixed, but in general the process is going well.
Regarding the Arch workbench specifically, I am currently developing an architecture project with it, and using it as a test bed to test all possible scenarios and find bugs (and fix them of course). There is unfortunately nothing very exciting to share here, it's mostly small things, but this is an important phase.
All in all, I think the Arch workbench is in pretty good shape for the coming release, we of course still don't have all the features we want for it to be a full BIM application, but the existing tools grew a lot in stability, versatility and usability. For some of them like the structure or panel tools, I believe we're not far from commercial counterparts.
Also, there are now several tools and addons around Arch, such as Reinforcement or Flamingo, that, together with Arch, are building a much bigger and more complete BIM ecosystem in FreeCAD.
There are many things you can do to help to speed up the release process, if you are interested. For example translating FreeCAD, helping with the documentation or more generally, do some work with FreeCAD and help to find bugs. As always, the forum is the best place to go if you want to help.
The Render workbench is a new addon workbench I've developed last month. It is meant to replace the built-in Raytracing workbench of FreeCAD. The main reason is that the Raytracing workbench wasn't really made to be extended with other rendering engines, but these engines get obsolete quickly and new ones pop up all the time, so I thought it was worth starting a new one from scratch.
The Render workbench is coded in Python, because since the rendering itself is performed by another application anyway, there is no critical speed issue here, so the speed of C++ code is not really necessary, and it makes the workbench much easier to extend by other people. I also took extra care of making it simple to understand and extend, you basically only need to add one new file for each new renderer, and write 3 functions inside: One that writes the position of the camera in the file format of the renderer, one that writes the geometry of a given object, and one that is called when the "Render" button is pressed.
So far the two original engines of the Raytracing workbench are supported (Pov-Ray and Luxender), plus a new one, Appleseed. Other such as Blender's Eevee and OpenCasCade's CadRays are on my todo list.
The Render workbench works exactly like Raytracing: You start by creating a Render project, then add your objects to it. You can tweak some things like color, transparency, etc (the Render workbench also supports FreeCAD materials, which turns it the third workbench with material support, after FEM and Arch), and finally press the Render button to create the rendered image. And the Render workbench uses the same templates as Raytracing, in the good tradition installed with TechDraw and Drawing.
This is still pretty new, but in the coming days I'll try to produce some good-looking images to post on the forum.
That's it for today, thanks once again to everybody who helps me on Patreon or Librepay, it's really thrilling to see what this can produce, this year has been very rich in new features, I can't wait to see what we'll do next year!
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!
Time for our monthly development report, explaining a bit of what I did this month. Thanks again to everybody who help me on Patreon, each month we're getting higher! If you don't know about it yet, you can help me to spend more time working on FreeCAD by sponsoring me with any amount you want on Patreon. Some of you have asked me if it was possible to give me some money directly via PayPal, well it sure is! My PP email is yorik (at) uncreated (dot) net.
This month however I will have much fewer to share than usual. There are two main reasons to this, one is that I've been doing a lot of bugfixing, which is too boring to talk about here. It is boring to do too, of course. Any coder will tell you that it is much more fun to develop new features than fix bugs. However, they are very important. The stability of an application depends heavily of the relentless testing, identifying and fixing of bugs.
I saw where FreeCAD comes from, and when you compare it with FreeCAD as it is today, even with all the remaining bugs and problems it has, the evolution of its stability has been phenomenal. All thanks to this: tiny bugfix after tiny bugfix...
There is a story I always like to tell about bugs. We architects are usually very sensitive about errors. Doing a mistake is a terrible thing for an architect, and results in huge blame, shame, guilt. You always try to show that you know everything. As you can imagine, this also comes with a strong tendency to hide the dirt under the carpet.
When I began to work with JÃ¼rgen and Werner on FreeCAD, it is one of the first things that surprised me much: How these guys treated their own errors as a normal thing, a bug. Bugs happen. You are human, you make mistakes, the same way as you breathe or eat. It wouldn't make sense to feel guilty for this. Since then, I always try to treat architecture work like that too: Consider your mistakes as a normal part of what you produce, try to make them appear (unit tests for architecture?) so they can be processed and fixed.
JÃ¼rgen and Werner and all other FreeCAD developers, if you guys read this, thanks! I am learning a lot with all of you.
One of the things I did that was really sorely needed is a better User Interface for the Draft tool, that was really clumsy (you needed to "indicate" graphically the scale factor). Now there is a simple, proper dialog to scale things up/down, which allows you also to choose the result: Scale the original objects or produce a Draft Clone (where the scale can be changed later).
The other reason why this report will be less interesting this month is that the construction of our WikiLab project has started yesterday, so I simply had less time to work on new FreeCAD stuff. There has been quite a lot of work to do these last weeks to have all the construction documents ready before construction start, and the approval process ended up not being as smooth as we thought either (it is actually not entirely finished...).
But all this is also not work for nothing. The main issue with approval is, as you might imagine, fire resistence. Our WikiLab is made of wood, which burns. The risk for human beings is extremely low (the room is very small, only holds a few people, is escaped very easily, nobody will sleep there, etc), and the OSB panels we are using already have a slower buring rate because the glue they are made with acts as a fire retardant, but the problem is that there is as of today very little official record of all this. People in charge of approval basically want to see a document that guarantees them that such wall will hold a certain time under fire. These documents don't exist yet, because people rarely build walls with OSB panels, so panels manufacturers have little interes to pay for the research and fire tests needed to obtain such guarantees. Plus, these tests are very specific, so in our case a fire test would be valid only if it was made with the exact same wall composition as we are using.
This is a well-known problem when using experimental systems. Convincing authorities is very hard. But that is also where this process is interesting and useful, when done, we will have created a precedent, which will lower the difficulty for all subsequent ones, because they'll be able to refer to this one.
The work on the WikiLab construction documents also allowed me to play further with another idea I had: The 3D view of FreeCAD is pretty nice: It is anti-aliased, line style, width, thickness, color, transparency are configurable by object, it has a nice support for fonts, and even things like transparent textures. So instead of the heavy ans slow workflow needed to produce "traditional" 2D views with the Drawing or TechDraw workbenches, you could simply grab a nice view of your 3D window.
So far these cannot be exported "as is" to vectorial 2D. Exporting a 3D view to PDF is supported by the Coin3D engine (which powers the 3D view of FreeCAD), but the result is often buggy, the engine struggles at rendering some complex 3D situations to PDF.
However, exporting a 3D view to bitmap formats usually works very well. Most architects who will read this might dismay in horror at the idea of exporting architecture work as a non-vectorial format, but there are many "but" here.
First, it makes sense of course to export your work in a CAD format, such as DXF or DWG if others need to work with it. But a PDF? Will anyone ever import a PDF to work on it in a CAD program? That would be pure masochism, there wouldn't be much you could do with it. Also, when working in an open-source way, or any case where your base files are more easily acessible to others, and are in an open format, all this discussion looses a lot of its meaning... If a person can get a FreeCAD file, why would that person need a PDF file
The next advantage of a vector-based format such as PDF is the reduced filesize. However, this is true for basic line-based work, but as soon as you use more fancy things such as transparency or textures or gradients, most CAD systems will turn that into bitmap anyway, so much for the file size. And large complex areas filled with one color can often be smaller in size in bitmap than vector format, where havy triangulation is needed (which by the way often stays visible in the PDF file). So there is not much difference at the end.
The third advantage of vector-based files is that you can zoom in and things continue to look sharp (this is certainly only useful for on-screen viewing, has any of you ever printed a PDF file at higher scale than 1x?). But this is just a matter of resolution, just save an image with enough resolution to be well readable when zoomed a lot, and this problem disappears. Plus, even if your image is embedded in a PDF file, zomming is blind-fast compared to zooming vector-based PDF files.
In the last years I've used bitmap files more and more to show traditional CAD work like floor plans. You can do all kinds of fancy things in
Photoshop Gimp, and if you manage your layers well, it is totally manageable to reimport a layer from your CAD/BIM app when something changes in the project.
So I used this a lot in these construction documents. By using Working Plane Proxies you can easily configure views that you can recall anytime, so it is easy to produce a new image that is identical of the last one when the project has changed. And the Tools->Save image dialog of FreeCAD allows you to save an image with a very high resolution, which gives a very sharp result.
There are sill issues to solve, such as calculating the resulting scale, or ensuring that texts and dimensions have coherent and consequent size across different views, but that shouldn't be hard to solve.
Of course this is not the holy grail. There is still a series of situations where you'll need vector-based output. But when you try to show a project in different ways, like we did here, it might become a lot more convenient.
The only real new feature I've been working on this month is the Arch Grid, that I just merged. A tool to construct a grid object, like you do in a spreadsheet: define columns and rows, change their sizes, and merge cells together.
This object can then be used to perform a series of other operations with Arch objects, for example spread objects on its vertices, face centers or edge midpoints, or use it as a base for windows, instead of a sketch, or for any other kind of situation such as constructing railings.
That's it for this month I'm afraid, sorry I couldn't do more, next month will likely be like this one too as we will be building the WikiLab, but you can count on me to share all I can during the construction. Almost all our wooden part are cut and ready to be assembled, the masonry base is being built now, and the assembly is scheduled to start on september 12th. If you are in SÃ£o Paulo at that moment, don't miss the opportunity to participate!
Thanks again to everybody who is helping this adventure to come true, each month a step closer to a full, feature-rich open-source BIM application!
The title of this article sucks, I know, couldn't think of anything better...
This is a concept I wanted to play with since a long time, and last month I was finally able to setup a proof of concept. The only missing part was to write an article explaining it, so here it goes.
For who is not familiar with the BIM or parametric 3D world, IFC is a file format used to exchange BIM data. BIM stands for Building Information Modeling, and is basically "3D parametric modeling for the construction industry".
There has been quite a fuss for a long time on the internet about this. "IFC is not parametric", you'll read around. "So it cannot be used to transmit model intelligence", Revit users (and specially sellers) will tell you. This always annoyed me... After all a file, that is stored on your computer, is a "dead" thing. It cannot perform computations, it's just a storage for data, so how could it be intelligent? There is no such thing as an "intelligent file format" except maybe in the mouth of some astute marketing gurus...
The "intelligence" doesn't lie in the file. It is the application that does intelligent things with the data it finds in the file. Also consider what a parametric object is. A parametric box, for example, would have 3 parameters: Length, width and height. A program would then construct a box geometry from these 3 parameters. The 3 parameters are everything that is needed for the program to construct the box. If you save these 3 parameters to a file, when reading the file back, the same program will be able to reconstruct the box, just knowing its length, width and height.
I'm using in this text words like "parameters" or "attributes" or "properties" more or less indifferently. It means basically, a piece of data (number, text, whatever) that is attached to an object, for example the length of our box.
This idea comes from an old discussion I once had with Inkscape people. Inkscape uses the very well-known and very standardized SVG format, which is readable by a huge amount of applications, including almost all web browsers. The SVG specification is something tighly maintained and controlled by the same consortium that maintains HTML and almost all the web standards.
However, Inkscape needs to save things in its files that are not part of the standard SVG specifications. They do this by writing standard SVG files, but adding custom properties to standard objects, which is something the SVG specification allows.
So Inkscape, when reading that file, will see the custom properties, and be able to use them the way they are meant to, while other applications will simply ignore those properties, and will only consider the standard parts.
An example of that is the "star" tool of Inkscape. The star object created by this tool is parametric, that is, if you edit the star after you created it, you will still be able to modify the number of spikes, the radius, etc. If you save the file, and reopen it, you are still able to change the number of spikes.
If you open that same file with any other SVG application that is not Inkscape, they will show the star correctly, but won't be able to edit it. Inside the file, the object is a standard SVG path object like this (the data inside the d parameter are point coordinates with instructions such as Movement or Line) :
<path d="M 100,100 L 90,75 L 100,95...">
This is standard stuff, readable by any SVG app. Inkscape adds its own attributes like this:
<path inkscape:type="star" inkscape:sides="5" inkscape:cx="90" inkscape:cy="95" d="M 100,100 L 90,75 L 100,95...">
"inkscap:sides" or "inkscape:type" are additional parameters that only inkscape will see when reading the file. Inkscape wil then know that this path is actually a star, and will be able to re-generate a different path data if you edit the star.
It was thought right from the start that applications might want to add such custom content to their SVG files, and therefore the SVG specification provides this nice namespace system where you can write your custom additions by preceding them with a name that identifies your application (inkscape: in this case), which turns it easy for you, the Inkscape developer, to identify Inkscape-specific content in the file. If you use such namespaces, the SVG specification even forces you to add a line like this in your file:
So other developers, when reading your file, when they see your inkscape: attributes, will not need to google for it, they will be able to go right to a page where you have carefully documented it all... Isn't that nice?
So basically here we are: the same concept can be applied to IFC. IFC supports adding custom properties to any object. Let's say you have an application that draws chocolate walls (yes, it's a BIM app for cake makers). You could make your application save your cake as an IFC file, and store its walls as standard IFC walls. But you would add a special property, for example: chocolate_type="milk chocolate". Your cake would still open in Revit, but only your app will see and read and use the chocolate_type property and will be able to recreate the cake faithfully and parametrically (you will be able to change the chocolate type after loading the file).
So I added this to FreeCAD, as a very simple proof of concept. There is now an option in Edit -> Preferences -> Import/Export -> IFC named "Export full FreeCAD parametric model". When you switch it on, when exporting to IFC, the resulting file, instead of being formatted like this:
IFCWALL (made from extrusion) -> EXTRUSION (made by extruding a base polygon 2m high) -> BASE POLYGON
Now contains additional properties like this:
IFCWALL (made from extrusion, and using 'FreeCAD' property set) -> EXTRUSION (made by extruding a base polygon 2m high) -> BASE POLYGON -> 'FreeCAD' PROPERTY SET -> PROPERTY ObjectType="Arch.Wall" -> PROPERTY Width="20cm" -> PROPERTY Length="200cm" -> PROPERTY Height="200cm"
The IFC importer of FreeCAD has also been adapted so when reading that file back in FreeCAD, you obtain faithful, 100% identical parametric objects as when you exported it. In fact, when FreeCAD finds an object inside an IFC file that has a "FreeCAD" property set, it will simply skip all the rest and reconstruct the object only from the contents of the property set.
But other applications, unaware of the FreeCAD contents, will still see the "standard" definition:
So far this is just a proof of concept. There are many property types of FreeCAD that are not yet supported. But it would not be much work to extend the system to support them all.
Now I can hear the arguments against all this gathering in your head. What's the point, if other apps won't be able to do anything of that shit? What if the other app modifies the standard IFC content, but leaves the FreeCAD property set intact? FreeCAD will ignore the modified version. Etc, etc. The counterarguments are many.
However, the discussion has shifted. What if such "extra" parameters/properties/attributes were clearly documented somewhere? What if, for example, Revit would export its walls with a defined set of properties that would allow it to recreate the wall 100% as it was before exporting? We could make FreeCAD see, use and modify those properties too. Or, even better, have a common definition that says "all walls must have length, width and height properties". That actually exists up to some very basic point in IFC, you can add a "standard wall property set" to walls, that contains such generic properties that should be common to all walls. I have never seen that system being used very much yet, though.
So is the problem not in defining things correctly, instead of blaming IFC for not being technically fit to the task? The model works well for SVG, it would be really worth trying...
Jon Mirtschin, the famous IFC guru behind GeometryGym, experimented a lot recently with similar concepts. The difference with his approach is that he found a way to bind properties to certain values in the IFC file. Simplifying a lot, his file looks like this:
IFCWALL (made from extrusion) -> EXTRUSION (made by extruding a base polygon by the value of "Height") -> BASE POLYGON -> PROPERTY SET -> PROPERTY Height="2m"
So the relationship between the extrusion value and the Height property is written in the file. This is obviously a much more interesting solution freedom-wise. Everything is stored inside the file. You can invent any kind of parametric relationship like this. And when you remember that GeometryGym is developed principally for Grasshopper, where you could read that file and reconstruct any kind of wild, crazy relationships written in the file (for example: The height of the wall equals to half the width of the whole facade, minus the height of the front door), this makes a lot of sense.
But the question remains: What would Revit do with a file that contains a definition like: "The height of the wall equals to half the width of the whole facade, minus the height of the front door". I think that's something where both approaches meet the same issue: Sooner or later, some of the parametric content will be discarded by some application, that will say "Here we don't construct walls like that. We don't allow this".
But my point in this article was to show this: Not only IFC can perfectly well contain parametric objects, it can even as Jon's example shows, contain your wildest parametric dreams, actually probably far beyond any other proprietary file format out there can do. Implementing parametric relationships in the IFC file format is something that has been researched for quite some time already, and there are other further plans too.
An IFC file that can do the full round-trip (be exported from your application and reimported with 100% faithfulness and all its "intelligence") is totally possible, that's now clear and proved. The remaining problem is actually not a technical issue, but much more a communication issue.
What if the consortium behind the IFC format would issue a chart, with things like "The parametric properties that a wall should have", or force you, if you add custom properties, to provide an URL where you explain it all, like SVG does? These things would not make the problem solved tomorrow, but would allow to progressively structurate and consolidate parametric IFC files, that could progressively become fully editable by more and more applications.
WTF, July development news in August, I hear you yelling (it's not only me!) But there was some last minute topic I really wanted to complete to include in this report... But now that it is complete, I think it deserves another post on its own, so I'll only mention it here briefly. It will be worth it, I swear
First off, I'd like to thank once again everybody who is contributing to my Patreon campaign and through there helping me to spend more time working on FreeCAD. This month I passed over USD 500/month, which becomes pretty important. In Brazil, where I live, the "official" salary of an architect (that is, recommended by the national council of architects) is around USD 2500/month. In reality, only some architects working in public institutions earn that much, in the private sector the usual salary is about half that amount. To put things in context, the 10% bar, that is, the salary you must earn to be in the richest 10% in Brazil is around USD 1100. So my 500/month begin to represent some consequent weight (it's almost a teacher salary). Yeah, these things make you think a LOT about what value is. And for who.
I started this Patreon campaign not really knowing where it would go and if it would allow for something serious, but now I begin to really believe it can change a lot. Working half-time as an architect and half-time as a FreeCAD coder is an idea I'm growing really fond of...
But enough about me, there is quite a lot to tell this month.
This is the big thing I wanted to merge before writing this report. I'll post something more detailed soon, but the idea is basically to export all the parameters of FreeCAD objects to IFC. So when reimporting that IFC file in FreeCAD, parametric objects are fully and faithfully restored. The idea is to show/prove that yes, IFC is totally adapted for parametric design. More on that very soon.
So the big thing I have been working on these last months is now merged in FreeCAD. I have been posting about it in the previous report already. It is an algorithm that organizes shapes to fit into a containing shape. This is useful in CNC operations, when, for example, you want to cut out a series of wooden pieces out of a wood panel, and want to stack all these pieces the best possible way on your panel.
There is now a nesting tool in FreeCAD, located in the Arch workbench, under the panel tools:
The system is simple, you launch the tool, select the containing object, then add the objects to be placed inside. Tune some parameters if needed, and launch the calculation. It is currently not much optimized and quite slow. When the calculation has finished, you can see a preview of the result, and if you apply that result, the object get moved and rotated to their preview position.
The next two features I'll add are support for margins (you usually don't want te pieces to touch, but leave a certain margin between them) and allow for non-rectangular container, so for example you could reuse scrap material easily. Then it'll be time to attack some optimization.
The nesting algorithm itself is separated from the tool above, so it could be used differently by other tools and workbenches. And also, it can be recoded in C++, which should make it run a lot faster. That will be done too later on.
I also introduced several changes to the Arch Axis system. There was already a way to make a series of structural objects spread over the crossing points of different axes, but it was not very easy to find and weird to use. I believe the new system is much cleaner and powerful. It basically works like this now:
There is now a new Arch tool, called Axis System that now really does what the icon means: Organize several axes series into one system. It can take two or three axes objects (you can edit that by double-clicking the axis system in the tree). Its function is basically to calculate the intersection points between all the axes.
Not only structures, but all Arch objets can now be spread along axes or axes systems. For that, they gained a new Axis property. By setting this property, you can make your object be duplicated automatically. The rule is as follows:
Now I think the situation is much cleaner, it's much easier to first create your axis systems properly, then make your other arch objects make use of it, and change/undo all this whenever needed. Also,by using any other shape as an axis system, many wilder possibilities become possible, such as using a sketch to drive the position of Arch objects, etc.
The Draft Working Plane tool is something you use constantly and everywhere when working with Arch. It is one of these tools that grew more and more complex over time, and that is now quite a powerful behemoth... For who is not used to Draft/Arch, it is responsible for setting a 2D plane where all the subsequent Draft and Arch operations will take place. The location of this working plane is represented by the Draft grid, that shows the position and orientation of the plane, and also gives a visual interval (the grid size), which you can also snap to.
The current possibilities are fair already, you can set that working plane quickly to one of the origin planes (top, front, side) or select a face and make the working plane adopt that face orientation and position.
Now I added a new Working Plane Proxy tool in Draft, that stores the position of the current working plane. It is represented on screen by a small widget (the size is customizable).
When selecting this widget and pressing the working plane button, the working plane will return to the location/orientation of the widget. You can even move and rotate the widget by conventional ways (it has a Placement).
The idea is that you can now save important working plane positions in your document, precisely, without the need to have "real" geometry there.
This proxy object also has two more interesting features: a Restore View property, that will, when restoring the working plane to the proxy position, also restore the camera position. So you can use the proxy object to store not only the position of the working plane, but also the view angle. You can change/store the current view anytime to a proxy object, by right-clicking it in the tree.
The other feature is a Restore State property that, when restoring the working plane, will also restore the visible/invisible state of all document objects (the ones that were present in the document when storing those states, that is). Here too, you can store the current state anytime by right-clicking the object.
With these two features, we are paving the way for a more conventional BIM environment, where you can switch from working on one floor to another floor, and all your environment (working plane, view orientation, visible objects) will change accordingly.
Next thing I'll look at is how to tie that to Floor objects, but these floors need a good refactoring first...
The recent GSOC work on Arch rebars (I strongly suggest you to have a look at the impressive work being done by Amritpal, our GSOC student, and several members of the community around, the image above is taken from there) also gave us the opportunity to tackle a long-lasting inherent design problem of the Arch workbench, the famous non-DAG bug. DAG stands for direct acyclic graph. It describes a type of graph or tree which all flows in the same direction, where it is forbidden to go backwards. The relationships between objects in a FreeCAD document is a DAG.
That means the dependency chain between FreeCAD objects must always flow in the same direction: You can object C that depends on object B that depends on object A, but you cannot have object A that depends on object B that in turn depends on object A. That would be a cyclic dependency (you cannot know which one comes first, A or B) and is forbidden in FreeCAD (if you find yourself in such a situation, FreeCAD will print non-DAG error messages and refuse to process anythingmore until you fix the problem).
Two Arch objects were constantly creating non-DAG situations: Windows and Rebars. The window, for example, often depends on its host wall (in order to know on which face it lies) and the wall also depends on the window to know how to drill the opening where the window is placed. The workarounds I had imagined until now to circumvent the problem were really not very satisfactory (for example create a second wall, so the base wall and the wall with the opening were two different objects).
With the Rebar, we now experimented a new idea that seems to solve the problem for good. It is not the "parent" object that knows which "children" it holds anymore. It is the child that knows which "parent" it belongs to, and the parent is not dependent on the child anymore.
That introduces a bit more complex system: The wall doesn't know which window is part of itself anymore, so when updating its geometry, it now has to "scan" the scene to find the windows it must use to drill openings. But this is a very ponctual and unperceptible slowdown, and I think totally worth the much cleaner situation and the vanishing of the dreaded non-DAG problem.
The Rebar object already uses the new system, and it seems to work very well, so I'll adapt the window to use the same system in the coming days.
Another talk I had with a FreeCAD user (that will soon become a more stucturated plan) lead me to this interesting experiment, where you take a simple Part Box, and use it as a "driver" shape for inner objects, like the panels and doors of a cupboard. This is an interesting workflow, and I liked to be able to work with simple boxes, that contain their own more detailed components.
The test file is here if you want to have a look at how it works.
I already had other discussions before about furniture/cabinet design with Regis and others, it would be a good time to think about a proper workbench for it.
Talking about Regis, one of the most knowledgeable Arch/BIM FreeCAD users around, have a look at the impressive series of videos he has been producing lately about BIM work in FreeCAD...
I also added UI controls to edit the boundary objects of Arch Spaces. Spaces can be based on a solid object (their shape is therefore the shape of the solid object), or a set of boundary faces (the shape of the space is therefore the bounding box of all these faces, subtracted by the volumes - or half-spaces - behind those faces), or a mix of both (the shape of the space is the shape of the base solid, subtracted by the half-spaces behind the boundary faces).
There was until now no way to edit the list of boundary faces without using the python console, this is now solved.
That's it for now, sorry about posting late! Still a lot that I wanted to do this month that will be for the next month, but step by step we're getting there. Thanks for reading, thanks to everybody who help me to make this come true, and as always, comments are welcome!
This is time for a new review of what has been going on in Arch development this month. Quite a lot actually, it's exciting that several things I've been working on during the last couple of months begin to flourish into pretty interesting and usable features.
There is another interesting thing happening, is a very good synergy between the WikiLab project I'm working on now, which you must grow tired of hearing about, and FreeCAD developement. FreeCAD fuels the project development, which in turns fuels FreeCAD with bugfixes and new features. Me and other FreeCAD community members are really keen to pursue and extend that synergy further with other projects.
As always, don't forget you can help me spending more time on FreeCAD, by sponsoring me via my Patreon campaign. As a side note, that campaign is really taking flight, sooner than I had expected, I'm highly overdue to update the campaign page, and add some whistles and bells such as goals and rewards.
As a possible reward, I am thinking about doing some short videos, explaining in detail specific feature of the Arch workbench, and more generally, doing BIM with FreeCAD. For example, one about walls, one about working with imported dwg files, things like that. These videos would be, in a first time, available to Patreon supporters only, as a kind of present to thank them, and then, after a couple of months, added on youtube for everybody. What do you think? Good idea? Lousy idea?
So enough of this, here is the real stuff:
If you are following the progresses of our WikiLab project, you might have seen that the crowdfunding campaign ended successfully, and we are now getting started. The wood panels have been ordered already, the final cutting sheets are being made, and the cutting should begin next week. This will take roughly two months, during which we will contract a constructor to build the foundation and base walls, and hopefully everything will be ready to build the WikiHouse-based part, at the end of August, during the university holidays, and just before the rainy season.
On the image above is a first "rib" we've been mounting this month, as a kind of proof-of-feasability, and to boost the crowdfunding campaign too. It went amazingly well, this element was built in about 2 hours by 5 people, it is very easy to understand and build, and the solidity is really impressive.
I'm also starting to write a manual (in portuguese) that willbe the actual construction document. No plans and sections in this project!
There are still several details to solve, some of them have been already discussed and solved on the WikiHouse community slack, which is a really cool way to solve these issues collaboratively, something we've been doing with OpeningDesign for quite some time already
We are also studying small changes and improvements to the design, such as holders for shelf supports, and ventilation holes at the top, that can be closed with 3D-printed custom lids.
This is a new feature I've been working on, inspired by Revit's tag objects. In Revit, you have different types of tags, that you can attach to an existing object. That tag will then automatically display a certain information about the attached object. For example, material tags will show the material of the object, door tags will show the door number, etc.
In FreeCAD I decided to go for a bit more generic approach: There is a new generic Draft Label object, which is made of a piece of text and a two-segment line, which can have an arrow at its end. The text can be made to display some property from the attached object. At the moment only a small list of properties are available, and can be selected from a drop-down box, but the system is very extensible and you could have those Labels display just any kind of information that can be retrieved from the base object.
As always, this is only the first, rough version, it works, but over time and use it will certainly refine ito something more solid and powerful. It should also gain additional feature so it can be used for all the Revit scenarios: show component numbers, space tags, etc. All these should be displayable in a distinct manner (in a rounded rectangular frame, in a circle, etc...)
The other big news of this month, is that I've been elected for a Shuttleworth Foundation Flash Grant! Thanks to OpenSourceEcology fellows, who indicated me! I still don't have fully formed plans for what to do with the money, but a couple of things I definitely want to do: 1) Help founding the wikilab project above (that is done already), 2) Turn the FreeCAD manual into a printed book. Most of the work is done already, it still needs a professional editor review, then it can be printed and sold, which nowadays is very easy thanks to sites like lulu.com. And 3) extend what I'm doing with the money from my Patreon campaign, spend more time coding for FreeCAD. I would be able to work half-time on FreeCAD for a coupe of months, I'm trying to see how to set that up now. As a point 4), I might have more/better ideas later on, still thinking about it.
This year, FreeCAD has received four student projects for the Google Summer of Code. For who doesn't know, it is a program by Google to sponsor students to work on open-source projects during the (northern hemisphere) summer months. We are now approximately at the middle of the coding period, and our 4 students are doing great!
I am myself mentoring one of these projects, together with Bernd, which is Amritpal Singh's proposal to extend the Reinforcement bar tools in FreeCAD's Arch module. So far so (very) good, Amritpal is surprising us with the quality of his code, which you can already test if using a development version of FreeCAD: Just install the Reinforcement addon via the addons manager, and on next run, the Arch workbench will detect it and add its tools under its current Rebar tool.
The objective of Amritpal's work is to extend the User Interface around the Rebar tool, to add it a series of tailored dialogs to create specific types of reinforcement bars, such as straight bars, U-shaped bars, stirrups, etc. All this UI work integrates with the current Rebar object, which is kept as the overall, can-do-everything Rebar object. The different dialogs help the user to create and edit these rebars in a more friendly way, but doesn't remove anything of the power of the base rebar object, which is simply made of a profile, an extrusion path, and a series of placements, and can therefore represent any kind of rebar we can think of.
Everybody wins with this approach: The normal user, who just wants a clear and easy way to add reinforcement bars, and the power user, for who these dialogs are not enough and who wants to tweak or script these rebars in any way possible.
Here is the best part, in my opinion. I'm working (it's not finished yet, but working already) on an algorithm to perform bin packing in FreeCAD. It is an operation that consists in placing/packing different shapes inside a container (the bin), so it uses as little space as possible. The immediate output, obviously, is toproduce cut sheets for WikiHouse-style constructions, like this:
Interestingly, this is a subject that renders a lot of theory (lots of research papers on the net), but few open-source applications. The only "readable" ones I found were SVGNest and the WikiHouse plugin for SketchUp. None of them is usable directly in FreeCAD (different coding language, too tied into their host system, etc), but they provided precious resource to understand how such an algorithm should work.
They both use the same concept, which is the no-fit polygon. The idea is more or less this: You place a first piece inside the container. Then, for each other piece, you try to "rotate" it around the already placed piece(s). You are basically trying to place the new piece as close as possible to the ones already there. By doing this, you end up defining a "no-go" zone, that is, a zone where our piece cannot go otherwise it would overlap the already placed pieces. By subtracting that zone from the container area, you obtain an "available zone" where the new piece can be placed. You then place the piece at the leftmost available position in that zone, try again with different rotations of the piece, measure the results, and keep the one that occupies the smallest space.
The above concept is working already. It takes a lot of time now, it still needs a lot of optimization. But the concept seems solid. Later on, I will try to implement a genetic algorithm which would run several passes, swapping the order of some pieces, and keeping the best solution. There is a lot of space for improvements.
In the coming days/weeks I should have a basic implementation ready in FreeCAD, so we can start playing!
The nesting system described above is made to work with any shape or feature of FreeCAD. You select a series of flat objects, and another flat object as the container, and the algorithm will return a series of placement transformations, that you can apply to the object to have them packed into the space defined by the container shape. So this will work with any Part-based object.
However, the main interest for me is to use this with Arch Panel objects, for constructions such as our WikiHouse-based project above. These panels, at the moment, already have several features that will be useful for this kind of use, such as the Panel Cut feature that produces a flat view of a Panel, to be placed on a Panel sheet, you see that everything is ready for the nesting, we already have both the shapes and the container.
I already added a couple of useful features such as individual margin settings for each Panel Cut (the minimal distance it must keep with other pieces on the sheet), and the ability to render a Panel Cut either as a Wire or a Face. I also added a way to define and represent wood fiber orientation on a Panel Sheet:
This, allied with a way to restrict possible orientations of a piece on the sheet, will allow to have the nesting algorithm respect the fiber orientation when placing the pieces. There are also other features to come, such as the possibility to use any shape as the container (at the moment it is restricted to rectangular shapes), and I believe we will have a pretty powerful and flexible system.
Then the last operation needed in order to make FreeCAD produce WikiHouse components entirely, is to generate Path objects from the Panel Sheets, a task that has been already worked on extensively by Sliptonic (check this video where he explains it all).
So here we are for our monthly report of what has been going on on the FreeCAD front this month. As usual, I will mostly talk about what I have been doing myself, but don't forget that many people are working on FreeCAD, so there is always much more happening than what I talk about in these notes.
To resume quickly, Werner has been busy working on the whole FreeCAD, as usual, but specially enhancing several issues in the tree view, making selection of large objects much faster, added several FEM tools, and fixed hundreds of other things. Looo has started merging core stuff from his Python3 branch into master (step by step, we will get there), WandererFan made a big update to TechDraw, Abdullah worked on better exceptions handling, and Realthunder is pursuing his work on PathArea, a set of tools inside the Path workbench, that work a bit differently than the others (they rely more on shapes).
But there is much more. For a deeper look at what has been worked on recently by me and others, check the commits log on github. Also, don't forget that more and more is happening outside the strict circle of FreeCAD source code, since it becomes more and more convenient to plug external workbenches into your existing FreeCAD installation. By the way, one of these external workbenches that becomes more and more interesting for BIM work, is Flamingo Tools. Check it if you haven't yet (look at the very professional pdf files in the "tutorials" folder)
So below are the highlights of what I have been doing recently. I also fixed a lot of small issues, but that are not worth mentioning here.
Don't forget you can help me spend more time on FreeCAD by collaborating to my Patreon campaign. This campaign is beginning to grow to impressive levels (special thanks to AlephObjects!) and I might soon have more impressive news to reveal! So next month I'll start improving it a bit, add goals and maybe rewards. I have a couple of ideas already. Don't worry, all of you early backers will automatically qualify for the whole suite
The most important feature I've been working on this month is a new Multi-Materials system. The idea is simple: Arch objects (and already some other FreeCAD objects, such as FEM) already have a Material property. If you give an Arch object a material, it will take the color of that material. Scripts and macros can already use the information contained in that material, for example the density, but so far that is all it does.
Arch objects can now, instead of a Material, take a Multimaterial. The multimaterial simply holds a list of materials, each with a given thickness:
This can already be used in Walls, Panels and Windows. Walls and Panels will use this to construct multi-layer walls and panels, and windows will use this to give a different material to each window part (frame, panels, etc). These objects all become multi-solid, and will contain a same number of solids and materials. With this, the paradigm change of the Arch workbench to multi-solid is now complete: Before, Arch objects were made of exactly one solid. Now, Arch objects can be made of one or more solids.
So far intersections of these multi-layer walls are not done automatically, I am still investigating the best way to achieve that...
With other users we were recently looking at Microstation's AccuDraw system. If you ever used Microstation, that is one of its most interesting features. Everytime you click a point to draw a shape (polyline, etc), you have an incredible amount of options available. The snapping system in Dratft/Arch is very much inspired from it, but there are still a couple of interesting features missing:
One first improvement is a new button in the task panel to realign the Draft working Plane while drawing a Wire/Polyline, along the latest segment drawn. This gives you a series of new alignment options and works very much like AccuDraw.
There are also a couple of new tools to place the Working Plane accurately: The Working Plane button now also works with 3 vertices selected, instead of a face, there is a new tool to place a Working Plane proxy in the document, that has the effect to save a working plane position. At any moment later, you can simply reset the working pane to that saved position.
Finally, I have added a couple of convenient macros to the Macros repository (remember that with FreeCAD v0.17 you can now install any of these macros directly from the Addons Manager): A first one rotates the view so it faces the current working plane perpendicularly, which basically allows Draft to behave like the Sketcher when drawing in a certain plane, and another that does the contrary: It moves the working plane so its center is exactly at the center of the current view. This is useful when you are drawing far from the working plane origin, and therefore you are out of the grid limits.
Another area I've been pretty busy this month, is not fully FreeCAD. It is our WikiLab project. By the way, I will have a chat online with people from the WikiHouse Foundation on youtube, on monday 29th. If this subject interests you, be sure to join us! I also recently wrote an article about the project for the WikiHouse website that you might like.
The project crowdfunding is also coming dangerously close to its end, if you have a couple of Reals to spare, please consider helping it, the experience gathered with it will be precious for everybody...
We also started cutting a couple of test pieces like these:
This was basically to calibrate the machine. One of the partners of the project is 123painÃ©is, that is where the cutting (and part of the assembly too) is done. But it also served to test if OSB panels would work well, and I can tell you they work amazingly well. I was afraid the cut would be a bit rough, but the cut is just perfect, and the finish is very nice.
"Enough of that!" will you tell me. "What relation with FreeCAD does this have!" Well, a lot actually. To begin with, the project is entirely developed on FreeCD. Also, I did a lot of coding for the Path workbench which was a sponsored job, made with Brad Collette (sliptonic in the FreeCAD world) and Daniel Falck. But at that time, I didn't know much about CNC manufacturing. Many ideas were implemented under their guidance, but, I must admit it with great shame, without fully knowing what I was doing. Now that I'm going through the whole process, everything is making sense and clicking into place.
Also a lot of subjects, that I was aware already, such as tolerance, dogbones, nesting, etc. now required some thought from me. This didn't result into actual coding, but rather on design strategies. FreeCAD proves to be an amazing tool to work with these panel constructions, you can take high advantage of parametric objects. To give you a small example, all the holes are parametric. Changing a hole (adding dogbones) requires you to only change one hole to adapt the whole project.
All the generation of DXF cut profiles is automatic. The only missing part is automatic nesting, which is not easy. The only open-source app I found that can do nesting is SVGNest, unfortunately its code is very hard to adapt to FreeCAD. I'm currently studying it to try to understand how the algorithm works, and maybe try to rebuild it in FreeCAD.
Next step will be to generate the GCode directly from FreeCAD.
I am also working on a new version of the Start Center:
I will finish with adding here a couple of ideas I had while talking with other users, that I'm currently working on or will attack one way or another in the coming weeks:
At the beginning of this year I was complaining that the economical crisis in Brazil was making things hard here, and guess what, now we have so much work coming in that it got hard to find time for FreeCAD! This is something normal when you are working free-lance, it is always a roller coaster, but now thanks to my Patreon campaign there is a growing piece of stability in the balance, I need to find better ways to equalize everything. But it is really thrilling.
Also since a couple of months I got a major contribution from AlephObjects, the makers of the famous Lulzbot 3D printers. They are sponsoring not only me but a wide selection of people and open-source projects related to 3D and 3D printing (they are a major contributor to Blender). These guys are carrying on their shoulders a pretty big part of the open-source 3D world!
It would really be great to see more companies involved in supporting open-source projects development. For a company, supporting a project or a developer is a rather small investment, and is a much, much cheaper and interesting way to spend money than paying expensive monthly licenses to a software company just to be able to use their software.
By supporting the development of an open-source project, even with a small amount of money, a company would probably already have a big say in the development and be able to obtain features they need way faster than waiting for a software company to decide to implement them. Also, unlike when you are renting a software license, development and formation go hand in hand. Software companies might offer training programs, but it is always a short-term thing, while getting involved in an open-source project creates a much deeper, long-lasting and sustainable relationship between the company and the software, where training and learning and new features/versions is not just a service you buy once (and everybody who worked in a company knows that both these things wear off quite fast), but a permanent feature.
Okay that was my little minute of publicity, if you are a company, be as cool as AlephObjects, sponsor me!
Now back to real news. This month I have been working mostly on small things, bug fixing, and small user experience improvements throughout FreeCAD.
Several applications (AutoCAD-based apps, Sketchup) have this "hold" system where you hover the mouse over a point for a certain time, then the software "remembers" that point and offers you new snap locations for it. Call me crazy, but I always got a bit annoyed with the fact that you have to wait a second or so with your mouse stopped, in the middle of a fast operation like drawing a polyline.
So I thought, why not let the user insert those hold points manually, wherever and whenever (s)he wants? It is now implemented, and it works pretty well: Press Q anytime, while drawing, to add such a hold point. New snap locations will become available orthogonally to that point, and at their crossings if you have more than one. This is really fast, and can easily be extended further.
This was a long-time issue, but it's finally done. When importing DAE and OBJ files (using the Arch OBJ importer), object color and transparency will be correctly rendered in FreeCAD.
When exporting to these formats, if the object has a material attached to it (currently only Arch and FEM objects can have a material), color and transparency will be taken form the material. If not, they will be taken from the object itself.
This makes exporting your architecture models to Blender for rendering much more comfortable, since all materials will be already there in Blender (same material/color in FreeCAD will create a same material entry in the OBJ or DAE file, and therefore in Blender).
@sliptonic recently released an impressive video showing how the Path module could use the Arch Panels objects. We worked further on this, and added a series of improvements that pave the road to be able to comfortably build a model such as a wikihouse in FreeCAD, and be able to create, fine-tune and export g-code directly from it.
Small things have been fixed such as bugs in the DXF importer, small improvements to the object link dialog, the ability to define which wire of a window will cut the hole in its host wall, and bugs in the scaling of TechDraw views.
A couple of Arch utility tools, as well as the new Sketchfab exporter, have also been moved out of the FreeCAD source code, and are now in a new, separate WebTools. This will allow to bundle in that workbench a series of additional python modules related to web operations, that would be annoying to bundle in FreeCAD itself. This will make it much easier to install, and thanks to the new built-in Addons manager in FreeCAD, installing external workbenches has now become a piece of cake.
I also developed a new addon workbench to use CAD Exchanger to add support to several new file formats such as Rhino's .3DM or ACIS .SAT (which allows you to export Revit families to FreeCAD!). CAD Exchanger is a paid application, but I believe there could be a good synergy there, especially if they support more commercial file formats (also dreaming of decent 3D DWG support? Lobby them!), that are beyond the reach of an open-source project. And paying for a plugin to add commercial formats support to our favorite open-source app is something I would have no problem with, certainly I'm not the only one. Let's hope this synergy will flourish.
I have a large list of major features that I want to implement in FreeCAD and Arch, I've been talking about most of them in the previous development news, but these are all issues that require a lot of thinking, for example xrefs or walls. Very often I get comments like, why don't you make it work like in Revit (or ArchiCAD, or -name your favorite software here-). The thing is, you can rush and implement an interface quite quickly. But the really important part is not what the user sees or does, it's the underlying structure. If you design some user interface on top of a badly designed data structure, sooner or later you will get yourself limited by the limitations of your data structure. And it will be very hard to get around it if you designed a user interface already. But when you have a well designed structure, adding a good user interface on top of it is easy.
We had this discussion recently about the reinforcing bars tool in FreeCAD. It needs a better interface, that is obvious, but, more important, the reinforcing bar system behind it must be robust and flexible enough to be able to support any kind of crazy situations such as, for example, non-uniform (spline-based) curved walls. If we don't have that, sooner or later our model will fail to address a certain issue.
Then when we have such a powerful system, designing a user interface on top of it, which allows you to, for example, click a column and automatically place a series of reinforcing bars by just specifying a couple of parameters in a nice dialog box is much easier. And if you need a case that the dialog box cannot do, the underlying model can do it. You can still write a small python script that will solve the problem.
That development philosophy is at the deep roots of FreeCAD. Often newcomers complain about the lack of user-friendliness of the FreeCAD interface. But we use to think that there is a right order in software design: First make sure your base structures are powerful and flexible, then design the interface for it.
The interesting aspect is that I think we are entering a kind of new epoch in FreeCAD. Many parts of it are now pretty robust, flexible and stable. And there is a series of new developers coming in, interested in working on the interface side of things. This is also a very precise and long-term work, there is no magical solution, UI-wise. Everything is a question of testing, seeing what works best and what users like (an indication that it works well), and refining.
By the way, have you seen the revamped icons that @agryson has been working on? Also, don't forget that FreeCAD also support color and icon themes, thanks to the hard work of @wmayer and @pablogil...
Sorry for that long diversion, but there is quite some time I wanted to explain better that thing, "why FreeCAD still hasn't a better user interface". We'll get there, but first things first.
About the other major features I am still exploring and didn't find a good attack path yet:
Xrefs: I think we are close to something there (see the discussion ). I was first thinking to start with something hybrid with different "modes" where you can either make it insert, in the current document, a full copy of all the objects of the references document, with all its properties, or just a "condensed" view of those objects, but the digital project approach is totally doable and seems much more interesting.
Walls: Two things are becoming highly necessary: Support for more complex, multi-layer walls, and a more powerful system to join walls. Note that both these things are possible and working already, but the system is still a bit cumberstone. Multilayer walls is the easiest one to solve, what we need there is probably a kind of "super-wall" object, that would hold the different wall layers. The auto-joining is a more delicate issue. Currently, joining two walls makes them turn into one. But that's not cool, we need to be able to still manipulate these walls independently. Most apps do tricks to make them look like they are joined, but they are still independent objects. But I still didn't find a good idea to do that in FreeCAD.
Types: As I was writing in an earlier post, In Revit the concept of individual object almost doesn't exist. Everything is part of families (communism?). In FreeCAD, the individual object is king. Relationships exist between one and another, but the concept of a "family" is very shallow. However, working with families and types in Revit is really good. I'd like to introduce that more in the Arch workbench, and make objects more dependent on some more general definitions. However, how to do that without loosing the precious individuality, which gives a lot of freedom that Revit doesn't have? No clear idea yet.
Sorry for that long read once again, hope you enjoyed, and I'll try to find ways to manage my time better next month! Don't forget you can help me to spend more time working on FreeCAD by sponsoring me on Patreon.
Also, have a look on our ongoing wikihouse-based project in Brasil, be sure to have a look at the FreeCAD files!
FYI, the image above has been heavily reworked in inkscape, but the sheet is originally exported from FreeCAD.
Last couple of weeks I've had the opportunity to do some work in Revit. This was highly welcome as my knowledge of that application was becoming rather obsolete. Having a fresh, new look on it brought me a lot of new ideas, reinforced some ideas I already had, and changed a couple of old perceptions too. So I cannot resist the temptation to do a little comparison between Revit and FreeCAD.
For who is not used to this blog, you must be warned that I am one of the developers of FreeCAD, and therefore my opinions here cannot be anything else than strongly biased. But for the sake of the exercise, I'll do my best to keep as neutral as possible, and look only at the technical side (I won't mention all the open source side of things).
The most important point I think, is that both pieces of software are surprisingly more similar than we use to think. Working in your spare time on a small open source project, and getting bashed all over the internet about how perfect Revit is, you end up thinking your humble work is phenomenally behind what thousands of Autodesk programmers can produce. It turns out that's a pretty wrong perception, I think. Both have their strengths and weaknesses, but FreeCAD comes out surprisingly well compared to Revit, and is actually better in many areas.
I'll start with what is similar in both apps. Both are fundamentally based on constrained sketches, that is, 2D shapes where you can put constraints (radius, length, etc), that you extrude to form 3D objects. Other extruded 2D shapes can then be used in boolean operations (union or subtractions) to produce the final object. So, very fundamentally, the modelling process in Revit is not very different than FreeCAD. In both apps, you'll find these profiles everywhere, underneath almost any object.
Both applications use reference planes to draw onto. In FreeCAD, there are several modalities depending on the workbench, but the concept is the same: You define a work plane, which is a plane in the 3D space, then you draw your 2D shapes on that plane, then you extrude.
The higher-level objects, like walls, structures, windows, etc... are in both applications convenience wrappers around these basic modelling tools. It would be a hassle to have to draw every outline of every wall you need in your project, so the wall tool does that for you, you just need to draw the baseline of the wall, and the whole modelling operation (make the 2D contour + extrusion) is performed automatically for you, and performed again every time you change something to the wall definition.
All the rest, that makes a full BIM application, is basically extensions around this modelling "core". It also surprised me how little the Revit core has been modified over the years. All the new features of these recent years are in that area around the core, not the core itself. This is not necessarily a bad thing, when you think of it, BIM work is composed of a very big part of theses things that are not solely 3D modelling.
The bad sides of both applications are also surprisingly similar, and, even more surprising to me, equal in number and annoyance. In FreeCAD, due to its young age, and the fact that there is too little work spent on the BIM module (don't forget you can help me to remedy the problem!), all kinds of shortcomings, limitations and incomplete features cross your path all the time. Fortunately you can work around these most of the time, and your ability to find and use these workarounds grows with your FreeCAD experience, up to a point that it doesn't annoy you anymore. That typically happens with all FreeCAD developers, so it's important that new users report the problems they encounter.
In Revit, my impression is that you basically encounter the same amount of annoyance. My even deeper impression (a secret I won't hesitate to reveal to you now, exclusively!) is that in the perfect world of Revit, where "everything works", so to speak, programmers are extremely reticent to add anything that could "stain" that perfect model. So all kind of external, hybrid, workaround features are vetoed or minimally implemented because they couldn't avoid, but highly discouraged.
But, more useful than the rant, I also made a list of points that I found good in both applications, with the obvious idea to gather things to improve in FreeCAD.
So no more shame, let's claim it loud, yes, FreeCAD is as good as Revit! "As good as" doesn't means "the same", though, and their philosophy and workflows are very different. Revit will give you more comfort and speed, FreeCAD will give you more freedom. I don't know if we'll ever reach the comfort level of Revit (I'm not convinced that it wouldn't force us into options that would harm the freedom side), but on the question of speed, there is still a lot to be done, no doubt we'll still see huge improvements in that regard.
I took note of a series of small things I'll try to fix or add in FreeCAD, but also identified these more generic areas that I'll try to improve in FreeCAD:
PS - Half the stuff on the images in this post was done by Ryan
I'll start adding a date to these "Arch development news", it will be easy to look back and motivate me to write them more regularly. A monthly report seems good I think, no?
Long time I didn't write, but that doesn't mean things have been quiet down here, it's actually more the contrary. To begin with, I've had the opportunity to do a job with Revit. There was a long time that I didn't really use Revit intensively, so this was a great opportunity to get back on track with it. I gathered a lot of observations, ideas, and things that compare quite favourably to FreeCAD (favourably for FreeCAD of course ). This is too long to put here, but I have written another post specifically about that, that I'll publish later this week.
I also collected a long list of Revit rants, but since a lot of people are doing that all over the net already, my article will rather concentrate on the positive points I found in both apps.
Now the ideal would be to get an ArchiCAD job! Anyone has an ArchiCAD job for me?
I've otherwise been working on a couple of own projects directly in FreeCAD, and implemented a couple of new features o the way:
This is not only mine but a real teamwork. Finally we have a simple but functional tool inside FreeCAD to install external workbenches and macros. No more need to go to the web, download and install, all this is done directly from within FreeCAD. Installing workbenches will still require you to restart FreeCAD, and it's currently still not very enjoyable to browse and explore available addons, but we're working on it.
In Revit, objects can display 3 levels of complexity: coarse, medium and fine. For each of these levels, you can define geometry that must appear or not. So for example, you can have a sink object that is made of a box and a more detailed curved geometry. Then you set the box to only appear in coarse mode, and the other geometry to appear in medium and fine.
In FreeCAD I now implemented a similar concept. It is still in test, so it might change depending on what people think of it and how it resists day-to-day use. Basically, each Arch object now has a new "Hi Res" property which is a link that can point to another object. They now also have a "Hi Res" display mode. If you set the display mode of the object to "Hi Res", and the object has its Hi Res property set, the geometry of the HiRes object is displayed, instead of its own. This happens entirely at the 3D view level, so the Arch object keeps its own shape. It only displays another. But selection still works, inside the 3D view you don't see that it's not the real shape of the Arch object.
Of course so far other tools and workbenches (TechDraw, etc) are unaware of this, and will continue to look for the objects shape. But if the system works well, it will be easy to simply use the Hi Res shape instead, if present.
So this is not Revit's (or ArchiCAD's) coarse/medium/fine system, but it seems to me that the cases where you really need three different levels are rare... And if three, why not four then. This systems seems much more flexible to me, you can basically use any shape/object (meshes too) as hi-res version of another, with all the possibilities and flexibility that this offers. And, if we need a third mode in the future, most of the work will be done already, it won't be much work to add it.
In the image above, the concrete blocks are the Hi-res version of the walls, and the wooden panels, with all their cuts, too. Check the whole file too (you will need a very recent version of FreeCAD).
There is a discussion thread about this feature on the forum, all ideas are welcome!
This system has another aim too: It paves the road for a pretty powerful external reference system we're currently thinking about (discussion thread here: Everybody used to Autodesk applications knows the X-Ref system: You have a file, and you embed it into another file. However, if you know this, you probably also know the bad side: If you embed a couple of heavy files, your "master" files becomes quickly unbearably slow. People coming from the mech engineering world, and software like Solidworks or Catia know another way: You cannot simply embed any file into any other. You need to prepare the base file somehow, either by organizing your objects inside somehow or by saving it under another file type, the methods differ.
But this could give way to an amazing idea, that JÃ¼rgen (FreeCAD's idealist and godfather) emitted several years ago already, and that is not even ours, since it has for example been implemented in Digital Project. Anyway, in the software world, as in all the culture world, nothing is really only your idea. It's always something that travels... Okay okay, the amazing idea: When embedding a file, instead of bringing the whole contents into the host file, you would only bring a lightweight version, or a "ghost" of it. In FreeCAD terms, that would mean only importing the OpenInventor representation of the objects contained in the file, which is what the 3D view of FreeCAD is made of. In other terms, you would bring only the 3D representation, not the BRep geometry.
Without the BRep geometry, you can go very far. The 3D view of FreeCAD can display several millions of polygons without problems on an average system, and keep everything pretty fluid. In the case of BIM, this could probably allow to display huge and complex buildings with all their details. All the heavy calculations would be left in the embedded file, and not be used in the host file.
But the OpenInventor representation is currently not stored in FreeCAD files (it is calculated by the engine on-the-fly). We need to find a way to store it, so another file could just load that representation, and nothing else, without the need to calculate it.
The easiest way seems to be the PartDesign way: You place all your geometry inside a "body" object, which stores a copy of the OpenInventor representation of its contents. When you load the file from somewhere else, you could just load that representation, and you would get a lightweight copy of the body contents.
Of course. that's the plan with PartDesign. But on the Arch side, we have an opportunity to do some testing quicker than there, firstly because Arch is programmed in Python, which makes it much easier to experiment, and secondly because less people are using it, so we need to be less careful, it's not such a big problem if we suddenly break something. And it happens a lot in FreeCAD, that some features are tested and tuned in Python first, and then some day become fast, rock-solid C++ features.
So that's the plan, and the Hi-Res system was a first step in playing with these concepts, now the way is open to try to play with external files too.
Do you know SketchFab? It is a platform where you can upload 3D models and view them inside a web browser, without flash or any other plugin (it uses webGL which is now built in all major browsers). SketchFab has free and paid accounts, and although the platform is not open-source, the team behind it is very friendly to open-source projects (some people behind it actually come from the Blender community). I begin to use SketchFab more and more, because it is very easy to show models and ideas to clients with it, without having to make them install software.
So this week I [coded an exporter] for it, which now lives in the Web workbench of FreeCAD. All it requires is to create an account on SketchFab, select the objects to upload, give a name and a description, and press a button. SketchFab has a pretty good built-in scene and material editor that allows you to fine-tune your model afterwards.
The exporter offers your several formats to export to, the one that works best for BIM models is the OBJ + MTL, because it will carry better materials info, but there is one mode that is particularly interesting which is the .iv (OpenInventor) mode, that literally sends to SketchFab a copy of the 3D view of FreeCAD, which gives very nice results:
So this could become a very good way to showcase your FreeCAD models to people who don't have FreeCAD.
Recently I had to work with models with a lot of non-orthogonal planes to work in. It is always when you have to eat your own dogfood that you become painfully aware of the shortcomings. Switching workplanes is very quick already, select a face, press "WP" and it's done, but there were two problems: first there is no way to set your view perpendicularly to the current working plane, which is often useful, and, if you choose one of the ortho planes (XY, XZ or YZ) very far from the model origin point, you won't see the grid.
So one thing I added is a checkbox in the "Select Plane" dialog to recenter the grid to the center of the current view. And another little utility is a macro to Align the view to the currnt working plane. If you install that macro (which is now easy with the addons manager!) and give it a keyboard shortcut, the workflow becomes very good: Select a face, press WP, then press the key you used as a shortcut for the macro, and you find yourself looking perpendicularly to your working plane. If you have the Snap to Working plane button on, then you are really working in a perfect 2D environment, like in the Sketcher.
The different Draw Styles of the FreeCAD 3D view have also received keyboard shortcuts, and Werner added two more modes. One of them, named "shadeless", gives actually very nice "hidden lines" aspect, you would almost think you're in Revit!
Don't forget you can help me spending more time working on FreeCAD, by sponsoring me on Patreon. Every dollar is a little more time I can dedicate to it!
As the tradition dictates, I put a couple of images of what I'm working on at the moment:
ogr2ogr -f "dxf" contours-lambert.dxf contours-lambert.shp -zfield ELEV
import Part,ReverseEngineering obj = FreeCAD.ActiveDocument.getObject("Points") Part.show(ReverseEngineering.approxSurface(obj.Points,NbUPoles=16,NbVPoles=16).toShape())
|Revit||R$ 20 853,27||Vende direto no site da Autodesk. Existe uma versÃ£o LT mas que nÃ£o vendem no Brasil.|
|ArchiCAD||R$ 24 951,90||NÃ£o vende diretamente no Brasil. Este Ã© o preÃ§o na Europa. Tem uma versÃ£o â€œsoloâ€ para metade do preÃ§o.|
|AllPlan||R$ 23 195,70||NÃ£o vende diretamente no Brasil, este Ã© o preÃ§o na Europa.|
|Digital project||R$ 30 000,00+||NÃ£o vende diretamente no Brasil nem online. PreÃ§o nÃ£o divulgado, mas bem acima dos R$ 30 000.|
|Vectorworks||R$ 9 037,35||NÃ£o vende diretamente no Brasil, este Ã© o preÃ§o nos USA.|
|Microstation Architecture||R$ 24 273,70||NÃ£o vende diretamente no Brasil. PreÃ§o do antigo microstation + triforma, agora vendido como um software sÃ³ (Bentley architecture)|
|4M IDEA PRO||R$ 1 044,65||Vende direto do site da 4MSA.|
|Softtech Spirit||R$ 21 667,30||NÃ£o vende diretamente no Brasil nem online.|
|RhinoBIM||R$ 6 582,11||Vende direto do site. PreÃ§o do Rhino + RhinoBIM.|
|Sketchup PRO||R$ 2 437,82||Vende direto no site.|
|ProgeCAD Architecture||R$ 6 149,00||Vende direto no site.|
|VisualARQ||R$ 5 189,07||Vende direito no site. PreÃ§o do Rhino + VisualARQ.|
This tutorial aims at giving you the basics to work with the Arch Workbench. I will try to make it simple enough so you don't need any previous experience with FreeCAD, but having some experience with 3D or BIM applications will be useful. In any case, you should be prepared to look for yourself for further information about how FreeCAD works on the FreeCAD documentation wiki. The Getting started page is a must read, if you have no previous experience with FreeCAD. Also check our tutorials section, and on youtube you will also find a lot more of FreeCAD tutorials.
The purpose of the Arch Workbench is to offer a complete BIM workflow inside FreeCAD. As it is still under development, don't expect to find here the same tools and level of completion as grown-up commercial alternatives such as Revit or ArchiCAD, but on the other hand, FreeCAD being used in a much bigger scope than these applications, the Arch Workbench greatly benefits from the other disciplines FreeCAD caters to, and offers some features rarely seen in traditional BIM applications.
Here are, for example, a couple of interesting features of FreeCAD's Arch Workbench that you'll hardly find in other BIM apps:
At the time I'm writing this, though, the Arch Workbench, as the rest of FreeCAD, suffers some limitations. Most are being worked on, though, and will disappear in the future.
This tutorial was written using FreeCAD version 0.14. You will need at least this version number in order to follow it. Earlier versions might not contain all the needed tools,or they could lack options presented here.
The Arch Workbench is mainly made for two kinds of workflows:
In this tutorial, we will model the house in 3D, based on the 2D drawings we'll download from the net, and extract from it 2D documents, such as plans, elevations and sections.
Instead of creating a project from scratch, Let's take an example project to model, it will save us time. I chose this wonderful house by the famous architect Vilanova Artigas (see a series of pictures by Pedro Kok), because it is close to where I live, it is simple, it's a wonderful example of the amazing modernist architecture of São Paulo (it is even for sale if you have "a few" Reals to spend), and dwg drawings are easily available.
We will use the 2D DWG drawings obtained from the link above (you need to register to download, but it's free) as a base to build our model. So the first thing you'll want to do is to download the file, unzip it, and open the DWG file inside with a dwg application such as DraftSight. Alternatively, you can convert it to DXF with a free autility such as the Teigha File Converter. If you have the Teigha converter installed (and its path set in the Arch preferences settings), FreeCAD is also able to import DWG files directly. But since these files can sometimes being of bad quality and very heavy, it's usually better open it first with a 2D CAD application and do some cleaning.
Here, I removed all the detail drawings, all the titleblocks and page layouts, did a "clean" ("purge" in AutoCAD slang) to remove all unused entities, reorganized the sections at a logical location in relation to the plan view, and moved everything to the (0,0) point. After that, our file can be opened quite efficiently in FreeCAD. Check the different options available in Edit -> Preferences -> Draft -> Import/Export, they can affect how (and how quickly) DXF/DWG files are imported.
This is how the file looks after being opened in FreeCAD. I also changed the thickness of the walls (the contents of the "muros" group), and flipped a couple of doors that were imported with wrong X scale, with the Draft Scale tool:
The DXF importer (which also takes care of DWG files, since when importing DWG files, they are simpl converted to DXF first), groups the imported objects by layer. There is no layer in FreeCAD, but there are groups. Groups offer a similar way to organize the objects of your files, but don't have specific properties, like AutoCAD layers, that apply to their contents. But they can be placed inside other groups, which is very handy. The first thing we might want to do here, is to create a new group (in the tree view, right-click on the document icon, add a group, right click on it to rename it as "base 2D plans", and drag and drop all the other objects into it.
Like most Arch objects, walls can be built upon a big variety of other objects: lines, wires (polylines), sketches, faces or solid (or even on nothing at all, in which case they are defined by height, width and length). The resulting geometry of the wall depends on that base geometry, and the properties you fill in, such as width and height. As you might guess, a wall based on a line will use that line as its alignment line, while a wall based on a face will use that face as its base footprint, and a wall based on a solid will simply adopt the shape of that solid. This allows about any shape imaginable to become a wall.
There are different possible strategies to build walls in FreeCAD. One might want to build a complete "floor plan" with the sketcher, and build one, big, wall object from it. This technique works, but you can only give one thickness for all the walls of the project. Or, you can build each piece of wall from separate line segments. Or, this is what we will do here, a mix of both: We will build a couple of wires on top of the imported plan, one for each type of wall:
As you see, I've drawn in red the lines that will become concrete walls (a pictures search of the house can help you to see the different wall types), the green ones are the exterior brick walls, and the blue ones will become the inner walls. I passed the lines through the doors, because doors will be inserted in the walls later, and will create their openings automatically. Walls can also be aligned left, right or centrally on their baseline, so it doesn't matter which side you draw the baseline. I also took care on avoiding intersections as much as I could, because our model will be cleaner that way. But we'll take care of intersections later.
When this is done, place all those lines in a new group if you want, select each line one by one, and press the Arch Wall tool to build a wall from each of them. You can also select several lines at once. After doing that, and correcting widths (exterior walls are 25cm wide, inner walls are 15cm wide) and some alignments, we have our walls ready:
We could also have built our walls from scratch. If you press the Arch Wall button with no object selected, you will be able to click two points on the screen to draw a wall. But under the hood, the wall tool will actually draw a line and build a wall on it. In this case, I found it more didactic to show you how things work.
Did you notice that I took great care not to cross the walls? this will save us some headache later, for example if we export our work to other applications, that might not like it. I have only one intersection, where I was too lazy to draw two small line segments, and drew one big wire crossing another. This must be fixed. Fortunately, all Arch objects have a great feature: you can add one to another. Doing that will unite their geometries, but they are still editable independently after. To add one of our crossing walls to the other, just select one, CTRL + select the other, and press the Arch Add tool:
On the left is are the two intersecting walls, on the right the result after adding one to the other.
Something is important to consider already. As you can see, in FreeCAD, everything is parametric: Our new "united" wall is made from two walls, each based on a baseline. When you expand them in the tree view, you can see all that chain of dependencies. As you can imagine, this little game can quickly become very complex. Furthermore, if you already know how to work with the sketcher, you might have wanted to draw the baselines with constrained sketches. This whole complexity has a cost: it raises exponentially the number of calculations that FreeCAD has to perform to keep your model geometry up to date. So, think about it, don't add unnecessary complexity when you don't need it. Keep a good balance between simple and complex objects, and keep these for the cases where you really need them.
For example, I could have drawn all my baselines above without caring about what crosses what, and fix things with the Arch Add tool later. But I would have raised much the complexity of my model, for no gain at all. Better make them correct right from the start, and keeping them as very simple pieces of geometry.
Now that our walls are okay, we need to raise their height, until they intersect the roof. Then, since the wall object still cannot be cut automatically by roofs (this will happen some day, though), we will build a "dummy" object, that follows the shape of the roof, to be subtracted from our walls.
First, by looking at our 2D drawings, we can see that the highest point of the roof is 5.6m above the ground. So let's give all our walls a height of 6m, so we make sure they will be cut by our dummy roof volume. Why 6m and not 5.6m? You may ask. Well, if you already worked with boolean operations (additions, subtractions, intersections), you must already know that these operations usually don't like much "face-on-face" situations. They prefer clearly, frankly intersecting objects. So by doing this, we keep on the safe side.
To raise the height of our walls, simply select all of them (don't forget the one we added to the other) in the tree view, and change the value of their "height" property.
Before making our roof and cutting the walls, let's make the remaining objects that will need to be cut: The walls of the above studio, and the columns. The walls of the studio are made the same way as we did, on the superior floor plan, but they will be raised up to level 2.6m. So we will give them the needed height so their top is at 6m too, that is, 3.4m. Once this is done, let's move our walls up by 2.6m: Select them both, put yourself in frontal view (View -> Standard Views -> Front), press the Draft Move button, select a first point, then enter 0, 2.6, 0 as coordinates, and press enter. Your objects now have jumped 2.6m high:
The Draft objects, and most Arch objects too, obey to a Draft system called working planes. This system defines a 2D plane where next operations will take place. If you don't specify any, that working plane adapts itself to the current view. This is why we switched to frontal view, and you see that we indicated a movement in X of 0 and in Y of 2.6. We could also have forced the working plane to stay on the ground, by using the Draft SelectPlane tool. Then, we would have entered a movement of X of 0, Y of 0 and Z of 2.6.
Now let's move our walls horizontally, to their correct location. Since we have points to snap to, this is easier: Select both walls, press the Draft Move tool, and move them from one point to the other:
Finally, I changed the color of some walls to a brick-like color (so it's easier to differentiate), and made a small correction: Some walls don't go up to the roof, but stop at a height of 2.60m. I corrected the height of those walls.
Now, since we'll have to cut our walls with a subtraction volume, we might as well see if there aren't other objects that will need to be cut that way. There are, some of the columns. This is a good opportunity to introduce a second arch object: the Arch Structure. Structure objects behave more or less like walls, but they aren't made to follow a baseline. Rather, their prefer to work from a profile, that gets extruded (along a profile line or not). Any flat object can be a profile for a structure, with only one requirement: they must form a closed shape.
For our columns, we will use another strategy than with the walls. Instead of "drawing" on top of the 2D plans, we will directly use objects from it: the circles that represent the columns in the plan view. In theory, we could just select one of them, and press the Arch Structure button. However, if we do that, we produce an "empty" structural object. This is because you can never be too sure at how well objects were drawn in the DWG file, and often they are not closed shapes. So, before turning them into actual columns, let's turn them into faces, by using the Draft Upgrade tool twice on them. The first time to convert them into closed wires (polylines), the second time to convert those wires into faces. That second step is not mandatory, but, if you have a face, you are 100% sure that it is closed (otherwise a face cannot be made).
After we have converted all our columns to faces, we can use the Arch Structure tool on them, and adjust the height (some have 6m, other only 2.25m height):
On the image above, you can see two columns that are still as they were in the DWG file, two that were upgraded to faces, and two that were turned into structural objects, and their height set to 6m and 2.25m.
Note that those different Arch objects (walls, structures, and all the others we'll discover) all share a lot of things between them (for example all can be added one to another, like we already saw with walls, and any of them can be converted to another). So it's more a matter of taste, we could have made our columns with the wall tool too, and converted them if needed. In fact, some of our walls are concrete walls, we might want to convert them to structures later.
Now it is time to build our subtraction volume. The easiest way will be to draw its profile on top of the section view. Then, we will rotate it and place it at its correct position. See why I placed the sections and elevations like that before beginning? It will be very handy for drawing stuff there, then moving it to its correct position on the model.
Let's draw a volume, bigger than the roof, that will be subtracted from our walls. To do that, I drew two lines on top of the base of the roof, then extended them a bit further with the Draft Trimex tool. Then, I drew a wire, snapping on these lines, and going well above our 6 meters. I also drew a blue line on the ground level (0.00), that will be or rotation axis.
Now is the tricky part: We will use the Draft Rotate tool to rotate our profile 90 degrees up, in the right position to be extruded. To do that, we must first change the working plane to the YZ plane. Once this is done, the rotation will happen in that plane. But if we do like we did a bit earlier, and set our view to side view, it will be hard to see and select our profile, and to know where is the basepoint around which it must rotate, right? Then we must set the working plane manually: Press the Draft SelectPlane button (it is in the "tasks" tab of the tree view), and set it to YZ (which is the "side" plane). Once you set the working plane manually, like that, it won't change depending on your view. You can now rotate your view until you have a good view of all the things you must select. To switch the working plane back to "automatic" mode later, press the Draft SelectPlane button again and set it to "None".
Now the rotation will be easy to do: Select the profile, press the Draft Rotate button, click on a point of the blue line, enter 0 as start angle, and 90 as rotation:
Now all we need to do it to move the profile a bit closer to the model (set the working plane to XY if needed), and extrude it. This can be done either with the Part Extrude tool, or Draft Trimex, which also has the special hidden power to extrude faces. Make sure your extrusion is larger than all the walls it will be subtracted from, to avoid face-on-face situations:
Now, here comes into action the contrary of the Arch Add tool: Arch Remove. As you might have guessed, it also makes an object a child of another, but its shape is subtracted from the host object, instead of being united. So now things are simple: Select the volume to subtract (I renamed it as "Roof volume to subtract" in the tree view so it is easy to spot), CTRL + select a wall, and press the Arch Remove button. You'll see that, after the subtraction happened, the volume to subtract disappeared from both the 3D view and the tree view. That is because it has been marked as child of the wall, and "swallowed" by that wall. Select the wall, expand it in the tree view, there is our volume.
Now, select the volume in the tree vieew, CTRL + select the next wall, press Arch Remove. Repeat for the next walls until you have everything properly cut:
Arch objects that support such additions and subtractions (all of them except the "visual" helper objects such as the axes) keep track of such objects by having two properties, respectively "Additions" and "Subtractions", that contains a list of links to other objects to be subtracted or added. A same object can be in thr lists of several other objects, as it is the case of our subtraction volume here. Each of the fathers will want to swallow it in the tree view, though, so it will usually "live" in the last one. But you can always edit those lists for any object, by double-clicking it in the tree view, which in FreeCAD enters edit mode. Pressing the escape key exits edit mode.
Now, all we have to do to complete the structure, is to make the roof and the smaller inner slabs. Again, the easiest way is to draw their profiles on top of the section, with the Draft Wire tool. Here I drew 3 profiles on top of each other (I moved them apart in the image below so you see better). The green one will be used for the lateral borders of the roof slab, then the blue one for the side parts, and the red ones for the central part, that sits above the bathroom block:
Then, we must repeat the rotation operation above, to rotate the objects in a vertical position, then move them at their correct places, and copy some of them that will need to be extruded twice, with the Draft Move tool, with the ALT key pressed, which creates copies instead of moving the actual object. I also added two more profiles for the side walls of the bathroom opening.
After that, we can see some problems arising: two of the columns on the right are too short (they should go up to the roof), and there is a gap between the slab and the walls of the studio on the far right (the 2.60 level symbol on the section view was obviously wrong). Thanks to the parametric objects, all this is very easy to solve: For the columns, just change their height to 6m, fish your roof subtraction volume from the tree view, and subtract it to the columns. For the walls, it's even easier: move them a bit down. Since the subtraction volume continues at the same place, the wall geometry will adapt automatically.
Now one last thing must be fixed, there is a small slab in the bathroom, that intersects some walls. Let's fix that by creating a new subtraction volume, and subtract it from those walls. Another feature of the Draft Trimex tool, that we use to extrude stuff, is that it can also extrude one single face of an existing object. This creates a new, separate object, so there is no risk to "harm" the other object. So we can select the base face of the small slab (look at it from beneath the model, you'll see it), then press the Draft Trimex button, and extrude it up to well above the roofs. Then, subtract it from the two inner bathroom walls with the Arch Remove tool:
Now, our structure is complete, we just have a couple of smaller objects to do.
Let's start with the chimney. Now you already know how it works, right? Draw a couple of closed wires, move them up at their correct height with the Draft Move tool, extrude them with the Draft Trimex tool, turn the bigger one into a structure, and subtract the smaller ones. Notice how the chimney tube wasn't drawn on the plan view, but I found its position by dragging blue lines from the section views.
The floors are not well represented in the base drawings. When looking at the sections, you cannot know where and how thick the floor slabs are. So I will suppose that the walls are sitting on top of foundation blocks, at level 0.00, and that there are floor slabs, also sitting on those blocks, 15cm thick. So the floor slabs don't run under the walls, but around them. We could do that by creating a big rectangular slab then subtracting the walls, but remember, subtraction operations cost us. Better do it in smaller pieces, it will be "cheaper" in terms of calculation, and also if we do it intelligently, room by room, these will also be useful to calculate floor areas later:
Once the wires are drawn, just turn them into structures, and give them a height of 0.15:
Now the stairs. Met the next of the Arch tools, the Arch Stairs. This tool is still in a very early stage of development, at the time I'm writing, so don't expect too much of it. But it is already pretty useful to make simple, straight stairs. One concept is important to know, the stairs tool is thought to build stairs from a flat floor up to a wall. In other words, when viewed from the top, the stairs object occupies exactly the space that it occupies on the plan view, so the last riser is not drawn (but it is of course taken into account when calculating heights).
In this case, I preferred to build the stairs on the section view, because we'll need many measurements that are easier to get from that view. Here, I drew a couple of red guidelines, then two blue lines that will be the base of our two pieces of stairs, and two green closed wires, that will form the missing parts. Now select the first blue line, press the Arch Stairs tool, set the number of steps to 5, the height to 0.875,the width to 1.30, the structure type to "massive" and the structure thickness to 0.12. Repeat for the other piece.
Then, extrude both green wires by 1.30, and rotate and move them to the right position:
On the elevation view, draw (then rotate) the border:
Then move everything into place:
Don't forget also to cut the column that crosses the stairs, because in BIM it's always bad to have intersecting objects. We are building like in the real world, remember, where solid objects cannot intersect. Here, I didn't want to subtract the column directly from the stairs (otherwise the column object would be swallowed by the stairs object in the tree view, and I didn't like that), so I took the face on which the column was built, and extruded it again. This new extrusion was then subtracted from the stairs.
Right! All the hard work is now done, let's go on with the very hard work!
Arch Windows are pretty complex objects. They are used to make all kinds of "inserted" objects, such as windows or doors. Yes, in FreeCAD, doors are just a special kind of window. In real life too, if you think of it, no? The Arch Window tool can still be a bit hard to use today, but consider this as a tradeoff, as it was built for maximum power. Almost any kind of window your imagination can produce can be done with it. But as the tool will gain more presets, this situation will certainly become better in the future.
The Arch Window object works like this: It is based on a 2D layout (any 2D object, but preferably a sketch, that contains closed wires (polylines). These wires define the different parts of the window: outer frames, inner frames, glass panels, solid panels, etc. The window objects then has a property that stores what to do with each of these wires: extrude it, place it at a certain offset, etc. Finally, a window can be inserted into a host object such as a wall or structure, and it will automatically create a hole in it. That hole will be calculated by extruding the biggest wire found in the 2D layout.
There are two ways to create such objects in FreeCAD: By using a preset, or drawing the window layout from scratch. We'll look at both methods here. But remember that the preset method does nothing else than creating the layout object and defining the necessary extrusions for you.
When pressing the Arch Window tool with no object selected, you are invited either to pick a 2D layout, or to use one of the presets. Let's use the "Simple Door" preset to place the main entrance door of our model. Give it a width of 1m, a height of 2.45m, a W1 size of 0.15m, and leave the other parameters to 0.05m. Then click the lower left corner of the wall, and your new door is created:
You will notice that your new door won't appear in the tree view. That is because, by snapping to a wall, we indicated that wall as its host object. Consequently, it has been "swallowed" by the wall. But a right click on it -> Go to selection will find it in the tree.
In this case, as our window is not inserted in any wall (the opening was there already), we might as well detach our window from its host wall. This is done by double-clicking the host wall in the tree view to enter its edit mode. There, you will see the window in its "Subtractions" group. Simply select the window there, press the "remove element" button, then "OK". Our window has now been removed from its host wall, and lies at the bottom of the tree view.
We have a second door, exactly the same as this one, a bit on the left. Instead of creating a new door from scratch, we have two ways to make a copy of the previous one: By using the Draft Move tool, with the ALT key pressed, which, as you already know, copies an object instead of moving it. Or, even better, we can use the Draft Clone tool. The clone tool produces a "clone" of a selected object, that you can move around, but that retains the shape of the original object. If the original object changes, the clone changes too.
Now would be a good time to do a bit of housecleaning. Since we already have two windows, it is a good moment to do some cleaning in the tree view: Create a new group, rename it to "windows", and drop the 2 windows in it. I also recommend you to separate other elements that way, such as the walls and structures. Since you can also create groups inside groups, you can organize further, for example by placing all elements that form the roof into a separate group, so it is easy to turn on and off (turning a group visible or invisible does the same with all objects inside).
The Arch Workbench has some additional tools to organize your model: the Arch Site, Arch Building and Arch Floor. Those 3 objects are based on the standard FreeCAD group, so they behave exactly like groups, but they have a couple of additional properties. For example, floors have the ability to set and manage the height of the contained walls and structure, and when they are moved, all their contents are moved too.
But here, since we have only one building with only one (and a half) floor, there is no real need to use such objects, so let's stick with simple groups.
Now, let's get back to work. Turn off the roof group, so we can see better inside, and switch the Display Mode of the floor objects to Wireframe (or use the Draft ToggleDisplayMode tool) so we can still snap to them, but we can see the plan view underneath. But you can also turn off the floors completely, then place your doors at level 0, then raise them of 15cm with the Draft Move tool.
Let's place the interior doors. Use the "Simple Door" preset again, make doors of 1.00m and 0.70m wide x 2.10m high, with W1 size of 0.1m. Make sure you snap to the correct wall when you place them, so they automatically create a hole in that wall. If it is hard to place them correctly, you can place them at an easier location (at the corner of the wall, for example, then move them. The "hole" will move together.
If by mistake you hosted a window in the wrong wall, it is easy to fix: Remove the window from the "Subtraction" group of the host wall in edit mode, as we saw above, then add it to the "Subtraction" group of the correct wall, by the same method, or, simply, using the Arch Remove tool.
A little work later, all our doors are there:
After a closer look at the elevation view, I now detected another error: The top of the brick walls is not as 2.60m, but 17.5cm lower, that is, 2.425m. Fortunately, windows based on presets have a facility: You can alter their general dimensions (width and height) from their properties. So let's change their height to 2.425 - 0.15, that is, 2.275. The second window, as it is a clone of the first one, will adapt too. This is basically where the true magic of parametric design appears.
Now we can look at the really interesting stuff: How to design your own custom windows.
As I explained above, Arch Window objects are created from 2D layouts, made of closed elements (wires (polylines), circles, rectangles, anything). Since Draft objects cannot hold more than one of these elements, the preferred tool to draw window layouts is the Sketcher. Unfortunately, with the sketcher, it is not possible to snap to external objects like with the Draft workbench, which would be useful here, since our elevations are drawn already. Fortunately, a tool exists to convert Draft objects to a sketch: The Draft To Sketch tool.
So, let's start by building our first window layout. I drew it on the elevation, using several rectangles: One for the outer line, and 4 for the inner lines. I stopped before the door, because, remember, our door already has a frame there:
Then, select all the rectangles, and press the Draft To Sketch button (and delete the rectangles, because this tool doesn't delete the original objects, in case something goes wrong). Then, with the new sketch selected, press the Arch Window tool:
The tool will detect that the layout has one outer wire and several inner wires, and automatically proposes you a default configuration: One frame, made by subtracting the inner wires from the outer one, extruded by 1m. Let's change that, by entering the window's edit mode, by double-clicking on it in the tree view:
You will see a "Default" component, that has been created automatically by the Window tool, that uses the 5 wires (always subtracting the other ones from the biggest one), and has an extrusion value of 1. Let's change its extrusion value to 0.1, to match what we used in the doors.
Then, let's add 4 new glass panels, each using a single wire, and give them an extrusion of 0.01, and an offset of 0.05, so they are placed at the middle of the frame. This will be how your window looks like when you are finished:
I suppose now you must have understood the power of this system: Any combination of frames and panels of any shape is possible. If you can draw it in 2D, it can exist as a full valid 3D object.
Now, let's draw the other pieces, then we'll move everything into place together. But first. we'll need to do some corrections to the base 2D drawing, because some lines are clearly missing, where the windows meet the stairs. We can fix that by offsetting the stairs line by 2.5cm with the Draft Offset tool (with ALT pressed of course, to copy our lines instead of moving them). Now we can draw our layout, with wires, then convert them to a sketch, then making a window of it.
After doing that a couple of times (I made it in 4 separate pieces, but it's up to you to decide), we have our facade complete:
Now, as before, it's just a matter of rotating the pieces, and moving them to their correct position:
Last missing piece, there is a segment of wall that didn't appear on the plan view, that we need to add. We have several options for that, I chose to draw a line on the ground plane, then move it up to the correct height, then create a wall from it. Then, we also need to fish up our roof subtraction volume (it must have stayed in the last column), then subtract it. Now this side of the building is ready:
Ready? Not quite. Look at the image above, we did our doors with a 5cm frame, remember (it was the default from the preset). But the other windows have 2.5cm frames. This needs to be fixed.
We already saw how to build and update window components, via the window's edit mode, but we can also edit the underlying sketch. Preset windows are not different than custom windows, the Arch Window tool only created the underlying sketch fo you. Select our door object (the original, not the copy, remember, we made a clone), and expand it in the tree view. There is our sketch. Double-click it to enter edit mode.
the Sketcher Workbench is an extremely powerful tool. It doesn't have some of the Draft conveniences, such as snapping or working planes, but it has many other advantages. In FreeCAD you will frequently use one or another depending on the need. The most important feature of the sketcher is constraints. Constraints allow you to automatically fix the position of some elements relative to others. For example, you can force a segment to always be vertical, or to always be at a certain distance to another.
When we edit our door sketch, we can see that it is made on a fully constrained sketch:
Now all we need to do is edit the 5cm distances between the outer line and the inner line, by double-clicking them, and changing their value to 2.5cm (Remember, the units are still not fully functional at the time I'm writing this). After clicking the "OK" button, our door (and its clone) have been updated.
Until now our work has been relatively easy, because we had the underlying 2D drawings to base our work upon. But now, we must do the opposite facade and the glass atrium, and things are getting more complicated: The opposite facade drawing has a lot of wrong things, doesn't represent the atrium at all, and we have simply no drawing for the inner walls of the atrium. So we will need to invent a couple of things ourselves. Be sure to have a look at reference pictures to figure out how things are made. Or do it as you wish!
One thing we can already do: duplicate the complicated stairs window with the Draft Move tool, because it is equal on both sides:
Note that here, I preferred to duplicate with the Draft Move tool instead of using a clone, because the clone currently doesn't support different colors inside objects. The difference is that the clone is a copy of the final shape of the original object, while if you copy an object, you create a new object and give it all the same properties as the original one (therefore, also its base sketch and its window components definition, which are both stored as properties).
Now we must attack the parts that are not drawn anywhere. Let's start with the glass wall between the sitting room and the atrium. It'll be easier to draw it on the elevation view, because we'll get the correct height of the roof. Once you are in plan view, you can rotate the view from the menu View -> Standard Views -> Rotate left or right, until you get a comfortable view to work, like this:
Note how on the image above, I made a line from the model to the left section, to get the exact width of the window. Then, I reproduced that width on the elevation view and divided it into 4 pieces. Then I built one main window piece, plus 4 additional windows for the sliding doors. The sketcher sometimes has difficulties with overlapping wires, that's why I preferred to keep them separated like this:
After the necessary rotations, everything clicks perfectly into place:
We still need some corner piece there. A little useful trick with the Draft SelectPlane tool, if you have a face selected when you press the button, the working plane matches this face (at least its position, and if the face is rectangular, it also tries to match its axes). This is useful to draw 2D objects directly on the model, such as here, we can draw a rectangle to be extruded directly at its correct position:
Then let's do the two remaining pieces. One is easy, it is a copy of what's on the other side, so we can simply use the 2D drawing:
The other one is a bit tricky, by looking at the pictures, we see that it has many vertical divisions, like the stairs windows. By chance (or very good design from Vilanova Artigas), the width of our window, of 4.50m, is exactly the same as the stairs window, so we can use the exact same division: 15 pieces of 30cm. Here I used the Draft Array tool to copy over the two lines 15 times,and drew rectangles on top of them:
Once this is done, we can create our window with the same method we already know. Another small useful trick, in case you haven't found it yourself already: When editing a window, if you change the name of a component, it actually creates a duplicate of it. So to create the 15 inner glass panels, instead of clicking 15 times the "add" button and fill 15 times the data, you can just keep editing one, and change its name and wire, it will create a copy each time.
After the window is rotated and moved into place, the atrium is complete:
Now when we look at our back elevation, and compare it with the plan, we see that there are some differences that need to be fixed. Namely, the bedroom windows are smaller than I first thought, and we'll need to add some more walls. In order to do that properly, some floors need to be cut:
We have of course several ways to do that, making a subtraction volume would be an easy way, but it would add unnecessary complexity to the model. Better to edit the base wire of each floors. This is where the Draft Edit mode comes into action. By expanding these floors in the tree view, then making their base wire visible, we can then double-click them to enter edit mode. There, we can move their points, or add or remove points. With this,editing our floor plates becomes easy.
After some more sweat (the person who made those drawings obviously became pretty lazy when did this last elevation, much is drawn wrong), we finally have our complete house:
Note the chimney tube, which is made from a circle I used to make a hole in the chimney block, that I extruded, then converted into a tube with the Part Offset tool.
Sometimes an object you made can have problems. For example, the object it was based onto has been deleted, and the object can therefore not recalculate its shape. These are usually shown to you by a little red sign on their icon, and/or a warning in the output window. There is no generic recipe to fix these problems, because they can have many origins. But, the easiest way to solve them is often to delete them, and, if you didn't delete their base objects, recreate them.
Now, after all the hard work we passed through to build this model, comes the reward: What can we do with it? Basically, this is the big advantage of working with BIM, all our traditional architectural needs, such as 2d drawings (plans, sections, etc), renderings, and calculations (bills of quantities, etc) can all be extracted from the model. And, even better, regenerated every time the model changes. I'll show you here how to obtain these different documents.
Before starting to export stuff, one consideration is interesting to do: As you saw, our model is becoming increasingly complex, with a lot of relationships between objects. This can make subsequent calculation operations, such as cutting through the model, heavy. One quick way to magically "simplify" drastically your model, is to remove all of this complexity, by exporting it to the STEP format. That format will preserve all your geometry, but will discard all the relationships and parametric constructions, keeping only the final shape. When reimporting that STEP file into FreeCAD, you will get a model that has no relationship, and a much smaller file size. Think of it as an "output" file, that you can regenerate anytime from your "master" file:
One of the very fundamental things you need when working with BIM is to be able to import and export IFC files. This is still a work in progress in FreeCAD. IFC format is already supported, and importing IFC files into FreeCAD is already pretty reliable. Exporting is still experimental, though, and has currently many limitations. However, things are bettering and we should get proper IFC export very soon.
IFC export requires very little setup, once the necessary software libraries are installed. You only need to recreate the building structure, which is needed in all IFC files, by adding an Arch Building to your file, then an Arch Floor, then moving all the groups of objects that compose your model in it. Make sure you leave your construction geometry (all the 2D stuff we've been drawing) out of it to avoid making your IFC file unnecessarily heavy.
Another thing to set, is to check the "Role" property of structural elements. Since IFC has no "generic" structural element, like FreeCAD, we need to assign them roles (column, beam, etc...) so the exporter knows what element to create in the IFC file.
In this case, we need our whole architectural system, so the IFC exporter can know if an object must be exported as a wall or a column, so we are using our "master" model, not our "output" model.
Once this is done, simply select your building object, and choose the "Industry Foundation Classes" format. Exporting to non-BIM applications, such as Sketchup is also easy, you have several export formats at your disposal, such as Collada, STEP, IGES ou OBJ.
FreeCAD also features a rendering module, the Raytracing Workbench. That workbench currently supports two render engines, PovRay and LuxRender. Since FreeCAD is not designed for image rendering, the features that the Raytracing workbench offer to you are somewhat limited. The best course of action when you want to do proper rendering, is to export your model to a mesh-based format such as OBJ or STL, and open it in an application more suited to rendering, such as blender. The image below has been rendered with blender's cycles engine:
But, for a quick rendering, the Raytracing workbench can already do a good job, with the advantage of being very easy to setup, thanks to its templates system. This is a rendering of our model fully made within FreeCAD, with the Luxrender engine, using the "indoor" template.
The Raytracing workbench still offers you very limited control over materials, but lighting and environments are defined in templates, so they can be fully customized.
Certainly the most important use of BIM is to produce 2D drawings automatically. This is done in FreeCAD with the Arch SectionPlane tool. This tool allows you to place a section plane object in the 3D view, that you can orient to produce plans, sections and elevations. Section planes must know what objects they must consider, so once you have created one, you must add objects to it with the Arch Add tool. You can add individual objects, or, more conveniently, a group, a floor or a whole building. This allows you to easily change the scope of a certain section plane later, by adding or removing objects to/from that group. Any change to these objects gets reflected in the views produced by the section plane.
The section plane automatically produces cut views of the objects it intersects. In other words, to produce views instead of sections, you just need to place the section plane outside of your objects.
The section planes can produce two different outputs: shape objects, that live in the same document as your 3D model, or drawing views, that are made to use on a drawing sheet produced by the Drawing workbench. Each of these behave differently, and has its own advantages.
This output is produced by using the Draft Shape2DView tool with a section plane selected. You produce a 2D view of the model directly in the 3D space, like on the image above. The main advantage here is that you can work on them using the Draft tools (or any other standard tool of FreeCAD), so you can add texts, dimensions, symbols, etc:
On the image above, two Shape2D views have been produced for each section, one showing everything, the other showing only the cut lines. This allows us to give it a different line weight, and turn hatching on. Then, dimensions, texts and symbols have been added, and a couple of DXF blocks have been imported to represent the furniture. These views are then easy to export to DXF or DWG, and open in your favorite 2D CAD application, such as LibreCAD or DraftSight, where you can work further on them:
Note that some features are still not supported by the DXF/DWG exporter so the result in your 2D application might differ a bit. For example, in the image above, I had to redo the hatching, and correct the position of some dimension texts. If you place your objects in different groups in FreeCAD, these become layers in your 2D CAD application.
The other kind of output that can be produced from section planes is a Drawing view. These are produced by using the Draft Drawing tool with a section plane selected. This method has one big limitation compared to the previous one: you have limited possibilities to edit the results, and at the moment, things like dimensioning or hatching are still not natively supported.
On the other hand, the final output being easier to manipulate, and the graphical possibilities of the SVG format being huge, in the future, undoubtedly this will be the preferred method. At the moment, though, you'll get better results using the previous one.
On the image above, the geometry is the direct output of the section plane, but some other Draft objects have been added, such as dimensions and hatched polygons, and another view object with same scale and offset values has been produced from them with the Draft Drawing tool. In the future, such operations will be done directly on the Drawing page, leaving your model totally clean.
This is another very important task to be performed on BIM models. In FreeCAD, things look good right from the start, since the OpenCasCade kernel of FreeCAD already takes care of calculating lengths, areas and volumes for all the shapes it produces. Since all Arch objects are solids, you are always guaranteed to be able to obtain a volume from them.
There is a brand-new workbench in FreeCAD, the Spreadsheet Workbench, that is the perfect tool for collecting such information about our model. It can count objects of a certain name or a certain type, or display a specific properties of those objects. The spreadsheet workbench features two objects: The spreadsheet object is a simple spreadsheet container, that you can edit, and place values inside the cells, but has no automation. The cell controller, on the other hand, is an object that you must insert in a spreadsheet, that controls a series of cells of its host spreadsheet, filling them according to what you specify. This, provided that you organized your model well, allows you to easily retrieve individual values:
Note that the spreadsheet workbench is still very new, and like everything very new, still contains many bugs and limitations. But for simple summaries like this, it already works well. The resulting spreadsheet can then be exported to a CSV file, which can be imported in any spreadsheet application.
The survey mode
Another way to survey your model and extract values, is to use the Arch Survey mode. In this mode, you can click on points, edges, faces or double-click to select whole objects, and you get altitude, length, area or volume values, shown on the model, printed on the FreeCAD output window, and copied to the clipboard, so you can easily pick and paste values in another opened application
I hope this gives you a good overview of the available tools, be sure to refer to the Arch Workbench and Draft Workbench documentation for more (there are more tools that I didn't mention here), and, more generally, to the rest of the FreeCAD documentation. Pay a visit to the forum too, many problems can usually be solved there in no time, and follow my blog for news about he Arch workbench development.
The file created during this tutorial can be found here
<?xml version="1.0" encoding="UTF-8"?> <mime-info xmlns='http://www.freedesktop.org/standards/shared-mime-info'> <mime-type type="application/x-extension-ifc"> <sub-class-of type="text/plain"/> <comment>Industry Foundation Classes</comment> <glob pattern="*.ifc"/> </mime-type> </mime-info>
This is a serie of 3 tutorials for architects who wish to use opensource 3D tools (mainly Blender and FreeCAD more effectively, or simply who are curious about programming, and would like a gentle introduction. This is the first tutorial, presenting python in a general way. Read also the second part: about Blender. The third part (about FreeCAD) is yet to be written.
Why would I need to program? You might ask. There are a couple of reaons:
Python is a programming language. It is free, open-source, multiplatform (Windows, Mac, Linux and many others), and it has several features that make it very different than other common programming languages, and very accessible to new users like yourself:
So, hands on! Be aware that what will come next is a very simple introduction, by no means a complete python course. But my hope is that after that you'll get enough basics to explore deeper into the Blender and FreeCAD mechanisms, which will be in parts II and III of this tutorials serie.
Installing python present no difficulty at all, if you are on Linux there are 99% of chances that it is installed already, since it powers many parts of your system (try running "python" from a terminal to check), otherwise just install it from your system's package manager. On Windows and Mac, just download and install the latest version from the official python website. If you have Blender or FreeCAD installed, they already include an embedded python version, and you don't need to install anything.
When installing python, you might be able to choose between several versions. At the time of writing, the globally considered "stable" version is 2.7, but the latest version available is 3.2. I advise you to install the 3.2, or any higher version available. This tutorial is based on 3.2, but normally everything will work just the same with any other version.
Usually, when writing computer programs, you simply open a text editor (such as notepad on Windows) or a special programming environment which is in most case a text editor with several tools around it, write your program, then compile it (that means basically convert it into an executable application) and run it. Most of the time you made errors while writing, so your program won't work, and you will get an error message telling you what went wrong. Then you go back to your text editor, correct the mistakes, run again, and so on until your program works fine.
That whole process, in Python, can be done transparently inside the Python interpreter. The interpreter is a Python window with a command prompt, where you can simply type Python code, that will be executed on-the-fly, without the need to do anything else.
When Python is installed on your computer you will have a Python interpreter in your start menu (usually labelled "Python" or "Python console"). On linux and mac, you can also simply run "python" from a terminal window. Or, simply fire up Blender or FreeCAD, which both have an included python interpreter (also called "python console"). Below are images showing a standalone python console, and the python consoles embedded in FreeCAD and Blender:
The interpreter shows the Python version, then a >>> symbol, which is the command prompt, that is, where you enter Python code. Writing code in the interpreter is simple: one line is one instruction. When you press Enter, your line of code will be executed (after being instantly and invisibly compiled). For example, try writing this:
print is a special Python keyword that means, obviously, to print something on the screen. It is called a function, which means basically "it does something". Like in most programming languages, functions such as this one use parenthesis () that signify "do it with the contents of the parenthesis". So here the whole line means means "print the contents of the parenthesis". When you press Enter, the operation is executed, and the message "hello" is printed. If you make an error, for example let's write:
Python will tell us that it doesn't know what hello is: "NameError: name 'hello' is not defined".
The " characters specify that the content is a string, which is simply, in programming jargon, a piece of text. Without the ", the print command believed hello was not a piece of text but another special Python keyword. I'll explain better below. The important thing is, you immediately get notified that you made an error. By pressing the up arrow, you can go back to the last command you wrote and correct it.
The Python interpreter also has a built-in help system. Try typing:
It will tell us that help is a function, and needs to be used with parenthesis. For example, let's say we don't understand what went wrong with our print hello command above, we want specific information about the print command:
You'll get a long and complete description of everything the print command can do. Press "Q" to exit the help message.
Now we dominate totally our interpreter (yes, there is no more to know than that), we can begin with serious stuff.
Of course, printing "hello" is not very interesting. More interesting is printing stuff you don't know before, or let Python find for you. That's where the concept of variable comes in. A variable is simply a value that you store under a name. For example, type this:
a = "hello" print(a)
I guess you understood what happened, we "saved" the string "hello" under the name a. Now, a is not an unknown name anymore! We can use it anywhere, for example in the print command. We can use any name we want, just respecting simple rules, like not using spaces or punctuation. For example, we could very well write:
hello = "my own version of hello" print(hello)
See? now hello is not an undefined word anymore. What if, by terrible bad luck, we choosed a name that already exists in Python? Let's say we want to store our string under the name "print":
print = "hello"
Python is very intelligent and will tell us that this is not possible. It has some "reserved" keywords that cannot be modified. But our own variables can be modified anytime, that's exactly why they are called variables, the contents can vary. For example:
myVariable = "hello" print(myVariable) myVariable = "good bye" print(myVariable)
We changed the value of myVariable. We can also copy variables:
var1 = "hello" var2 = var1 print(var2)
Note that it is interesting to give good names to your variables, because when you'll write long programs, after a while you won't remember what your variable named "a" is for. But if you named it for example myWelcomeMessage, you'll remember easily what it is used for when you'll see it.
Of course you must know that programming is useful to treat all kind of data, and especially numbers, not only text strings. One thing is important, Python must know what kind of data it is dealing with. We saw in our print hello example, that the print command recognized our "hello" string. That is because by using the "", we told specifically the print command that what it would come next is a text string.
We can always check what data type is the contents of a variable with the special Python keyword type:
myVar = "hello" type(myVar)
It will tell us the contents of myVar is 'str', or string in Python jargon. We have also other basic types of data, such as integer and float numbers:
firstNumber = 10 secondNumber = 20 print(firstNumber + secondNumber) type(firstNumber)
This is already much more interesting, isn't it? Now we already have a powerful calculator! Look well at how it worked, Python knows that 10 and 20 are integer numbers. So they are stored as "int", and Python can do with them everything it can do with integers. Look at the results of this:
firstNumber = "10" secondNumber = "20" print(firstNumber + secondNumber)
See? We forced Python to consider that our two variables are not numbers but mere pieces of text. Python can add two pieces of text together, but it won't try to find out any sum. But we were talking about integer numbers. There are also float numbers. The difference is that integer numbers don't have decimal part, while foat numbers can have a decimal part:
var1 = 13 var2 = 15.65 print("var1 is of type ", type(var1)) print("var2 is of type ", type(var2))
Int and Floats can be mixed together without problem:
total = var1 + var2 print(total) print(type(total))
Of course the total has decimals, right? Then Python automatically decided that the result is a float. In several cases such as this one, Python automatically decides what type to give to something. In other cases it doesn't. For example:
varA = "hello 123" varB = 456 print(varA + varB)
This will give us an error, varA is a string and varB is an int, and Python doesn't know what to do. But we can force Python to convert between types:
varA = "hello" varB = 123 print(varA + str(varB))
Now both are strings, the operation works! Note that we "stringified" varB at the time of printing, but we didn't change varB itself. If we wanted to turn varB permanently into a string, we would need to do this:
varB = str(varB)
We can also use int() and float() to convert to int and float if we want:
varA = "123" print(int(varA)) print(float(varA))
Note on Python commands
You must have noticed that in this section we used the print command in several ways. We printed variables, sums, several things separated by commas, and even the result of other Python command such as type(). Maybe you also saw that doing those two commands:
have exactly the same result. That is because we are in the interpreter, and everything is automatically printed on screen. When we'll write more complex programs that run outside the interpreter, they won't print automatically everything on screen, (in fact, maybe they won't even have a screen to print to, if they run inside another application) so we'll need to use the print command. But from now on, let's stop using it here, it'll go faster. So we can simply write:
myVar = "hello friends" myVar
Another cosmetic detail, you can insert blank spaces where you want, just to make your code easier to read. It's a matter of taste, python doesn't consider whitespaces (unless they are inside a string, of course, otherwise how would you print whole sentences?). For example, these two lines of code are totally identical to python:
print(type(varA+varB)) print ( type ( varA + varB ) )
Another interesting data type is lists. A list is simply a list of other data. The same way as we define a text string by using " ", we define lists by using [ ]:
myList = [1,2,3] type(myList) myOtherList = ["Bart", "Frank", "Bob"] myMixedList = ["hello", 345, 34.567]
You see that it can contain any type of data. Lists are very useful because you can group variables together. You can then do all kind of things within that groups, for example counting them:
or retrieving one item of a list:
myName = myOtherList myFriendsName = myOtherList
You see that while the len() command returns the total number of items in a list, their "position" in the list begins with 0. The first item in a list is always at position 0, so in our myOtherList, "Bob" will be at position 2. We can do much more stuff with lists such as you can read here, such as sorting contents, removing or adding elements.
A funny and interesting thing for you: a text string is actually, internally, a list of characters! Try doing this:
myvar = "hello" len(myvar) myvar
Usually all you can do with lists can also be done with strings. In fact both lists and strings are sequences of elements, and you can do much more with sequences, as we'll see further on.
Outside strings, ints, floats and lists, there are more built-in data types, such as dictionnaries, or you can even create your own data types with classes. Like everything in Python, the basics are small, but it is often extensible as far as your imagination allows.
One big cool use of lists is also browsing through them and do something with each item. For example look at this:
alldaltons = ["Joe", "William", "Jack", "Averell"] for dalton in alldaltons: print (dalton + " Dalton")
We iterated (programming jargon again!) through our list with the "for ... in ..." command and did something with each of the items. Note the special syntax: the for command terminates with : which indicates that what will comes after will be a block of one of more commands. Immediately after you enter the command line ending with :, the command prompt will change to ... which means Python knows that a :-ended line has happened and that what will come next will be part of it.
How will Python know how many of the next lines will be to be executed inside the for...in operation? For that, Python uses indentation. That is, your next lines won't begin immediately. You will begin them with a blank space, or several blank spaces, or a tab, or several tabs. Other programming languages use other methods, like putting everythin inside parenthesis, etc. As long as you write your next lines with the same indentation, they will be considered part of the same for-in block. If you begin one line with 2 spaces and the next one with 4, there will be an error. When you finished, just write another line without indentation, or simply press Enter to come back from the for-in block
Indentation is cool because if you make big ones (for example use tabs instead of spaces because it's larger), when you write a big program you'll have a clear view of what is executed inside what. We'll see that many other commands than for-in can have indented blocks of code too.
For-in commands can be used for many things that must be done more than once. It can for example be combined with the range() command:
serie = range(1,11) total = 0 print ("sum") for number in serie: print (number) total = total + number print ("----") print (total)
Or more complex things like this:
alldaltons = ["Joe", "William", "Jack", "Averell"] for n in range(4): print (alldaltons[n], " is Dalton number ", n)
You see that the range() command also has that strange particularity that it begins with 0 (if you don't specify the starting number) and that its last number will be one less than the ending number you specify. That is, of course, so it works well with other Python commands. For example:
alldaltons = ["Joe", "William", "Jack", "Averell"] total = len(alldaltons) for n in range(total): print (alldaltons[n])
Another interesting use of indented blocks is with the if command. If executes a code block only if a certain condition is met, for example:
alldaltons = ["Joe", "William", "Jack", "Averell"] if "Joe" in alldaltons: print ("We found that Dalton!!!")
Of course this will always print the sentence, because the stuff after "if" is always true ("Joe" is indeed foundin the allDaltons list), but try replacing the second line by:
if "Lucky Luke" in alldaltons:
Then the result of that line is false, and nothing is printed. We can also specify an else: statement:
alldaltons = ["Joe", "William", "Jack", "Averell"] if "Lucky Luke" in alldaltons: print ("We found that Dalton!!!") else: print ( "Such Dalton doesn't exist!" )
The standard Python commands are not many. In current version of Python there are about 30, and we already know several of them (print(), len(), type(), etc...). But imagine if we could invent our own commands? Well, we can, and it's extremely easy. In fact, most the additional modules that you can plug into your Python installation do just that, they add commands that you can use. A custom command in Python is called a function and is made like this:
def square(myValue): print ( str(myValue)+" square meters" ) print ( square(45) )
Extremely simple: the def() command defines a new function. You give it a name, and inside the parenthesis you define arguments that we'll use in our function. Arguments are data that will be passed to the function. For example, look at the len() command. If you just write len() alone, Python will tell you it needs an argument. That is, you want len() of something, right? Then, for example, you'll write len(myList) and you'll get the length of myList. Well, myList is an argument that you pass to the len() function. The len() function is defined in such a way that it knows what to do with what is passed to it. Same as we did here.
The "myValue" name can be anything, and it will be used only inside the function. It is just a name you give to the argument so you can do something with it, but it also serves so the function knows how many arguments to expect. For example, if you do this:
print ( square(45,34) )
There will be an error. Our function was programmed to receive just one argument, but it received two, 45 and 34. We could instead do something like this:
def sum(val1,val2): total = val1 + val2 return ( total ) sum(45,34) myTotal = sum(45,34)
We made a function that receives two arguments, sums them, and returns that value. Returning something is very useful, because we can do something with the result, such as store it in the myTotal variable. Of course, since we are in the interpreter and everything is printed, doing:
will print the result on the screen, but outside the interpreter, since there is no more print command inside the function, nothing would appear on the screen. You would need to do:
to have something printed.
Now that we have a good idea of how Python works, we'll need one last thing: How to work with files and modules.
Until now, we wrote Python instructions line by line in the interpreter, right? What if we could write several lines together, and have them executed all at once? It would certainly be handier for doing more complex things. And we could save our work too. Well, that too, is extremely easy. Simply open a text editor (such as the windows notepad, or gedit on ubuntu), and write all your Python lines, the same way as you write them in the interpreter, with indentations, etc. Then, save that file somewhere, with a .py extension instead of the usual .txt. That's it, you have a complete Python program. Of course, there are much better and much more comfortable editors than notepad (try notepad++ for example), but it is just to show you that a Python program is nothing else than a text file. Also note that on windows, python already comes with an editor named "IDLE", which is also a very comfortable way to write python code.
To make Python execute that program, there are hundreds of ways. In windows, simply right-click your file, open it with Python, and execute it. But you can also execute it from the Python interpreter itself. For this, the interpreter must find your .py file. The easiest way is to place your .py file in a place where python will search by default, such as the folder from where you started the python interpreter. On linux, by default it is your user home directory, on windows it is the folder where you installed python. If you use FreeCAD, you can simply place your .py file in the macros folder.
Here is a simple trick to find, from inside the python console, what is the current directory, which will be a good place to save our script (I'll explain later):
import os os.path.abspath(".")
Then, let's fire our text editor, and write the following text:
def sum(a,b): return (a + b) print( "test.py succesfully loaded" )
and we save it as test.py in the directory found above. Now, let's start our python console, and, write:
without the .py extension. This will simply execute the contents of the file, line by line, just as if we had written it in the interpreter. The sum function will be created, and the message will be printed. There is one big difference: the import command is made not only to execute programs written in files, like ours, but also to load the functions inside, so they become available in the interpreter. In python, that kind of files, made to be imported into other files instead of being simply executed, are called modules.
Normally when we write a sum() function directly in the interpreter, we execute it simply like that:
Like we did earlier. When we import a module containing our sum() function, the syntax is a bit different. We do:
That is, the module is imported as a "container", and all its functions are inside. This is extremely useful, because we can import a lot of modules, and keep everything well organized. So, basically, everywhere you see something.somethingElse, with a dot in between, that means somethingElse is inside something. Now you should understand better what we did with our "os" module above. The os module is a standard module of python, and contains operating system-related functions, and a submodule (simply a module inside a module) named "path" which contains tools to work with files and folders.
We can also throw out the test part, and import our sum() function directly into the main interpreter space, like this:
from test import * sum(12,54)
Basically all modules behave like that. You import a module, then you can use its functions like that: module.function(argument). Almost all modules do that: they define functions, new data types and classes that you can use in the interpreter or in your own Python modules, because nothing prevents you to import modules inside your module!
One last extremely useful thing. How do we know what modules we have, what functions are inside and how to use them (that is, what kind of arguments they need)? We saw already that Python has a help() function. Doing:
Will give us a list of all available modules. We can now type q to get out of the interactive help, and import any of them. We can even browse their content with the dir() command:
import math dir(math)
We'll see all the functions contained in the math module, as well as strange stuff named __doc__, __file__, __name__. The __doc__ is extremely useful, it is a documentation text. Every function of (well-made) modules has a __doc__ that explains how to use it. For example, we see that there is a sin function inside the math module. Want to know how to use it?
print ( math.sin.__doc__ )
which is a simpler version than:
And finally one last little goodie: When we work on programming a new module, we often want to test it. So once we wrote a little piece of module, in a python interpreter, we do something like this, to test our new code:
import myModule myModule.myTestFunction()
But what if we see that myTestFunction() doesn't work correctly? We go back to our editor and modifiy it. Then, instead of closing and reopening the python interpreter, we can simply update the module like this:
By now, you should have a broad idea of how things are programmed in python. As you see, it's basically a matter of writing text files containing your python instructions, and have these files (modules) imported in your favorite application, and executed for example when the user pushes a button. How to achieve that depends from the application, that's what we'll explore in the next parts of this tutorials serie...
In the meantime, if you would like to know more about the basics of python, there are many, many tutorials on the internet. I selected a couple of good, simple and easy ones here. For more advanced ones, just google for "python tutorial", and you'll find plenty, including one from the official python website.
There are also many very complete PDF ebooks:
I hope you liked, if anything is unclear, please tell me by posting a comment below, so I can make it evolve into something better!
To be continued! Read the second part: about Blender.
class Line: def __init__(self, obj): ''' App two point properties ''' obj.addProperty("App::PropertyVector","p1","myCategory","Start point") obj.addProperty("App::PropertyVector","p2","myCategory","End point").p2=FreeCAD.Vector(1,0,0) obj.Proxy = self def execute(self, obj): ''' Print a short message when doing a recomputation, this method is mandatory ''' obj.Shape = Part.makeLine(obj.p1,obj.p2) ml=FreeCAD.ActiveDocument.addObject("Part::FeaturePython","myLine") Line(ml)As a result, the 2D drafting module has been completely upgraded to take advantage of this. One of the most useful consequences is that it now has an editmode. But it also allows for several other goodies, such as enter FreeCAD's parametric chain (for example, an object made of the union of two other objects retains the original objects, etc):