Congratulations, we are always grateful for your work in the FC BIM area, among countless other contributions!
I would like to take this opportunity to ask you a few questions:
We see that the IFC classification has been evolving and expanding its scope, but generally speaking, how far will the IFC classification go? Is the idea that one day it will cover all the details of a project and the native IFC file will be almost as broad as the standard FC file? Or, on the contrary, will they keep it as simple as possible, since its focus is to be universal? It should focus on the most common elements of construction, avoiding going into too much detail. That is, will we always need to have the native FC file as the basis for our projects?
I understand that by classification you mean the system of giving classes to elements, right? Well I think the idea is indeed to cover everything. Note that there are more precise classes, and other more generic for when you don't have a correct class for your object. I've seen files where everything is a IfcBuildingElementProxy (the most generic one).
In FreeCAD, at the moment, IF you need to work with IFC, then you still need the IFC file together with the FreeCAD file. But I'm studying a way to bypass that (have the IFC file embedded inside the FC file).
Basically many people don't need very precise IFC control. They just want to model and maybe at some point export an IFC file, that's all. So that should always be possible with FreeCAD. When we are at a point where it doesn't matter if you use nativeIFC or not, then we might think of retiring the "non-IFC" system, but IMHO there is till some way to go :)
Well that's a vast question. Basically, in a nutshell:
There is no provision or structure for parametric objects in IFC
There is broad support for custom properties. That's basically all we need.
See what inkscape does: It produces generic, valid SVG, but wit additional properties that only inkscape sees. So, when you have for ex. a star, any SVG app renders the star correctly, because it is saved as a standard, generic path object, but when you edit it in inkscape, it knows it is a star, and it offer you the correct controls (you can change the number of spikes, etc). When you change the star, the path is regenerated.
I believe that's the way we should go with parametric IFC. We store a generic IFC object, but with all the properties needed by FreeCAD to understand and recreate the parametric object. Other applications won't use these properties (unless of course we could think together with Bonsai people and use a common system ;) )
Completely agree. IFC doesn't, and shouldn't define how parametrics works, since how parametrics works is a really big question that changes faster than ISO standards can keep up. Who knows, in a few years we might have AI-generated parameters.
But if we agree on a way to specify "This is externally generated" and "The ID of the exteneral generator is X", that should be enough for any software to lookup the rules of "X" and selectively implement "X".
Ok, I understand. This is all very interesting, indeed!
In the image below, I left the Equipment next to the original objects for better visualization of both.
In the case of the chair mentioned, I inserted it into a BIM Arch_Equipment. But only after exporting to IFC that the BIM component start to track the changes in the chair's properties. It seems that the link is enabled only after this operation. However, the resulting IFC file is empty. Only by exporting the “Chair_#_” folder that I get an IFC of the file. I am using version 1.0 of FC.
The BIM Arch_Site worked well with the parametric terrain, except that some elements must be removed so that they do not merge with the final IFC (the section volume, for example).
It is not possible to perform the same process for parametric doors and windows. Would it be possible to modify the respective BIM tools for this (Arch_Window and BIM_Door), or simply add them to the existing list of doors and windows, as was done in the past? Please let me know.
Well, my intention is to start the process of translating parametric components to IFC format. Guidance and suggestions are welcome.
If this discussion must be in another post, let me know.
If this discussion must be in another post, let me know.
Yes, probably, so it does not get buried here :)
About the specific problems you encountered, the best way is to open issue(s) on the FreeCAD repo and let people look at the files, it's hard to reply without trying...
About the parametrics things, we could formulate the problem like this: How to define a parametric door, or window, only with properties? What set of properties would allow to define a window precisely (there is one and only one window that can be made from the values), completely (there is nothing missing) and as extensive as possible (with the same set of properties we could do , let's say, 95% of the windows of the world? Or 90?)
When we have that set of properties, I think we can almost say the coding is the easy part :)
The first part was clear, no problem. But the second, regarding parametric doors and windows, not so much.
My two suggestions were: modify the corresponding BIM workbench tools to incorporate any object designed to be interpreted as a door or window (parametric or not), as we can do with Site or Equipment; or incorporate the parametric doors and windows component into the existing list, as was done in the past, in this case behaving as a library insertion.
If this second option is not viable, we could consider the first.
In general, parametric components do not need to achieve such a high coverage (90 to 95%) as an initial condition for their development and application.
I understand that developing a parametric component for later codification would be another matter. It would be a new, very ambitious and not easy work front. It was not intentionally part of my suggestions. Ok?
@F_Rosa said:
My two suggestions were: modify the corresponding BIM workbench tools to incorporate any object designed to be interpreted as a door or window (parametric or not), as we can do with Site or Equipment; or incorporate the parametric doors and windows component into the existing list, as was done in the past, in this case behaving as a library insertion.
You meant using your parametric object as Base of Windows?
I understand in general all FreeCAD BIM/Arch Objects are extremely flexible and users can use ('encapsulate') any object with Shape created by any workbench in FreeCAD to be its Base. For your case, either Arch Window, or Arch Equipment (users can assign its Ifc Class as Window), or even any Arch Objects, can use your parametric object as its Base.
We need to establish a workflow for this. In the example shown, it would be necessary to incorporate the subtraction volume as well, so that the void of the wall follows the change in the dimensions of the component.
Comments
Hi @yorik ,
Congratulations, we are always grateful for your work in the FC BIM area, among countless other contributions!
I would like to take this opportunity to ask you a few questions:
We see that the IFC classification has been evolving and expanding its scope, but generally speaking, how far will the IFC classification go? Is the idea that one day it will cover all the details of a project and the native IFC file will be almost as broad as the standard FC file? Or, on the contrary, will they keep it as simple as possible, since its focus is to be universal? It should focus on the most common elements of construction, avoiding going into too much detail. That is, will we always need to have the native FC file as the basis for our projects?
I understand that by classification you mean the system of giving classes to elements, right? Well I think the idea is indeed to cover everything. Note that there are more precise classes, and other more generic for when you don't have a correct class for your object. I've seen files where everything is a IfcBuildingElementProxy (the most generic one).
In FreeCAD, at the moment, IF you need to work with IFC, then you still need the IFC file together with the FreeCAD file. But I'm studying a way to bypass that (have the IFC file embedded inside the FC file).
Basically many people don't need very precise IFC control. They just want to model and maybe at some point export an IFC file, that's all. So that should always be possible with FreeCAD. When we are at a point where it doesn't matter if you use nativeIFC or not, then we might think of retiring the "non-IFC" system, but IMHO there is till some way to go :)
This is very interesting!
I don't know if this would be the place for this type of question, but if not, please tell me, it was a question raised here in another post.
https://community.osarch.org/discussion/2694/parametric-components-doors-and-windows#latest
In the case of parametric components in FC, what do you think would be the best way to leave them preconfigured for the IFC version, without losing their configurable properties? I know doors and windows are more complicated, but let's start with a simple example: this chair:
https://github.com/Francisco-Rosa/FreeCAD-library/blob/master/Architectural Parts/Living room/Chair.FCStd
Based on this example, I can start leaving the other components preconfigured for the IFC format, as far as possible.
Well that's a vast question. Basically, in a nutshell:
I believe that's the way we should go with parametric IFC. We store a generic IFC object, but with all the properties needed by FreeCAD to understand and recreate the parametric object. Other applications won't use these properties (unless of course we could think together with Bonsai people and use a common system ;) )
Completely agree. IFC doesn't, and shouldn't define how parametrics works, since how parametrics works is a really big question that changes faster than ISO standards can keep up. Who knows, in a few years we might have AI-generated parameters.
But if we agree on a way to specify "This is externally generated" and "The ID of the exteneral generator is X", that should be enough for any software to lookup the rules of "X" and selectively implement "X".
Specially if X is, you know, open source ;)
Ok, I understand. This is all very interesting, indeed!
In the image below, I left the Equipment next to the original objects for better visualization of both.
In the case of the chair mentioned, I inserted it into a BIM Arch_Equipment. But only after exporting to IFC that the BIM component start to track the changes in the chair's properties. It seems that the link is enabled only after this operation. However, the resulting IFC file is empty. Only by exporting the “Chair_#_” folder that I get an IFC of the file. I am using version 1.0 of FC.
The BIM Arch_Site worked well with the parametric terrain, except that some elements must be removed so that they do not merge with the final IFC (the section volume, for example).
It is not possible to perform the same process for parametric doors and windows. Would it be possible to modify the respective BIM tools for this (Arch_Window and BIM_Door), or simply add them to the existing list of doors and windows, as was done in the past? Please let me know.
Well, my intention is to start the process of translating parametric components to IFC format. Guidance and suggestions are welcome.
If this discussion must be in another post, let me know.
Thank you.
Might be worth linking this conversation as well: https://community.osarch.org/discussion/1738/standardizing-bbim-property-sets
and a high level stab at it once: https://gitlab.com/osarch/FreeMVD_WorkFlow/-/blob/1dfb0048fca1d4bebabf778e96e2c17433ac1aed/Standard_BBIM_PSets/Standard_BBIM_PSets.md
Yes, probably, so it does not get buried here :)
About the specific problems you encountered, the best way is to open issue(s) on the FreeCAD repo and let people look at the files, it's hard to reply without trying...
About the parametrics things, we could formulate the problem like this: How to define a parametric door, or window, only with properties? What set of properties would allow to define a window precisely (there is one and only one window that can be made from the values), completely (there is nothing missing) and as extensive as possible (with the same set of properties we could do , let's say, 95% of the windows of the world? Or 90?)
When we have that set of properties, I think we can almost say the coding is the easy part :)
Thanks, Yorik for the answers.
The first part was clear, no problem. But the second, regarding parametric doors and windows, not so much.
My two suggestions were: modify the corresponding BIM workbench tools to incorporate any object designed to be interpreted as a door or window (parametric or not), as we can do with Site or Equipment; or incorporate the parametric doors and windows component into the existing list, as was done in the past, in this case behaving as a library insertion.
If this second option is not viable, we could consider the first.
In general, parametric components do not need to achieve such a high coverage (90 to 95%) as an initial condition for their development and application.
I understand that developing a parametric component for later codification would be another matter. It would be a new, very ambitious and not easy work front. It was not intentionally part of my suggestions. Ok?
You meant using your parametric object as Base of Windows?
I understand in general all FreeCAD BIM/Arch Objects are extremely flexible and users can use ('encapsulate') any object with Shape created by any workbench in FreeCAD to be its Base. For your case, either Arch Window, or Arch Equipment (users can assign its Ifc Class as Window), or even any Arch Objects, can use your parametric object as its Base.
Arch Window/Door even has specially programmed to adopt shape formed by other workbench
- see https://wiki.freecad.org/Arch_Window#Defining_window_types. Just put the component into a App:Part container as explained in the wiki.
If user has sub-components to form a window component, I guess user may try put them into separate App:Part container.
Yes.
Ok. Could you, please, show us how to use whith the parametric doors window file as an example
(https://github.com/Francisco-Rosa/FreeCAD-library/blob/master/Architectural Parts/Doors_Windows/Doors_windows_module_01.FCStd)? I think it will be very ilustrative.
Thanks.
Just a quick test, a bit convoluted, just a proof of concept :)
Added 2 Links instances of the same Window, punching 2 more holes.
Thanks, @paullee!
We need to establish a workflow for this. In the example shown, it would be necessary to incorporate the subtraction volume as well, so that the void of the wall follows the change in the dimensions of the component.
Yes. Feel free to discuss if you have other problem.