Categories:


Archives:

FreeCAD BIM weekly update 14

by Yorik on 14.07.2023 in freecad , opensource , nativeifc

Hi all!

Here is the fourteenth weekly update showing what I ham doing this last weeks with FreeCAD, BIM and NativeIFC. Sorry for the missed updates last weeks, I've been doing less BIM stuff because we're busy with the upcoming 0.21 release of FreeCAD, and also because I've been stuck on a couple of features that took way more time than I thought. Read more below!

NativeIFC: Layers

This has taken surprisingly more time than I thought, because everything was there already, I thought this would be easy! But in fact it added a whole new layer of complexity to NativeIFC, and made me realize some design options I chose earlier had become too bulky and a large refactoring was needed. More on this below. Anyway, we now have layers support in NativeIFC! Basically:

  • When opening or importing an IFC file using the NativeIFC importer, in the import dialog, we now have the option to import layers. This will create a hidden group inside the IFC project. You can reveal it by right-clicking the project -> show hidden items, or turning on the "show hidden groups" setting in NativeIFC preferences.

  • These layers are the same layers used by Draft and Arch workbenches. Only, they live inside the IFC project.

  • The layers manager of the BIM workbench has been extended so it shows which layer is an IFC layer (part of an IFC project) and which not. From that layers manager you can create new layers, and, by selecting an IFC project, you add these new layers to that IFC project.

  • To add an object to a layer, just drag and drop it on that layer from the tree view.

This all is still a bit rough, of course. But I decided to stop implementing this further for now, because of the increasing complexity. I thought bet to solve that first, then we'll get back to layers. Read on!

commit

NativeIFC: Groups

The NativeIFC add-on now has support for groups. This works basically the same way as in the rest of FreeCAD: You can add groups inside your IFC project, and add objects to these groups. To add a group, right-click any IFC object in the tree, and choose "Create group". To add an object to a group, just drag and drop it into it.

There is one catch, though: Groups work the same way as other FreeCAD groups: They behave like other FreeCAD objects. You can add groups inside other objects or structures, but if you add an object to a group, that object cannot be part of another group or structure. This kinds of forces a strict "tree-like" structure.

In IFC, however, groups are a much looser structure. You still keep a strict structure using building containers like storeys or buildings, but any object can be attached to any group, and groups don't need to live inside a structure.

We could do it that way too, but then our IFC groups would not look like FreeCAD groups anymore, they would become a separate, loose structure on the side and not interfere with the building structure.

I like the former one, because I've got used to work that way in FreeCAD and use groups a lot to organize things, for example inside a storey. But I understand this is not the way most people use groups within IFC. So this is a point that still needs some debate I think.

What's your opinion? Do you use IFC groups? How? I'd be interested to know.

commit

NativeIFC: material properties

Property sets attached to materials are now properly handled by the NativeIFC module.

commit

NativeIFC: code refactor

I seem to have gone (maybe too?) fast and stacked a lot of things in ifc_tools module. This has been working fine up to now, but I begin to meet some bottlenecks. Mainly, the overall complexity begins to pose different problems:

  • The overall performance is becoming hard to control. It is hard to see where the slowdowns and bottlenecks are.

  • Each new feature supported by the NativeIFC brings a new layer of complexity, that must be applied on several parts of the code, which is slowly getting out of control. We need a better plan to handle these complexity increases.

  • There is more and more "stuff" outside the IFC project structure itself: materials, layers, groups... And there will be much more in the future. We need to think of a better system to properly and beautifully handle these.

So I've started working on a big code refactor, separating code into easier-to-handle structures, and also designing a better structure to accommodate future expansion. Right now there is not much to see yet, the main piece committed is the separation of all shape-generation code into a separate ifc_generator module. So the situation is mow much clearer: FreeCAD objects use this module whenever they need their shape to be calculated or updated, and that's it, nowhere else in the NativeIFC module is a shape recalculation initiated. So when measuring file load performance that's now the only place to look at.

I've also added a quick-and-dirty performance test that gives the performance data at the end of the README. I'll try to maintain these performance numbers updated and more under control form now on.

commit

FreeCAD: 0.21 preparations

The forthcoming 0.21 release of FreeCAD is coming, we are coming to the end of what we call the "feature freeze" time, where we all concentrate on bug fixing. Most of the work is done, and outside a few leftovers we're close to ready for the release. Another important aspect we've been looking into is to better streamline and document the process of building the "official" release packages for the different platforms (Windows, MacOS and Linux).

Currently, weekly builds are all handled using the conda platform. Release builds too, for MacOS and Linux. Conda is a really interesting open-source, cross-platform system that gathers the capabilities of a build system and a package manager.

On Windows, though, the FreeCAD executable must be packaged into an installer, so there is an extra step, which is currently done manually, outside the conda platform.

We're trying to better document all this process, so others can help working on these packages, and also make the official FreeCAD installer packages more seamlessly installable.

Another issue we have is that main commercial platforms, basically Windows and MacOS, are increasingly trying to restrict the ability for users to install applications not coming from their own stores. More than often, users are nagged by "warning! You are trying to install an unsafe application!" dialogs when trying to install FreeCAD.

While we're also trying to bring FreeCAD on these stores, it is a pretty complex process which takes big amounts of time and money. So while we're still not there we are also trying to make the current FreeCAD packages a bit more recognized as safe by these platforms, by having them digitally signed. This is another complex problem that also takes a lot of research, as these platforms put a lot of conditions.

Is all this really bettering the security of these platforms? I have my doubts there, it seems much more like a commercial move to force application developers to use the stores, which generates big revenues (they take about 30% of the developer earnings, without having to do much). Anyway, we're decided to try to get FreeCAD there, as long as it does not harm the open and free nature of FreeCAD and does not cost us a fortune.

FPA issues

That's it for this week! Thanks again to everybody who sponsors me on Patreon, LiberaPay or GitHub! See you next week or so!

by Yorik on 14.07.2023 in freecad , opensource , nativeifc

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