This is the monthly development post about the development of BIM functionalities of FreeCAD. This month we won't have a video here, because there is quite a lot of stuff to show already, but next month I'll resume making videos, and I'll try to begin to show real projects in them too (not sure how doable that is, as it might easily make videos pretty long, but we'll try).
As usual, thanks a million to everybody who makes all this journey possible by supporting me on Patreon or Liberapay. As you might have heard if you are using Liberapay, they currently have problems with their payment provider, and operations are suspended there at the moment. Many of you who are using Liberapay opted to empty their online wallet by distributing their remaining money between the projects you sponsor, so I got quite an unusual amount of money this month (around 700 EUR). I am keeping this money intact for now, maybe there would be something cool to do with it, I don't know yet.
As I wrote here last month, by combining what I earn on Patreon (about 700 USD/month) and Liberapay (around 90 USD/month), we are hitting the first goal I had set on Patreon (750 USD), which is to set a site, or forum, where you guys can propose and vote for ideas to be implemented and I would try my best to make them come true. I lacked time to organise this, so it will be for next month. But it's definitely coming!
The project illustrated in this post is by OpeningDesign
So on with the stuff I did this month. Basically not much fancy graphical stuff, bu heavy work on the IFC side of things:
Last month I starrted with this by implementing support for property sets in FreeCAD. Property sets are a feature of the IFC format, where properties of an objects can be grouped into sets. As you can add any number or type of custom properties to any IFC object, you can also group them into custom sets. But the IFC format also provides standard sets, for example walls have a Pset_Wall_Common property set, that contains usual wall properties such as "IsExternal" or "IsLoadBearing". IFC Property sets are now fully supported when importing an IFC file in FreeCAD, and when exporting a FreeCAD model to IFC.
The other big feature I had been working on last month, the new BuildingPart object, which is made to replace the current Building and Floor objects with something more robust and versatile, is now also supported by the IFC importer and exporter. Depending on the IFC role that you give to your BuildingPart object, being Building or Building Storey, it will behave that way in the IFC file.
As important as the support for it in IFC, is the ability to easily edit, add and remove properties to/from your BIM objects in FreeCAD. So in the BIM workbench, we now have a full property manager tool. That tool can be launched directly from the BIM Elements Manager in the "Manage" toolbar or menu of the BIM workbench, or directly from inside the Edit Mode panel of BIM/Arch objects. If the BIM workbench is not installed, that option is not available.
I'm not a big fan of that, "plugins" that spread out new functionality inside existing tools, I find that confusing and hard to discover, so the idea is not to go that way, and keep things clear between Arch and BIM workbenches and not begin to mix stuff between the two. But at the moment I'm still experimenting with all this, trying to find where it fits best, so consider these "intrusions" of the BIM workbench inside existing Arch tools just an experiment to see how it works best. If it consolidates into some "ground" functionality, it will go to Arch. If it's just an additional layer of UI work, it will stay in BIM.
The general idea is that you might want to use the Arch tools sporadically but you work mainly with other FreeCAD workbenches. Then you don't want to be bothered with BIM stuff. Or you are using FreeCAD mainly for BIM, then you want the full-fledged BIM workbench.
We already had several Axis tools in Arch/BIM, that can already cater reasonably well for your axes/alignment needs. However, they weren't very compatible with the way these work in IFC, where each axis is an independent object, grouped under an IfcGrid object that defines which ones are in the X, Y and Z directions. The IFC importer and exporters of FreeCAD now support all this transparently. In FreeCAD, axes can now be only one axis, so IFC grids can be imported as they are (several independent axes inside one grid/axes system), and on export, FreeCAD systems made of several axes will simply be decomposed into their individual axes.
This is not a very good title for this feature, but it sounded powerful Basically this is something that Revit does, that is fully supported by the IFC format. When you have two objects that share, for example, a same point (0,0,0) or a same colour, or a same property (Height = 3m), this information is stored only one in the IFC file, and used everywhere it is needed. This results in drastic file size reduction (30 or 40% everywhere I tested) because in IFC there are a LOT of those simple, basic pieces of information, but makes the file more annoying to read by human eyes, because if you are reading about an object at line 3500, you might need to scroll all the way up to line 15 to know the position of the object, and then half-way back at line 1500 to know its colour.
So this feature is now enabled by default, because in most cases you will want that compression, but can be unchecked in IFC preferences if you need a more human-readable file.
Not every IFC information can be compressed/reused that way at the moment, I just implemented some of the most common ones, but the list is easy to extend.
This is coming from an old dicussion we had with Ryan Schultz and Jon Mirtschin, about how to store and retrieve parametric profiles in IFC. The idea is that several objects can be based on a same profile, a very simple way to convey some "model intelligence" inside an IFC file. You modify the profile, all objects based on it change.
It turns out the IFC format supports that in a pretty simple way, very similar to the previous topic here above, you simply use the same IFC profile entity in different extruded objects. So the IFC importer now implements this, when different FreeCAD objects are extrusions of a same 2D object, it will be saved that way in IFC, and restored that way too when reading the file back.
So with all of the above we can now begin to get pretty accurate "roundtrips" when working with IFC files in FreeCAD. That is, the file contents you get when opening an IFC file you just exported are 100% identical with the original file.
Of course the concept of 100% equality is debatable, you WILL find something that is different from the original file, that is inevitable due to the complexity of the IFC format. But my idea is that we can settle on a general agreement over what reasonably needs to be there in order for us to consider it identical. I would say basically the model tree must be identical, the geometry of all objects must be identical, and all BIM-related properties of all objects must be there and contain identical values.
I think in many cases we have that now fully working in FreeCAD. I'm proud to say that you won't find that in many other BIM aps out there, even the big players
A very simple addition, when an IFC extruded object is imported into FreeCAD, if possible (ie. it is planar and doesn't contain curves), the base profile is now created as a Draft Wire, making it easier to edit.
It's a very small and simple change, but I think we can go a long way like this. "IFC doesn't contain model intelligence", you will often hear hard-core supporters - or vendors - of a certain well-known BIM platform say. But if you think of what makes this intelligence, or in other words what is it really that you do when working with said platform, I think 95% of it are simple things, the ability to click an object and change its extrusion length, duplicate it but still be able to edit a common property of both, etc. All this is well supported in IFC, and can probably be recovered and used in FreeCAD with pretty little changes like this, and we'll be able to make IFC model much more editable.
Another very simple change: Until now, when importing IFC objects that were extrusions, a 2D profile object was created, then a Part Extrusion, then this was encapsulated inside an Arch/BIM object with the correct IFC type. Now, for Arch objects that can create an extrusion themselves (Walls and Structures, basically), the intermediate step is skipped, and the final object is using the profile directly, making the whole model tree a bit thinner.
The progress bar of the IFC importer never worked well, because it was interrupted and reset all the time by the shape reader (which "stole" the progress bar). The shape reader can now run silently, and doesn't perturb us anymore, so the progress bar displayed during IFC import show realistic progress and remaining time estimation. Plus, its abort mechanism is now functioning, and you can abort the import anytime by pressing the Escape key.
For IFC export, the process is so fast that I think we don't need a progress bar at the moment
We had some discussions about materials recently, and, since they are used everywhere in BIM, I thought they could be a good way to handle these characteristics and properties that you want to give to several objects at once. In fact, IFC doesn't give you much option to give extra properties to materials, you have to give these properties to each object that uses the material. But we can do better in FreeCAD, and allow materials to have any number of custom properties (that is implemented already). So materials become a kind of "host" for these properties, and on IFC import/export there would be transferred to/from individual objects transparently.
But that means that if you have two objects made of concrete, but one of their "common" properties has a different value, you need two different concrete materials. This will quickly become annoying. So we need a system to be able to have one concrete material, but with sub-materials, which would change only one value, but keep all the others from their parent.
This system existed already in FreeCAD materials, and is now reflected in the tree. You just need to specify which other material is a parent of this one. There is still a lot to implement (additional properties, the ability to remove a value so it takes its parent's corresponding value, support all this in IFC etc), but I think we are on the right track to get an easy and flexible system that won't overcomplicate the model tree.
A simple addition to the ShapeBuilder tool, an option to build a Wire from a selected set of Edges. It doesn't need to be closed or planar.
A new series of American Wide Flange steel profiles (W profiles) was added to the Structure tool, and the profile object, that is used structural objects when based on a "built-in" profile, was also upgraded. It now uses an own icon, and it has gained an edit mode panel where you can change the profile definition.
At the moment you can only change to another profile of the same type (H, rectangular, etc...) because I am not sure it is a good idea to permit cross-type changes, model-wise (it will need another object, which as consequences on your whole model hierarchy), but we need to study that point further.
This is another rather simple to implement but major improvement. Classification systems are common since quite some time in the construction world. Basically instead of your own description like "concrete pavement tile for exterior use", you would use a number from a classification system that has an " 01 Exterior pavements" categories, with a subcategory " 03 tiles" with different categories for " 05 concrete", " 06 stone", etc. So your number would look like 01 03 05. You get the idea.
That way, you can give your file around, and there is a much higher chance that everything will be correctly understood, even by people in different countries, as the whole system can be faithfully translated. This is not used much for small projects of course, but think of stadiums being built in other countries, you might see the interest there can be in such systems.
There are many classification systems in use around the world already. Most of them proprietary unfortunately (you have to pay to obtain them), some open and free, and most countries are also developing their own which might or might not be compatible with others. In other words, this is a jungle
In FreeCAD, materials already had a "Standard Code" property, which can hold any text value. Now, all BIM/Arch objects also have a "Standard Code" property. The idea would still be to use materials for that, but you would be able to override the material code for any individual object.
Last month I stumbled on this repository made available by Graphisoft with many of the most used standards available as xml files (an open format). So now in the BIM workbench we have a Classification Manager tool, that is able to read these xml files, and set the Standard Code property of a material or BIM object with any its values.
So far this is not exported to IFC (I still need to understand better how it works) but we have a fairly decent classification system in FreeCAD already!
Note that these xml files are provided there by Graphisoft on their own good will. We cannot include these files in FreeCAD because they don't have any license allowing us to do so, so the responsibility to download and use them is yours (how to do it is explained when you open the Classification Manager in FreeCAD). They might change their system or simply remove those files anytime. Some of these, however, such as GuBIM, are open-source, and also provided on the website of their author. So it's important to keep fighting for open standards that we can really rely on on the long term.
Finally another small experiment: In the BIM workbench, there is one new tool beside the Move tool (which is the pain old Draft Move tool): A copy tool. It is simply the same Move tool, but with its "copy" option turned on by default. I think it is pretty handy, so you can start it by another shortcut (C,P instead or M,V) and perform a copy instead of a move. One click or key press less.
And another one, the Clone tool in the BIM workbench now works differently than the original Draft Clone tool: Immediately after creating the clone, the Move command is launched so it works more like in other applications: you select an object, press the clone button, and drop the clone at some other location (since you rarely want the clone to stay at the same place of its original).
I am not sure yet if these changes should go to Draft or not. Tell me what you think!
So that's it for this month, once again thanks a lot if you are supporting this effort, one step closer to our dream BIM application!
Time for a new update on the development of BIM tools for FreeCAD. There is some exciting new stuff, most of it are things that I've been working for some time, that are now ready. As always, a big thank you to everybody who helped me this month through Patreon or Liberapay! We are very close to meet our first goal on Patreon. We would actually already be there if we sum up both platofrms, so next month I'll lower the goal accordingly and declare it achieved and set everything up accordingly!
So here go the new stuff of this month:
This month's video is a presentation of the new BIM workbench, so in next videos we'll use it instead of Arch. As always, your comments are highly welcome (here or directly in youtube comments).
You will remember last time that I told you about the impressive series of FreeCAD-related videos made by Regis, you might also be interested in this other very nice series about BIM and open-source, with a very large part dedicated to FreeCAD, made by Nirbhay, another well-known member of the FreeCAD community. We begin to have pretty decent FreeCAD BIM learning material!
The BuildingPart object I have been working on during the last months is finally ready and is part of the Arch workbench already. It is meant to replace the Arch Floor tool. For the time being, the Floor button is still there in Arch, but it already produces a BuildingPart object with its IFC role set to "Building Storey".
The BuildingPart object is still based on a classical FreeCAD Group object. I played a lot with the idea of using an App::Part instead, because it looked interesting because of its ability to automatically move its contents when you move it, and also that you can make it "active" and automatically add contents to it.
However, I discovered that it was relatively easy to reimplement these two features in another object, and also met some particularities that made me decide against using the App::Part:
The App::Part only allows its children to be part of this App::Part. They cannot belong to any other. This, summed with another particularity, which is that all descendents of an App::Part also become its direct children, makes it impossible to use, for example, a same profile to build two columns placed in two different App::Parts, since the profile will become a direct child of the App::Part. This is not of big importance when designing, for example, mechanical parts, but is very common in BIM.
When you add objects to an App::Part, then move the App::Part, the Placements of the objects don't change. Only their visual appearance gets moved. So if you build a column on the ground floor, then move its containing App::Part 3 meters above, the internal coordinates of the column still indicate the ground floor. And when you remove the column from the App::Part, it pops back to its original location on the ground. This is all "fixable" of course, there are methods in place to obtain the "summed up" placement of the column + its App::Part, and you can add code when removing the column from its Part to deal with the change of location, but this all seemed to me like trying to patch up something that's not really made for that use case.
For part design workflows, this is exactly what you want: Draw your elements at (0,0), then add the to the Part, then move the Part around. If you remove elements from the Part, you want them back to (0,0). You want their internal coordinates to reflect that. In BIM workflows, I think we prefer all our elements to have real-world coordinates. Tell me in the comments if you have a different opinion!
So the BuildingPart is basically a Group, like the old Arch Floor. But with a lot of enhancements:
It can display a "mark" in the 3D view that shows the origin point and optionally the label and level (its z coordinate) . If you move the BuildingPart in Z direction, the level updates. You can give an artificial offset value, so for example if the offset value is 700, but your level is at z = 30, the displayed level will be 730. This is useful to work with geographic coordinates and elevations. You can also select the BuildingPart by its mark in the 3D view.
It can be made "active" by double-clicking it, like an App::Part. When a BuildingPart is active, all new objects will be added to it automatically, like the App Part or PartDesign Body.
When moved/rotated, all its children that either have no "Move With Host" property, or have it turned on, will move/rotate together.
When moving an object out of a BuildingPart, it will keep its current position, not "pop back" to its original position (different from App::Part)
It can be cloned. Internally, the BuildingPart stored a Shape, which is a compound of all its direct children. This shape is used by the clone, also keeping individual face colors. This shape is also stored on disk when saving the file, I think you'll be able to guess where we're heading for next
It can take any IFC type, like other Arch objects. The idea behind the BuildingPart is not only to serve as a Floor/Level/Storey, but to group BIM elements in any other possibly useful way in a replicatable manner. One obvious use would be to make a typical storey of a tower, then replicate it for the other floors, but we can also think of other replicatable things like a toilet stall, a wikihouse component, etc.
It can set the height of included walls and structures automatically. The Arch Floor could do that already. If a height value is set for a BuildingPart, any wall or structure inside it, that has its Height value set to zero, will adopt the BuildingPart height.
It defines a working plane automatically. When double-clicking a working plane, in the tree view or the BIM views manager, the working plane will be placed on the XY plane of the BuildingPart. Later on, I'll also implement the same functions that the Draft WP proxy has, which is to be also able to restore a view angle, and show/hide other objects.
So the idea here is that you would be able, for example, to double-click a BuildingPart which represents a level of a building, and set yourself automatically in top view above this level, hide all other levels, and set the working plane to the floor plane of this level, just like if you were working in a 2D plan. When deactivating that level, you would have everything turned back on, and pop back to the view you were at before activating.
But I found it safer to go step by step, and let people play a bit with the BuildingPart first, before implementing more stuff.
This is another big thing I have been working on for many months. It stayed a long time on hold because we were waiting for FreeCAD to reach a good Python3 compatibility. This is now done thanks to the hard work of several FreeCAD developers, specifically looo and Werner (and a bit of myself too). The issue there is that Blender only uses Python3 while FreeCAD was still not fully ported to it, but Python2 and 3 modules are incompatible with each other.
You can already use the importer, it is pretty stable already, but you'll need to get your hands on (or compile yourself) a version of FreeCAD compiled with the same Python version you use in Blender. The minor version number must match too, so if for example Blender uses 3.6.1, FreeCAD must use also 3.6 (the third digit can be different)
After that, it's just a matter of saving the code from the gist as a .py file (for example io_import_fcstd.py) and place it in Blender's addon folder, then enable it in Blender's addons preferences. If your Python3-compiled verision of FreeCAD is in an unusual location, you might also need to set its location in the addon's preferences.
This is all still a bit uncomfortable, but with time this will get addressed properly. The important part is that it already works pretty reliably.
You will then get a new option in Blender's File->Import menu to directly import a FreeCAD file. You can set a scaling factor between FreeCAD's internal unit (millimeter) and Blender (at the moment I set the default to 0.001) which will import as one Blender unit = 1 meter, and set a couple of other handy options.
The importer will at the moment only handle Part and Mesh-based objects. That is, basically, no texts and dimensions. Groups are also not yet supported, and either are clones (each comes as a separate object). But the geometry comes pretty accurately. Curved faces will be triangulated, flat faces imported as ngons. Materials are also correctly handled and attributed, and materials have both Blender internal settings and cycle nodes (I stil need to implement a proper cycles transparency node for transparent materials).
There is also one feature that will be specially interesting in viz work: The ability to replace objects with similar names. FreeCAD holds an internal, unique name for each object. Blender doesn't have that feature, but has something similar, where an object holds a mesh that can have a different name.
So what happens now is that the Blender object name is set to the FreeCAD object label, while the mesh name takes the FreeCAD object unique name. This allows to match each FreeCAD object with a corresponding, unique Blender object. If you enable the appropriate option when importing a FreeCAD file, if a corresponding object is found in Blender, only its mesh will be updated, the current Blender materials will be kept (and reattributed per-face).
This allows you to work on a FreeCAD model, import it in Blender, makes some changes to materials in Blender, setup your scene, add more objects, etc... Then reimport your FreeCAD files, and keep the object positions and materials that you changed in Blender.
This is a small change, but that will be great for backwards and forwards compatibiliy between different versions of FreeCAD. Basically objects loaded from an older file will now have their properties updated when loaded in a newer version of FreeCAD, so they'll be albe to use all the new features.
In the same way, objects loaded from a file made with a newer version will be able to "auto-fix" to work with this version.
Walls can already use all kinds of 2D objects as their baseline, but by default, new walls will have their base line created as a sketch. This is not always the most interesting thing to do, in many cases a simple Draft line is more efficient, as it can be edited by Draft tools like Edit or Stretch, which support snapping. So now there is a preference option to make new walls create a Draft line instead of a sketch.
This is still a work in progress and not ready for merging, but it's an interesting subject anyway. In IFC, objects can have custom properties. These properties can be grouped into property sets. At the moment, when reading an IFC file, FreeCAD will read and store all properties of an object, but not the property sets they belong to. So when reexporting the file, properties will loose their property set information.
I tried for some time a complicated way to handle these property sets, but recently found a much easier (json-based) way which will also serve for other things (speckle?). So this part can almost be considered as solved.
There is another interesting feature available in the IFC specification, which are pre-made, or standardized property sets. These define, for example, some common properties for walls, that all walls should have. Same for almost all IFC entity types.
These standard property sets are not mandatory. In fact I have very rarely seen an IFC file that uses them. But using them in FreeCAD would be a very good way to create more standardized IFC files. These property sets are not defined in the IFC schema, so I already coded a small utility to download these definitions from the net, and pack them in an xml file. This xml file will be bundled with FreeCAD, and the IFC property editor I'm working on will be able to use it, so we can easily, for example, add common property sets to our objects.
So far, once a window was created, it was possible to change its width and height via its properties editor. To change more advanced details such as frame thickness, you had to edit the window components parameters or the base sketch directly, which was tedious. Now, windows have two new properties: Frame and Offset. As with width and height, changing the frame or offset values will change the window accordingly.
If you wish to use this in your custom windows, it uses the same system as width and height: In the base sketch, if you define two length constraints (horizontal or vertical) and name them "Height" and "Width", they will be controlled by the host window's "height" and "width" properties. To have other length constraints controlled by the "Frame" property, just include "Frame" in their name, for example Frame04.
In the window parameters editor, you now have two new checkboxes to make use of the offset and frame properties.
This is not the end of the path of course, but slowly we'll get there to a friendlier window object...
By right-clicking a material group, you now have an option to merge duplicate materials. That is, materials with a same name but with 3 digits at the end. For example Concrete and Concrete001 will be merged. Any object that used Concrete001 will be changed to use Concrete instead. Very useful when importing susequent versions of IFC files.
Now this dialog from the BIM Workbench also allows you to check what object uses what material, and make sure you have everything properly configured before exporting to IFC.