FreeCAD BIM development news - August 2019

Hi friends!

Time for another report about what has happened this month regarding the development of BIM tools in FreeCAD. We have quite a lot of stuff again this month, and pretty exciting news all over FreeCAD! 

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:

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

And the Draft View, which is used to put drawings made with Draft tools on a TechDraw page, has gained this one:

  • 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!



Tier Benefits
Recent Posts