FreeCAD BIM development news - August 2019
As always, thanks a million to everybody who supports me on Patreon, Liberapay or donated me directly via PayPal. The more I get, the more of my working hours I can dedicate to FreeCAD. This has been now almost two years since I began this campaign, I consider it an astonishing success. There is always movement (new people starting to donate, some people leaving, some changing the amount of their donations, for higher or for lower), but it is all in all very steady, and it really helped me to keep the boat afloat and keep working on FreeCAD several times when I would have stopped otherwise to switch to other stuff to pay the bills. Also, it's a great thermometer of the interest that you guys have in all this.
But let's no delay things any longer, here it goes!
The video: Rendering with Blender
As you know, I'm a huge fan of Blender, and it's an absolutely indispensable companion tool to FreeCAD. All the things that FreeCAD doesn't do well, Blender is excellent at. And, if I dare to say so, vice-versa. I couldn't recommend enough you spend some time playing with it, if you are in to BIM. Here I'll show how to import a FreeCAD model into it and do very basic rendering:
Get the FreeCAD importer addon here.
This is (probably) the last video of the Barcelona Pavillion series. All the files I produced when making the series are available on GitHub, I still need to give it a bit of cleaning then I'll add the link on all the videos pages...
I'll go on making videos, of course. You guys showed clearly that you like them. But I'll go back to illustrating more specific aspects of BIM modeling in FreeCAD.
GIT support for FreeCAD files
I did two experiments this month, one with the FCInfo utility and another using Zippey. Both are ways to make the changes between one version and another version of a FreeCAD file rendered as text, and therefore comparable by diffing (diff is a program that highlights differences between two texts, like the image above).
Both methods have their advantages. The FCInfo methods gives a nicer diff, but is not a 1:1 text conversion, so for example some differences inside the binary parts fo the FreeCAD file won't appear (although it will be marked as changed, as the SHA1 code will be different). The zippey method is uglier but guaranteed to show each and every change, even if unreadable to a human.
Note that this only solves one of the problems of working with FreeCAD files in git, which is to know what changed between two versions of a same file. The other problem, which is that each commit stores the entire FreeCAD file again, thus eating quite a lot of space, remains to be addressed. But this is a step already.
Support for different object and material color
Until now, when an Arch/BIM object in FreeCAD got a material assigned, the object would automatically take the material color. This is what you want in most cases, but not always: For example, a civil engineer would want to have a certain set of beams in red, and another in green, to illustrate categories they belong to, although they have the same material.
Now, Arch/BIM objects have a property to switch the automatic color association off, so they won't take automatically the material color, and you can give them another color if you wish.
BuildingParts properties cleanup, and section support
I did a good cleanup in the BuildingPart properties, they are now a bit better organized. Since this object is becoming the all-in-one do-it-all BIM container object, which can be used to represent a building, a storey, or just about any kind of (duplicatable) grouping you want to do in a BIM model, it also gained quite a lot of behavioural functionality (ways to manipulate it), so I created a specific properties group for them.
Another big change, is that BuildingParts now have a built-in, implicit section plane. That section plane is always parallel to the BuildingPart's base plane, but you can specify the offset between them. So now all tools that work with a section plane, such as Draft Shape2DView and TechDraw ArchView also work with BuildingParts. Showing a plan view in TechDraw is now pretty easy: Create your level model, create a TechDraw page, add your plan to it with the ArchView button.
TechDraw ArchView and DraftView improvements
The TechDraw ArchView, which you use to create on a TechDraw sheet a view obtained from an Arch Section Plane (or now from a Building Part too), has gained a couple of additional properties:
- Arch Join: If set to True, all Walls and Structure objects will be unioned by material. Those that have no material will be unioned together.
- Cutline Width: Allows you to give a custom line width to cut lines
- Override Style: This is set to True by default, to make it still work as before: All objects gathered by this view are rendered with the same line width, color and style. If you set it to False, however, each object will be rendered with the line width, color and style it has in the model. The Line Width set on the TechDraw view serves as a base factor, that is, if it is for example set to 0.15, objects with line width of 1.0 will be rendered in 0.15, those with 2.0 will render in 0.30, etc..
This one was done by Dion Moult. It adds a Project object to FreeCAD, which gives support for the IfcProject entity in IFC. That entity basically holds georeferencing data, such as units system, orientation, projection system, etc. In the future, this will also allow us to support other kinds of product collections in IFC, such as the IfcProjectLibrary
When importing an IFC file, a Project object will now always be created. You can delete it afterwards if you are not using it. When exporting, it works the same way as other entites such as Site or Building. If you have one, it will be used and exported. If you don't, a default one will be added to the file. So this doesn't force you to use anty of them in your FreeCAD model.
Coin-based TechDraw views
In this forum thread, we started a discussion about improving TechDraw performance, and it ended up connecting to some experiments I did earlier, which finally gave birth to a working solution, that is, a third rendering mode for TechDraw ArchViews.
The first mode, Wireframe, uses OpenCasCade's internal hidden-line algorithm to create a 2D view. Furthermore, it also performs a gigantic boolean operation to cut the model when rendering a section. The second mode, Solid, uses an own vector rendering module that essentially applies the painter's algorithm: it projects each face of the model in the correct order so faces closer to the camera are drawn on top. This works well with SVG, which works the same way. However, it falls short for curved surfaces, which can be both behind and in front of another face, and the gigantic boolean operation is still needed.
The new, third mode (thery are actually two: Coin and Coin Monochrome), use another system: they "simply" (nothing is simple there, of course) create a vector output of the FreeCAD 3D view, which is another amazing possiblity offered by Coin, the engine behind the FreCAD 3D view, which was masterfully adapted by Werner some time ago to produce SVG code.
The way it works is simple: When needing a recompute, the TechDraw view spawns a separate FreeCAD 3D view, copies over the Coin nodes from the main view, sets the camera and clip planes as needed, renders it to an SVG file, and closes the view. As there is no shape operation involved, this happend blind-fast, even for pretty large models. It can basically solve all the problem of using TechDraw for large models. We could in theory have any number of views open at the same time with little overhead.
Of course, there are still problems: If you have many views needing recomputation, FreeCAD opens and closes many 3D views at the same time, which is prone to crash, and some features are not supported by this method, such as transparency and cut lines. But no doubt solutions will come up. The important thing is that, I feel, we now have a real, working solution to work with.
DXF layer support improvements
The DXF import/export framework has also gained better support for Layers. Layers are now imported and exported with correct line color and style, and objects that are inside a layer that affects children color and style are exported with "BYLAYER" style, which means they must take the color or line style of their host layer. This works only for the legacy (python) importer and exporter at the moment.
This gives a much better workflow when using FreeCAD as a 2D CAD platform, which is something I intend to develop further. I am increasingly using FreeCAD as my main 2D CAD platform too, in order to, as they say in the developers world, eat your own dogfood, and also solve issues on the way.
I don't really think 2D CAD is anywhere close to dead... In many cases drawing is still more efficient than modeling... Besides, having both 2D drawing and 3D/BIM modeling tools in the same "space" and be able to use both in the same model is awesome.
BIM Rewire tool
This is a small tool that I added to the BIM workbench that will go to Draft once it has stabilized, it basically takes a bunch of lines, being separate objects or not, and joins them into wires (it finds connected edges automatically).
Link branch merge
This might not say you much if you are from the BIM area, but it is a major milestone in FreeCAD's life. The Link branch has been developed mostly single-handedly during more than a year by Realthunder, and has finally been merged into FreeCAD's main code branch, after a gigantic review work that Werner did.
As the Link branch does some pretty heavy changes all over FreeCAD, during this year, there have been many lengthy discussions and issues, and the branch has grown into an enormous set of changes, which has been very hard to merge. But it is finally there, and so far it behaves pretty well, and is causing far less instabilities than I anticipated.
Basically, the Link branch prepares FreeCAD for the phase that was scheduled to happen after PartDesign: Working with assemblies. It allows to share object data such as geometry or even their 3D visual representation with other objects, inside or outside the file.
The Link branch basically adds a new object type, that we call App::Link, that is able to use another object's shape or visual representation. Think of a kind of sublime, absolute clone. Or a same object living into two different "instances".
A lot of the functionality offered by the App::Link functionality is already present in Arch/BIM (clones, references,...), but this is a much wider and lower-level implementation, and no doubt many new uses will pop-up for us too.
That's all for this month I guess, next month I'll be traveling most part of the month (Russia and Belgium, tell me if you are around for a beer!) so there will likely be much less coding from my part. But I'll concentrate on working on the documentation instead, which is in dire need of a good cleanup!