It is really fast ! On my 10 years old i3, it loads IFC Schependomlaan.ifc in 5 s :lol:
0:05 - No Representation (a cube appear :roll: )
0:27 - Coin Representation
1:09 - Full Shape
NativeIFC: Edit placements: This has been a bit of a headache, because of several aspects: 1) Placements in IFC are notoriously a complex affair, 2) Placement matrixes are different in FreeCAD and IfcOpenShell, and 3) Placement properties are triggered pretty often in FreeCAD, and there was a whole question of sorting out when the IFC placement of the object needed to be updated. This is now all (hopefully) sorted out, and you can now edit placements of IFC objects in FreeCAD, which will correctly reflect on the stored IFC placement. This means changing the placement of an object manually works, but also all other commands that work on placements, such as the Move command. As this is using the IfcOpenShell API, all needed internal complexity of dealing with local and relative placements is taken care of magically! commit
FreeCAD: Draft memory leak: The Draft workbench has had a nasty memory leak for a very long time, which means the memory usage is increasing during use. Usually this is normal when running a program, as structures (data, variables, etc...) are created during the execution, that take space in memory. However, there are usually destruction mechanisms in place, for example all variables or objects created inside a function are automatically destroyed when the function ends, or there are garbage collection systems that automatically clean up unused variables and data structures. A memory leak occurs when something escapes these mechanisms and is not automatically destroyed, and is recursively being created, which makes the memory consumption raise over time. The Draft workbench has had one of these for a long time. To see the effect by yourself, you just need to start a Draft command such as Line, click a point and simply hover your mouse around instead of clicking the second point. If you watch the memory consumption (for example running top -p $(pidof freecad) in a terminal), you will see a small memory increase. This used to be huge, and is now mostly solved, as the garbage collection manages to keep it under control and in the long run, memory usage does not increase anymore. There is however still some minor leak happening, that I couldn't pinpoint yet. There are so many things happening in Draft, with so many different parts of FreeCAD involved (Qt interface, widgets on the Coin3D view,...) that it turns debugging very difficult. issue - PR
NativeIFC: Allow to delete objects: Deleting an object in FreeCAD now correctly deletes the corresponding object in the IFC file. As usual when using the IfcOpenShell API, everything is taken care of automatically, and all needed subobjects and dependencies are deleted automatically too. As always, when you perform an operation that affects internal IFC objects, the project object is marked as modified, and by right-clicking it in the tree view you can select "Show Diff..." to see the modifications that have been made to the IFC file. This is a great way to make sure the right operation was done. commit
NativeIFC: Allow to collpse children: You can now perform the reverse operation to "Expand children": When an object has its children expanded, you can now reverse the operation by right-clicking the object and choosing "Collapse children". The child objects (and all their descendents too) will be removed from the FreeCAD document, causing the base object to gather and show the shapes of them all. This allows you to keep your FreeCAD document fast and light, even when working on large IFC files, by shrinking the structures you don't need to edit. commit
This took quite some time to thoroughly test and fine-tune, but it is now working satisfyingly. It is basically the GUI counterpart of the aggregate() function I added last time. It allows to take any FreeCAD object, BIM or non-BIM, and add it to a NativeIFC document just by dropping it onto any NativeIFC spatial structure (site, building, storey or space) or object (in which case the new object becomes aggregated to the host object). This basically allows to create just any kind of NativeIFC object.
Sorry to be slightly off topic, but how did you manage to aggregate multiple IFC elements to one IFC element assembly with ifcopenshell?
I see this snippet:
i assume the strings you used (like "ifc_assembly_element") are not really strings in your code, right? they should be actual IfcOpenShell objects.
I am not sure if you can add several objects in one go. Maybe you need to run the API command several times. But it should even so add the subsequent objects to the same IfcRelAcgregates.
@yorik said:
i assume the strings you used (like "ifc_assembly_element") are not really strings in your code, right? they should be actual IfcOpenShell objects.
I am not sure if you can add several objects in one go. Maybe you need to run the API command several times. But it should even so add the subsequent objects to the same IfcRelAcgregates.
Yes, they're not string but IFC elements, I managed to make it work but I get some strange behaviour. It only aggregates the last IFC element in the for loop and why I load it in BlenderBIM. Maybe I should make a different thread about it.
NativeIFC: Default project structure: When you create a new project from scratch using the BIM Project tool, you will now see a dialog asking if you also wish to create a default project structure (Site, Building and Storey) under it. Note that this is not strictly mandatory by the IFC specs, you can very well have a flat file where all objects are simply related to a (mandatory) IfcProject. However, this site -> building -> storey structure is considered by many BIM applications as a standard. Your choice! ;) commit
NativeIFC: Better attributes handling: I reenabled the display of non-link attributes (those that don't link to other IFC entities) by default when importing a file, as it seems to me they cannot change the geommetry or affect other objects so they should be safe for now, but this needs to be explored further. The "Description" property contents will also now show in the "Descriptipn" column of the FreeCAD tree view. commit
NativeIFC: Support for IfcSpaces: Spaces are now handled, displayed in the tre view when importing the project structure or expanding the children of an object. You can also add objects to an IfcSpace. The shape of IfcSpaces is shown in wireframe mode in the 3D view when the shape is loaded. In coin mode, you don't see anything in the 3D view (for now... better ideas are welcome). commit
NativeIFC: Loading of orphan objects: An IFC file might contain objects that are not related to an IFC project. This is not standard, but it is still used around and might even actually be a useful thing, for example in Work-In-Progress files where it was not clear to the author what would become of a certain object. In the import dialog, there is now an option to import these "orphan" objects. They will be placed into a special group under the project object. This feature is not complete yet, because we still need to permit people to add their own objects to that group. commit - issue
NativeIFC: First steps towards geometry edition: This is probably the most exciting feature of the lot: The ability to edit IFC objects. This is still an experiment to see if this is a valid path to follow, but it's proving really interesting so far. Basically, objects gained a new "expand geometry properties" right-click menu option. When that option is clicked, a new "Geometry" property group is created, and a few properties are added to it tha allow to edit the geometry. So far, you can edit the extrusion depth and direction of extruded objects, and length and width of their profile, if that profile is a rectangle. This works really well for Arch walls and structures (rectangular beams and columns). I'll add more types on the way. There is more to iron out too, such as updating the object history. And later on, of course, we should integrate all this in an edit mode and implement tools to edit these values graphically. But I think this is a pretty interesting start. commit
NativeIFC: Show geometry tree: Importer IFC objects now have a new "Show geometry tree" context menu option. This option pops up a dialog window that shows the geometry decomposition of that object. This has no direct utility when you are modelling, but can be very useful for debugging, and also to learn the internals of how IFC objects are constructed. You can also of course use this from Python. commit
NativeIFC: Expose IFC property sets: You can now right-click any IFC object, and choose the new "Expand IFC property sets" option. Alternatively, you can also mark the "load property sets" option on the import dialog. When choosing that option, property sets attached to an IFC object appear in the properties panel of the object. At the moment, you can change the value of a property, which will correctly change the IFC file. However, the owner history of that object is not changed, I'm not sure it needs to, and you still cannot add new properties or new property sets. I'm not too sure how to handle this yet, as we might want to allow adding or even bulk-adding default psets like Pset_WallCommon automatically. I guess we'll go step by step and first allow to add new properties ;) commit
Looks cool! this kind of UI lends its better for displaying information of an IFC than BlenderBIM in my opinion.
Are you going to integrate IFC git in FreeCAD next? :-)
What's the drawing generation status of FreeCAD with native IFC at the moment?
Are you going to integrate IFC git in FreeCAD next? :-)
It's not in my immediate plans (also because we already have something similar in the WebTools addon), but of course keeping an eye on it ;)
What's the drawing generation status of FreeCAD with native IFC at the moment?
The current BIM workflow still works with NativeIFC models. So you can still create plans, sections, dimension and annotate and everything the normal way. Only, those things are not part of the NativeIFC model. But the plan is of course to integrate that too, and I also want to test using IfcOpenShell to generate the 2D views
FreeCAD: release 0.21: As you might have seen in the mass media on social networks, we are preparing a new release of FreeCAD, which will be labeled 0.21. Hopefully, that's the last one before the big 1.0. We wanted this one to be 1.0 already, but it's better to do this the right way and given things the time they need than trying to stick to a predefined plan. After this 0.21 release, we will start merging toponaming code that can affect FreeCAD performance too, so it also makes sense to have a stable version now. The release date will depend on many factors, but we estimate it should be ready in about one month from now. announcement - help us!
NativeIFC: support for doors and windows: You can now create windows and doors from scratch in FreeCAD and add them to a NativeIFC project. The workflow is the same as other NativeIFC-ready objects, you create a window or a door using usual BIM or Arch tools, then you drag and drop it onto a wall. Simple as that! An opening will be generated automatically and the necessary relationships added to the IFC document. If you use other tools than Arch/BIM to model your window, make sure it has a "Subvolume" property pointing to a shape object that defines the opening volume otherwise no opening will be created in the host object. commit
NativeIFC: editing openings: When expanding individual IFC objects, windows and doors are shown embedded into their parent object (typically a wall). When expanding the children of that wall, both the opening element (which creates the "subtraction" in the wall) and the window or door that fits ito it get revealed. So we now have a possibility to edit the opening too, by moving it together with the window, or changing its extrusion parameters if it is extruded. commit
FreeCAD: Misc fixes: I also did a couple more BIM-related fixes in FreeCAD:
There is a lot of information that needs to be loaded from an IFC file, that is not geometry, for example materials, types, layers, etc... that should be organised inside the IFC project, that should be visible and manageable by the user, at times, but that should also not otherwise pollute your project tree.
All this data is loaded only when you request it (when marking the appropriate checkboxes on the import dialog or by right-clicking an object in the tree) and placed into those hidden groups. You can show them by right-clicking the project and choosing "show hidden items". There is also a preference option under Edit -> Preferences -> I/O -> NativeIFC to have these groups shown by default.
There is, together with this point above, a whole lot of new functionality in NativeIFC that is, at the moment, loosely gathered under the right-click context menu of objects. This is obviously not ideal, and is highly temporary. Simply, putting these things there at the moment is easy programming-wise as all the "UI" stuff is self-contained and in one place.
Obviously, we will need to better think to the UI later on. Ideally, I'd like all these tools to simply vanish, and the needed functionality to be expanded automatically and transparently while you work. I'll start experimenting with that soon.
NativeIFC: Editing the geometry tree
By right-clicking any object, you could already select "show geometry tree" and pop up a dialog window showing the geometry composition of that object. Since geometry can be constructed in a lot of different ways in IFC, this is useful info. Now, that dialog shows a side panel that allows you to select geometric components and modify some of their properties.
This is a work in progress, one step further in exploring possibly smart ways to edit IFC geometry without creating a ton of FreeCAD objects and keeping large models responsive, and might change more in the future. But it's amazing to see how revealing properties like these allows in terms of geometry editing.
And of course, once the "problem" is expressed in properties, the whole UI question next, that is, how to edit these properties graphically, gets much easier to solve. I think we are on a good path there.
Another important item on our list is now done: materials. You can now load all the materials from an IFC file at once, or right-click any object and load its materials. Materials are then stored into one of the hidden groups I described above, and linked to a "Material" property of the object. Within the BIM workbench, you can also create and manage materials the standard way, with the materials manager, and attribute those materials with the same material manager, as if it were a classic, non-NativeIFC material. Under the hood, when attributing a non-NativeIFC to a NativeIFC object, the material gets converted to NativeIFC.
So the basic system is now working, you can view, create and manipulate materials. There are more refinements needed, such as supporting material properties, and probably a better UI workflow, but I guess we need to test a bit how things work now to know better.
The current Type property is confusing. Soon we will implement types (families) support. So better change now than later. So from now on, the object type (IfcWall, IfcWindow, etc) is called class.
You can now drag an IFC element and drop it onto a building or storey, everything gets handled and reorganized smartly. It was actually already possible, but I just checked different scenarios to make sure it works
This is not fully working yet because it needs changes in FreeCAD, but you can now right-click a building structure object, like a building or storey, and make it active. When an object is active, it is highlighted in the tree, and when you create a new object it will automatically be added to it.
Right now you can already mark an object as active, and when the PR is merged, all new BIM objects will automatically be added to it.
IFC objects can have different representations. For example, a wall can have a 3D shape and a 2D shape that is used in plan view (not sed/implemented yet in FreeCAD/NativeIFC, but we'll get there). Another representation type that is very useful, is an axis representation, which is a simple line that describe the object. So far, only the walls used it, but it's also commonly used for stucrtural elements like bams and columns. Now this is also supported in FreeCAD.
I reworked a couple of less polished parts of the NativeIFC code, and now each and every action that touches the IFC document (excepting creating new IFC representations, which still use the Arch IFC export code), use the IfcOpenShell API. Besides the increased stability and reliance on IfcOpenShell, it also has the side effect that we always know when the internal IFC file has changed. So we now have a much more reliable way to know that, and we can think of automatic operations such as writing the changes on the fly, or later on plugging to other management systems like Git.
@yorik would consider to use the IFC Representation dialog box table on the right to edit the properties?
Yes, you can already, but I'm not sure how good a workflow that is. Certainly we can do something better. Consider this preliminary, until we find something better ;)
@yorik would consider to use the IFC Representation dialog box table on the right to edit the properties?
Yes, you can already, but I'm not sure how good a workflow that is. Certainly we can do something better. Consider this preliminary, until we find something better ;)
Hmmm, I tested with IFC Schependomlaan.if, seems e.g. I can change the ELEVATION attribute from +1000 to +1500
But changing the CompositionType is not working...
Comments
NativeIFC!
Cross-posting test results of latest (No Representation) NativeIFC import mode :D
https://forum.freecad.org/viewtopic.php?p=666531#p666531
It is really fast ! On my 10 years old i3, it loads IFC Schependomlaan.ifc in 5 s :lol:
0:05 - No Representation (a cube appear :roll: )
0:27 - Coin Representation
1:09 - Full Shape
the cube is a temporary workaround for the group extension bug. it should vanish in the future
FreeCAD BIM weekly update 16.03.2023
https://yorik.uncreated.net/blog/2023-011-freecad-weekly4
FreeCAD BIM weekly update 24.03.2023
https://yorik.uncreated.net/blog/2023-012-freecad-weekly5
thanks @bitacovir ?
FreeCAD BIM weekly update 30.03.2023
https://yorik.uncreated.net/blog/2023-013-freecad-weekly6
FreeCAD BIM weekly update 14.04.2023
https://yorik.uncreated.net/blog/2023-014-freecad-weekly7
top -p $(pidof freecad)in a terminal), you will see a small memory increase. This used to be huge, and is now mostly solved, as the garbage collection manages to keep it under control and in the long run, memory usage does not increase anymore. There is however still some minor leak happening, that I couldn't pinpoint yet. There are so many things happening in Draft, with so many different parts of FreeCAD involved (Qt interface, widgets on the Coin3D view,...) that it turns debugging very difficult. issue - PRFreeCAD BIM weeky dev news 8: https://yorik.uncreated.net/blog/2023-015-freecad-weekly8
From the blog:
Where can I find this code snippet? :-)
there is a "commit" link in the article: https://github.com/yorikvanhavre/FreeCAD-NativeIFC/commit/b20ad5d246443e952272bf07ba413e0918affe7e
Ohyes, I see. At the end of the alinea. Comprehensive reading was never my strong point ?
i must admit it's a bit buried :)
@yorik
Sorry to be slightly off topic, but how did you manage to aggregate multiple IFC elements to one IFC element assembly with ifcopenshell?
I see this snippet:
But I would to like to assign multipe elements at once like this pseudocode:
I have not been succesful with this method
i assume the strings you used (like "ifc_assembly_element") are not really strings in your code, right? they should be actual IfcOpenShell objects.
I am not sure if you can add several objects in one go. Maybe you need to run the API command several times. But it should even so add the subsequent objects to the same IfcRelAcgregates.
Yes, they're not string but IFC elements, I managed to make it work but I get some strange behaviour. It only aggregates the last IFC element in the for loop and why I load it in BlenderBIM. Maybe I should make a different thread about it.
Dev new 9: https://yorik.uncreated.net/blog/2023-016-freecad-weekly9
FreeCAD BIM weekly update 10
https://yorik.uncreated.net/blog/2023-017-freecad-weekly10
weekly update 11 from https://yorik.uncreated.net/blog/2023-018-freecad-weekly11
Looks cool! this kind of UI lends its better for displaying information of an IFC than BlenderBIM in my opinion.
Are you going to integrate IFC git in FreeCAD next? :-)
What's the drawing generation status of FreeCAD with native IFC at the moment?
It's not in my immediate plans (also because we already have something similar in the WebTools addon), but of course keeping an eye on it ;)
The current BIM workflow still works with NativeIFC models. So you can still create plans, sections, dimension and annotate and everything the normal way. Only, those things are not part of the NativeIFC model. But the plan is of course to integrate that too, and I also want to test using IfcOpenShell to generate the 2D views
Updates of this week from https://yorik.uncreated.net/blog/2023-019-freecad-weekly12
FreeCAD: release 0.21: As you might have seen in the mass media on social networks, we are preparing a new release of FreeCAD, which will be labeled 0.21. Hopefully, that's the last one before the big 1.0. We wanted this one to be 1.0 already, but it's better to do this the right way and given things the time they need than trying to stick to a predefined plan. After this 0.21 release, we will start merging toponaming code that can affect FreeCAD performance too, so it also makes sense to have a stable version now. The release date will depend on many factors, but we estimate it should be ready in about one month from now. announcement - help us!
NativeIFC: support for doors and windows: You can now create windows and doors from scratch in FreeCAD and add them to a NativeIFC project. The workflow is the same as other NativeIFC-ready objects, you create a window or a door using usual BIM or Arch tools, then you drag and drop it onto a wall. Simple as that! An opening will be generated automatically and the necessary relationships added to the IFC document. If you use other tools than Arch/BIM to model your window, make sure it has a "Subvolume" property pointing to a shape object that defines the opening volume otherwise no opening will be created in the host object. commit
NativeIFC: editing openings: When expanding individual IFC objects, windows and doors are shown embedded into their parent object (typically a wall). When expanding the children of that wall, both the opening element (which creates the "subtraction" in the wall) and the window or door that fits ito it get revealed. So we now have a possibility to edit the opening too, by moving it together with the window, or changing its extrusion parameters if it is extruded. commit
FreeCAD: Misc fixes: I also did a couple more BIM-related fixes in FreeCAD:
Update from https://yorik.uncreated.net/blog/2023-020-freecad-weekly13 :
NativeIFC: hidden project groups
There is a lot of information that needs to be loaded from an IFC file, that is not geometry, for example materials, types, layers, etc... that should be organised inside the IFC project, that should be visible and manageable by the user, at times, but that should also not otherwise pollute your project tree.
All this data is loaded only when you request it (when marking the appropriate checkboxes on the import dialog or by right-clicking an object in the tree) and placed into those hidden groups. You can show them by right-clicking the project and choosing "show hidden items". There is also a preference option under Edit -> Preferences -> I/O -> NativeIFC to have these groups shown by default.
commit
There is, together with this point above, a whole lot of new functionality in NativeIFC that is, at the moment, loosely gathered under the right-click context menu of objects. This is obviously not ideal, and is highly temporary. Simply, putting these things there at the moment is easy programming-wise as all the "UI" stuff is self-contained and in one place.
Obviously, we will need to better think to the UI later on. Ideally, I'd like all these tools to simply vanish, and the needed functionality to be expanded automatically and transparently while you work. I'll start experimenting with that soon.
NativeIFC: Editing the geometry tree
By right-clicking any object, you could already select "show geometry tree" and pop up a dialog window showing the geometry composition of that object. Since geometry can be constructed in a lot of different ways in IFC, this is useful info. Now, that dialog shows a side panel that allows you to select geometric components and modify some of their properties.
This is a work in progress, one step further in exploring possibly smart ways to edit IFC geometry without creating a ton of FreeCAD objects and keeping large models responsive, and might change more in the future. But it's amazing to see how revealing properties like these allows in terms of geometry editing.
And of course, once the "problem" is expressed in properties, the whole UI question next, that is, how to edit these properties graphically, gets much easier to solve. I think we are on a good path there.
commit
NativeIFC: Materials support
Another important item on our list is now done: materials. You can now load all the materials from an IFC file at once, or right-click any object and load its materials. Materials are then stored into one of the hidden groups I described above, and linked to a "Material" property of the object. Within the BIM workbench, you can also create and manage materials the standard way, with the materials manager, and attribute those materials with the same material manager, as if it were a classic, non-NativeIFC material. Under the hood, when attributing a non-NativeIFC to a NativeIFC object, the material gets converted to NativeIFC.
So the basic system is now working, you can view, create and manipulate materials. There are more refinements needed, such as supporting material properties, and probably a better UI workflow, but I guess we need to test a bit how things work now to know better.
commit
NativeIFC: Changed Type property to Class
The current Type property is confusing. Soon we will implement types (families) support. So better change now than later. So from now on, the object type (IfcWall, IfcWindow, etc) is called class.
commit
NativeIFC: Regrouping
You can now drag an IFC element and drop it onto a building or storey, everything gets handled and reorganized smartly. It was actually already possible, but I just checked different scenarios to make sure it works
commit
NativeIFC: Active containers
This is not fully working yet because it needs changes in FreeCAD, but you can now right-click a building structure object, like a building or storey, and make it active. When an object is active, it is highlighted in the tree, and when you create a new object it will automatically be added to it.
Right now you can already mark an object as active, and when the PR is merged, all new BIM objects will automatically be added to it.
commit - PR
FreeCAD: Export of structure axis
IFC objects can have different representations. For example, a wall can have a 3D shape and a 2D shape that is used in plan view (not sed/implemented yet in FreeCAD/NativeIFC, but we'll get there). Another representation type that is very useful, is an axis representation, which is a simple line that describe the object. So far, only the walls used it, but it's also commonly used for stucrtural elements like bams and columns. Now this is also supported in FreeCAD.
PR
NativeIFC: API use + auto changes of IFC file
I reworked a couple of less polished parts of the NativeIFC code, and now each and every action that touches the IFC document (excepting creating new IFC representations, which still use the Arch IFC export code), use the IfcOpenShell API. Besides the increased stability and reliance on IfcOpenShell, it also has the side effect that we always know when the internal IFC file has changed. So we now have a much more reliable way to know that, and we can think of automatic operations such as writing the changes on the fly, or later on plugging to other management systems like Git.
commit
A few screencapture of latest features :D
@yorik would consider to use the IFC Representation dialog box table on the right to edit the properties?
Yes, you can already, but I'm not sure how good a workflow that is. Certainly we can do something better. Consider this preliminary, until we find something better ;)
Hmmm, I tested with IFC Schependomlaan.if, seems e.g. I can change the ELEVATION attribute from +1000 to +1500
But changing the CompositionType is not working...
Indeed not everything works just yet... Normally all numerical values should work already, plus pure text like name, description, ...
@yorik and/or @bitacovir Wondering if name of this thread should add Native-IFC
e.g. - " [FreeCAD BIM + Native-IFC] development news by Yorik " ? :D
And combining thread - " [FreeCAD] Soon also with Native IFC support? like BlenderBIM " ?
( https://community.osarch.org/discussion/1183/freecad-soon-also-with-native-ifc-support-like-blenderbim )
Not sure we can change the title anymore... Also this thread comes from well before NativeIFC.
Maybe time to start a fresh new thread? :)
Indeed, it seems there is limitation in time to edit a post :) Probably bitacovir can't revise the topic now.