Categories:


Archives:

FreeCAD News 29

by Yorik on 26.05.2025 in freecad , opensource , nativeifc

Hello all!

Here we go for a new activity report showing what I've been working on on the FreeCAD BIM front. First of all, I must apologize for the long delay with no posting and little coding, the reason is I've had my attention diverted by this little side project

a picture of Cosmo!

But there is a lot of new stuff coming, part of my original Native IFC road map, which is now almost complete. With this done, we can basically claim the basic support for Native IFC in FreeCAD is there and done. There is still a lot of work to be done yet, of course, but what I had in mind for this milestone is more or less complete, and working with IFC files natively in FreeCAD is a reality.

Let's have a look at what's coming. Most of what's below is what I had planned in this blog article for walls and this one for windows.

Keep in mind most of this stuff still needs a little bit more polish and testing before it's merged, so it is not yet available in FreeCAD weeklies. I'll do my best to do that soon, though.

Better window placement

screenshot of FreeCAD showing a window being placed on a wall, with a precise working plane position

Correctly placing windows on a wall has always been delicate in FreeCAD, and there is the additional problem of keeping track of the relative position of a window on its host wall, so if the wall changes, the window keeps its correct location.

These are inherently two different problems, and while I have no clear solution in mind for the second one, I gave a try at the first one already, by adding two improvements to the Snapping functionality:

  • Allow to set the working plane on a selected edge + face. This does the same as setting it to a face, like before, but it also places the origin of the working plane to the first point of the edge, and orients it so its X axis is aligned with the edge. This allows, for example, to place the working plane at a corner of a wall. So from there, it becomes easy to place a window at an exact location relative to that corner.

  • Added a "Recenter" in-command shortcut. This moves the working plane to the current snap position (the working plane snap button is taken into account, so one can only move the WP in the same plane or not). This allows for further precise placements, for example placing a temporary snap hold point, and then placing the working plane on that point.

With these, one can easily, for example, start from a corner of a wall, go 100cm left, recenter the working plane, go 100cm up, and place the window there.

See the pull request here.

Baseless walls

Although this was already possible to do by code, using the Arch.makeWall() Python function, it was so far not possible to create baseless walls using the graphical user interface. This is now possible.

Baseless walls are just walls that have no separate base line object. They are just constructed form their length, width and height properties, and their placement. Certainly above 90% of the walls we make in BIM projects are such simple, rectangular walls. So if the wall object contains everything that is needed to produce the wall geometry, the base line object becomes in those cases unneeded.

And, as you know, in a parametric application, objects have a price. A large number of objects in a document has a very significant impact over the general speed and responsiveness. So the fewer objects we can make, the better.

UI-wise, in the BIM properties, you will now be able to specify how you want your walls created: Baseless (which will be the default), with a Draft line, or with a Sketch (which in this case, uses Arch Sketches, which give very advanced possibilities and precise per-segment controls).

Baseless walls will still be fully movable, editable, stretchable and everything, just like line-based walls. Only, the baseline is implicit instead of being an explicit, separate object.

See the pull request here.

Joining system

Joining walls or structural elements is a complex problem in a BIM application. Even more complex if you want these joints to keep updated, and support them in IFC.

We won't pretend solving everything here, rather start building good foundations and convenient tools for users to easily join elements. With good foundations, we can later build more functionality to keep things automatic and support IFC.

So what we have so far are three tools:

  • A miter join tool, that joins two selected walls with a miter joining. This is how many commercial and non-commercial BIM applications out there work.

  • A butt join tool, that joins two selected walls or structural elements (beams and columns) by creating a butt situation (one creates the angle, the other stops against it). This is not so often used in walls, but is very convenient for structural elements. You usually always want either a beam to stop at a column, or a column to stop under a beam. The order of your selected objects has importance here.

  • A tee join tool, that simply extends one wall or structural element so it touches the other. Here too, the selection order is important.

These tool work all basically on a same system, that is implemented for both walls and structural objects: Both types gain two new properties: Ending Start and Ending End, which are both Placement properties. These two placements, if not zero, define cut planes, to be placed either at the start or at the end of the element. These planes can be placed inside the element, in which case they cut the element, or outside, in which case the element is also extended until it can be cut by the plane.

This allow for just any kind of ending situation described above. It also has the advantage of separating the ending from the baseline, which is important in structural elements, because you still want the baselines or nodes to meet exactly, but that is not necessarily how you want your intersections to look like.

In a typical example, if you have two columns supporting a beam, you will want the three baselines to meet exactly, to form a coherent structural diagram, but you want the beam to appear supported by the columns, that is, include the columns widths.

Another example would be a room surrounded by 4 walls, you would want the baselines to form a closed square, but not necessarily will the wall geometry be cut exactly on the intersection points.

There is a lot of room for expansion in the future. For example, automatic joining could be achieved by having an invisible plane object that controls the start and end placements of two elements. Such behaviour could also be much easier stored in as IFC data.

All in all, we will need to put this to test, but I believe it is a good base for a solid sytem.

See pull requests for walls and for structural elements.

screenshot of FreeCAD showing beams and windows joined in different ways

RCP tool

RCP, or Reflected Ceiling Plans, are used a lot in architecture: They are floor plans, but that show the ceiling instead of the floors. They are called inverted because they are still projected as if "viewed from above". That is so you can easily find yourself in the plan and compare with the other floor plans.

There is now a new RCP tool coming in BIM, which basically does a very simple thing, it marks a section plane as "reflected", which will simply flips X and Y coordinates of the generated views made from it.

The RCP tool will automatically create such a reflected section plane for you, if you invoke it with a selected section plane. Internally, it will simply duplicate it, rotate it 180°, and set its Reflected property to True.

So in a typical workflow, for each floor of your project, you will have two section planes: One pointing downwards, to make the floor plan, and one, placed at the exact same location (or not), but pointing upwards, and marked as "reflected", to produce a ceiling plan.

See the pull request here.

Baseless windows

screenshot showing a baseless window

Same as for walls as I described above, 90% of windows are actually very simple models with a couple of rectangular frames and rectangular panels. These can very easily be described by a few numbers, and would not require an underlying sketch.

So now the window code has been modified to allow to describe components with numbers only. If a window is made of only such "numeric" components, it does not need its base sketch anymore.

Less objects mean faster FreeCAD.

If you are interested in a bit more details, here we go:

Windows in FreeCAD have a Window Parts property (hidden in the properties view because it's meaningless to the user, at least for now) that holds the components definition.

Each component is described by things like:

  • a name

  • a type (frame, glass panel, solid panel, louver,...). This is what determines which "geometry generator" is used for the component

  • a list of wires to use from the base sketch

  • an extrusion thickness

The parameter that changes is the third one, the list of wires. It can now also be a list of numbers, that describe the (x,y) relative start position of the component, and a width and a height. That's enough for a solid panel. For frames, there is also the thickness of the frame, or optionally 4 thicknesses for the top. right, bottom and left legs of the frame. This allows for ex. to make a door frame, setting the bottom thickness to zero.

Of course, just as before, this is complicated to define. Therefore, comes the UI. Read below

See the pull request.

New window component UI

screenshot showing the new window editing UI

The window components editor was notoriously cumbersome and hard to use, so I rewrote it entirely. It works now similarly to other part of FreeCAD, with a top panel showing the components tree (because their hierarchy is now no more implicit, but can be changed and rearranged), and below a component editor that shows the parameter of the selected component.

It is now much, much more convenient to create, edit or delete components, change them, reorder, etc. And above all, it's much clearer to see what you are doing

When creating a "numeric" component, there is also an extra panel opening to allow editing the different values.

See the pull request.

Custom window components

screenshot showing a window with a handle

Another improvement to windows is the ability to add custom components (that is, objects made with other tools and workbenches). That was somewhat already possible using Additions, but then those additions wouldn't properly follow when the window is opened.

Now, windows have gained a Components property, that can hold other objects. Any object in Components can then be used in the component editor, and placed in the components hierarchy. Then they will coherently follow when the window is opened. This is mainly interesting for hardware like handles, but could also be very useful for any complex, hand-crafted elements of a window.

This is all part of the same windows pull request.

Window annotations

In a similar way as components, windows have also gained an Annotations property, which can hold any kind of 2D object or text. These will then be part of the window appearance, both in the 3D view as on 2D views.

This can be used to add symbols, tags or any other kind of marking that should be added to the window.

So far there is no support for parametric text, so basically one different text must be added to each window that needs a different text, but that's an improvement that could easily be brought in the future.

Again part of the windows pull request.

Window/door presets separation

As asked by many users, the separation between the door tool and the window tool is now more coherent and logical, although underneath it is still the same tool: The window and door tools will now remember all of their settings separately, so what you define in one won't interfere in what you define in the other.

Also, the list of presets is now separated in two: The window tool will only show the window presets, while the door tool will only show doors. This seems simple or even unwanted, but in our minds windows and doors are very different concepts. So I see this mostly as a speed-up, that allow you to go faster to where your mind knew already it was going.

This too is part of the windows pull request.

BIM documentation

Finally, the BIM documentation is, in my humble opinion, in a state good enough so we can call it "up to date". The native IFC is extensively being worked on, though, so things are always adapting there...

This s the corresponding issue.

That´s all I have this time! Please forgive the lack of updates here recently, always the same problem, I tend to wait until I have "finished" stuff before posting, but nothing is ever completely "finished"...

Thank you once again to everybody who sponsors my FreeCAD BIM work on Patreon, LiberaPay or GitHub!

Cheers

Yorik

by Yorik on 26.05.2025 in freecad , opensource , nativeifc

Comment on this post on Twitter FreeCAD forum OSArch Mastodon - Show replies