I am currently trying to use IfcOpenShell to import IFC and calculate properties for the imported objects. We use Open Cascade in our application so it’s easy to calculate volume but anything beyond that is hard because all I have is the resulting TopoDS_Shape.
In the recent road map post I saw in version 0.9.0 “Retain Geometric operation history”, this looks like it could help a lot when it comes to computing properties for at least the ‘standard cases’ of IFC. However, it’s a long way down the road...
Do you have any tips about where I should start in the IFCOpenShell code if I wanted to look into how this could be implemented on our end? Any ideas on methodology?
Thanks,
Ian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yeah, interesting question. How I think of it now, is that it is some sort of tree structure of atomic geometric operations that generalize and decompose the representation items in IFC. For example, an IfcExtrudedAreaSolid is an extrusion, but in addition has a placement position, so this would become in fact two operations, an Extrusion and a Transformation. The ObjectPlacement of a product would be represented as a Transformation as well, same as mapped items. Openings elements, CSG operations and clipping would all be represented as Boolean operations. This way many of the redundancies in the code base can actually be reduced. A rough sketch of such a structure:
That said, I am not sure if it would help your case tremendously. You can already descend down the representation items of the original IFC graph. Use convert_wire() for example to convert the Axis representation of its wall, to find its length.
I am open to your input of course.
Kind regards,
Thomas
Last edit: Thomas Krijnen 2015-10-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I am currently trying to use IfcOpenShell to import IFC and calculate properties for the imported objects. We use Open Cascade in our application so it’s easy to calculate volume but anything beyond that is hard because all I have is the resulting TopoDS_Shape.
In the recent road map post I saw in version 0.9.0 “Retain Geometric operation history”, this looks like it could help a lot when it comes to computing properties for at least the ‘standard cases’ of IFC. However, it’s a long way down the road...
Do you have any tips about where I should start in the IFCOpenShell code if I wanted to look into how this could be implemented on our end? Any ideas on methodology?
Thanks,
Ian
Hi Ian,
Yeah, interesting question. How I think of it now, is that it is some sort of tree structure of atomic geometric operations that generalize and decompose the representation items in IFC. For example, an IfcExtrudedAreaSolid is an extrusion, but in addition has a placement position, so this would become in fact two operations, an Extrusion and a Transformation. The ObjectPlacement of a product would be represented as a Transformation as well, same as mapped items. Openings elements, CSG operations and clipping would all be represented as Boolean operations. This way many of the redundancies in the code base can actually be reduced. A rough sketch of such a structure:
That said, I am not sure if it would help your case tremendously. You can already descend down the representation items of the original IFC graph. Use convert_wire() for example to convert the Axis representation of its wall, to find its length.
I am open to your input of course.
Kind regards,
Thomas
Last edit: Thomas Krijnen 2015-10-02
Hi Thomas,
I think you are right; we have started using IFC data (like the Axis of an IfcWall) during import to compute our proporties.
Thanks for the tip :)
Ian