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.
Time for a new update on BIM development in FreeCAD. Since last month saw the release of version 0.17, we now have our hands free to start working again on new features! There is quite a lot of new stuff this month, as usual now, spread between the Arch and BIM workbenches. For who didn't see the previous posts where I explained the idea, I am now basically more and more trying to split BIM stuff between what goes into the Arch module, which is included into the FreeCAD source code, which will contain all the "hard-core" stuff (object definitions) and will probably grow more and more deprecated as a workbench, and the BIM workbench, which will contain all the UI (User Interface) work.
This split has many advantages, mainly 1) to make it easier for other people to contribute to BIM development without the need to dig into the FreeCAD source code, and 2) be easier to experiment, outside of the FreeCAD source code itself.
For the FreeCAD user, these distinctions don't really matter, you should basically now use the BIM workbench, and everything from Arch will be there too.
As always, the time I can spend on FreeCAD is a diret consequence of the help I receive from many of you on Patreon or LiberaPay. Thanks a million to everybody who is contributing already, and if you aren't, what about joining the family? Also, helping me with a couple of bucks is just one way to help. Python coding is easy, and the Arch/BIM split makes it even easier to get into it. There is a forum thread dedicated to BIM development. All the help is welcome!
Also: Some pleasant things can happen while you work with FreeCAD...
This month, the video is about windows. Hope you'll like!
This is an item that was annoying me since a long time and has now gained a good update. Panels were already able to be displayed as a flat plate, or as a corrugated panel. But the system was very slow, because a small curve section was generated, then copied over, then extruded, then unioned to the next curve section, resulting in a lot of boolean operations, which, in any CAD system, are an expensive operation that you as a developer must try to use as little as possible.
Besides, that system didn't do a very good job with multilayer panels, and couldn't have a different bottom face, which is both common in sandwich panels and convenient when you don't need to show the curves on the bottom face.
Both these issues are now solved. Now, internally, the code generates one big profile for the whole panel, which is then extruded and doesn't need to be unioned anymore, which makes it way faster to calculate. Additionally, there is one more wave type ("spike"), and you can make the bottom face flat.
This is another long-time request, it is the ability to "draw" beams directly in the 3D view, like walls. So now, when pressing the Structure button, you have an option to switch to that beam drawing mode, instead of just placing an element. I'm not too happy about that interface yet, it seems annoying to me to have to click that control to switch modes, but it is more important to have the tool to work well first, sooner or later an idea will arise to make the UI workflow better.
Another related idea I am always toying with, is if it wouldn't be more interesting to split the "internal" functionality offered by the different BIM tools into separate toolbar buttons, in other words, less complex tools, more toolbar buttons. For example, instead of one Window button that has 6 window presets, have 6 window buttons, each running a different preset. I have no clear idea about that yet, I am not convinced that it is an interesting trade-off, it seems to me it's only moving the compexity to another place...
More thinking is needed there
The Draft Scale tool, when I coded it, was very remotely molded upon the AutoCAD scale tool. One feature I used a lot in AutoCAD was reference scaling. You take one distance, and you say "I want this distance to become that other distance". But this made the Draft Scale tool horribly clumsy to use, specially with 3D objects. In fact, nobody was using it and people were using the Clone tool, which allows to set a scaling factor in an easy and intuitive way like (2.0, 2.0, 2.0) for scale factors on the X, Y and Z axes.
So a while ago I remolded the Scale tool to have the same, simple system. Now you choose your objects, set the scale factor, and choose if the result is a Clone object, or if the original objects must be modified directly (this doesn't work for all object types ATM).
Now we finally have the best of both worlds: The scale tool still works the simple, reliable way, but you can also define the scaling ratio by picking a reference distance and a target distance in the 3D view. The scale factor will be the ratio between these two distances.
This is a very simple change, but that open large possibilities. All Arch objects already had a "Role" property that could be used to fine-tune the use of each object, for example a Structure could have its Role set as Beam, Column, Slab, etc.. But this was basically not used anywhere, except when exporting to IFC. And each Arch object type has its specific list of possible roles.
Now the Role property has been renamed to IfcRole (this is part of a larger effort I am beginning, to group all Ifc-related properties into some specific group), and it can take any IfcProduct role. The IfcProduct is the master class of all "physical" (and a couple of non-physical ones too) elements found in a building, such as column, wall, door, etc (full list here).
In other words, from now on, any Arch object (or, in fact, any FreeCAD object, as you can just encapsulate it in a Component) can be exported to any IFC type. This is something surprisingly simple, offered by very simple apps like Sketchup, but that is curiously hard to do in many BIM applications...
The Draft Text tool, until now, was using a basic App::Annotation object, which was not very handy to use and lacked a couple of features. Now the tool is using its own python object, which is much more comfortable to work with. The two immediate results is that the text object now has a placement, so it can be rotated and placed in any custom position you may want, and it is now a common scene node, so it won't appear through other objects anymore, like the old object did.
From python, you can use Draft.convertDraftTexts() to convert old-style Draft texts in a document to the new format.
A new "manager" tool is now functional in the BIM workbench: The IFC elements manager. What it does is basically shows you all the Arch objects of your document, together with their IFC role. Here you can easily manage all these roles individually or several at once, and make sure everything will export as you want. That screen also allows you to rename objects.
Accurate window placement has always been a pain in FreeCAD. So much that me and others ended up advising to disable snapping when placing windows, then reenable it and move the window to its correct position. Hopefully, thanks to a very simple change, this is history.
Now, when placing a window, when hovering with the mouse over a face, the window will take and keep the orientation of that face, until you hover on another face. This allows to both align a window to a face, and take advantage of the full snapping tools, for example to place a window on an edge or a vertex, like one would expect.
This is not yet 100% perfect, one would still like to be able to place a window at a certain position relatively to another element, but this is a larger question that relates to other elements too like walls or columns. In any case it is already a good step forward, now the window tool finally works properly.
It can happen, when working with Draft Wires,that the wire is not exactly flat. Nothing in FreeCAD or OpenCasCade prevents that. But it might not be usable to form a flat face anymore. This is specially often the case with geometry that you import from other applications, where rounding could occur. The DraftGeomUtils module already had a flattenWire() function that would project all the points of the wire onto its median plane. Now, a right-click context menu option has been added to Draft Wires to perform that action, so it has become a piece of cake to fix those problems.
This is only an experiment so far.
It is a recurrent request from new FreeCAD users coming from AutoCAD: They want an AutoCAD command line. I don't like the idea, basically because it conflicts with a shortcut-based UI like FreeCAD has. If you look at how other apps with both shortcut-based UIs and command line do, for example QCAD or LibreCAD, it doesn't work really well. At some point the app needs to decide if the L key you pressed is a shortcut or the first letter of a command line command. You need either to move your mouse over the command window, or press SPACE to "switch" to command-line mode, which kills a bit the efficiency of it all.
But I have this idea that it would be possible to "fake" the system, and offer the user not a "real" command-line system, but a keyboard-only workflow with the same speed and easiness of the famous AutoCAD command line. To make it simple, pressing the keys would still trigger shortcuts and UI actions, but you would get a "feedback" of it in the output window of FreeCAD, making it look exactly as if you were typing stuff in it.
So far two Draft tools have been adapted to that system, as a proof of concept: Line and Wire. There are a couple of improvements to bring to the console, like the possibility to show stuff in bold font, or maybe enable clickable links, I will look at that later on. But I am not convinced yet if this is usful at all. After all, it is totally possible to pilot most of Draft and Arch commands via keyboard only since a long time...
Please test and give your opinion! There is a forum thread dedicated to this topic.
The Multimaterial dialog already allowed you to define different material layers, to be used by walls, panels, and windows. In the case of windows, it was a bit clumsy to use, you had to create one material layer for each window component. So if you had 20 panels in a window, you needed 20 material layers too. And take care that it uses the same name.
Now instead of a layer name in the Multimaterial editor, you can also click the drop-down arrow and select a window component type. That material layer will then apply to all window components of that type. So you now just need to create a Multimaterial with one material as "Frame" and another as "Glass panel", apply it to all your windows, and you are done.
Another new widget is available in the BIM workbench: A Views manager, that will open inside your Combo View. It is basically a small widow that will list all the Draft WorkingPlane Proxies of your document. You often need to double-click them to set the corresponding view, but they are often buried deep down your model tree. Now they can always be conveniently be available there, no more endless scrolling!
Later on, as the BuildingPart object evolves and can also define a view, it will also appear in that view.
Finally, this is not mine but the result of the hard work of Wandererfan, the TechDraw master, and of huge importance to Arch/BIM users, TechDraw pages can now be exported to DXF. Every single TechDraw feature is not 100% supported yet, but Wandererfan is working amazingly fast on this, and it is very usable already. The result is a very clean and compact DXF file.
If you haven't tried to use TechDraw for Arch/BIM work yet, give it a try, it is still a bit slow for production use, but most of the needed features are there already, no doubt we are getting very close!
That's it for this month, thanks for reading, thanks for the support, more to come next month, don't forget, if you are new to these pages, I can go faster with your support!