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!