User:Mdjska

Proposal for Google Summer of Code (GSoC) 2022:
"Create visual programming nodes for generating BIM data with IfcSverchok" #43

Detailed project description

The first and foremost use case of IfcSverchok is to enable creating building models enriched with model data in accordance with the IFC schema in Blender. The scope of the planned components can be narrowed or extended depending on the rate of progress.

A mockup of a workflow creating an .ifc file based on existing geometry, is shown below. Since many of the components could be either generated directly, or be heavily based on, IfcOpenShell functions, the flowchart is expressed in quite high level nodes, that could be shown to the user. Still, the presented components are not comprehensive.

The question of what data type the geometry provided to the components would have, is left open right now. To begin with, it’s assumed that the geometry is fully modelled in either Blender itself (eg. with the help of BlenderBIM) or in native Sverchok nodes. Then the mesh or NURBS geometry would have to be translated to solids accepted by IFC. Another approach would be to directly generate geometry through the IfcSverchok components. This approach would be fully parametric, but would be quite labour intensive, both for the user and in development. Right now, it should be reserved for more complex elements that wouldn’t be intuitive to model through other methods. A mixed approach, of asking the user to provide a simple geometry like a surface or a curve, and then building the rest of the element based on it, could be beneficial. This would allow to automatically get the location of the element in the projects coordinate system, which can be troublesome for users if it has to be provided as cartesian points. At the same time, it gives the user an intuition of the elements placement in relation to the rest of the model. Example of this in the flowchart is creating an IfcSpace based on a boundary curve and a height or creating beams with different profiles, based on just a curve.

The presented workflow in general, is based around the idea of using IfcSpaces as a central concept to rapidly develop the whole building and fill in the more detailed information as it becomes available. This process is more in line with the typical design process, where architects would often start with abstract areas with the only information available about them being their intended use functions and rough sizes. This approach could allow the model to stay parametric, even when large parts of the geometry change at a later point. If the specific constructions are added to the spaces, instead of the other way around, the user can reshape the spaces or even change their plancement in relation to each other, without having to remodel any of the actual elements like the walls or floors. This would of course require, that the geometry isn’t modelled separately, but is coupled with the spaces’ parameters.

On the leftmost side, the IfcSpaces are created either from Blender/Sverchok geometry or by dimensions. An ordered list of points could also form the basis of the simple geometry. The resulting space or a list of spaces can then be parsed to a component that would associate related building elements to a space or spaces. It could place the instance of IfcBuildingElement in the space.BoundedBy and obj.RelatedBuildingElement properties. Class specific nodes would be written for all IfcBuildingElement by customising the CreateEntity function. Components for other relevant IfcElements could be added, and a “CreateCustomEntity” node would always give the user possibility to add another, not implemented, entity type.


Aparts from linking geometry, adding meta data like name and ID, the IfcElement creation nodes should all expose and give the possibility to set the relevant property sets. User should be able to find the names of property sets and their respective properties corresponding to the given class, and set their values. Another important feature is the possibility to assign materials to building elements. I imagine that a small library of typical materials (instances of IfcMaterial) and constructions made from these materials (IfcMaterialLayerSets) would come with the plugin and be available to be used simply by picking them from a dropdown menu. Alternatively, the user should be able to modify these standard materials or create their own from scratch. In that case, the ifc material properties, such as energy, mechanical, thermal and optical, should be exposed and the user should be able to assign as many as they wish. Simple unit tests could be implemented here; eg. if the model should later be used for daylight or energy analysis, then the material should require to eg. have the thermal conductivity and transmittance properties filled in. The user should be able to save custom materials and constructions to a local library of sorts and reuse them in the same or other project. The same could be implemented at IfcBuildingElement level. If multiple spaces are given, the component could try to find adjacencies between spaces and thus pinpoint if any constructions/elements are shared between them. The user, should then have the possibility to easily define these elements with different specifications, eg. another construction type. The possibility to assign elements in a more manual manner, by eg. directly picking the associated space face, or completely detached from the space, should also be possible. Finally, implementing occupancy or other schedules on a space level would be desired. These could though also be implemented on zone, building storey or building level. The resulting object, would still be an IfcSpace, but with relational data on all bounding elements.

Further, the model creation would continue upwards in a hierarchical manner. Optional IfcZones could be created from multiple IfcSpaces. The same with IfcBuildingStoreys. Building storeys or the IfcBuilding itself, should contain all other building elements, that cannot be associated with one IfcSpace. This could be large facade walls, curtainwalls, slabs, roofs, beams etc. IfcBuilding would contain some typical meta data like name, address, elevation etc., but could also be enriched with more advanced data like occupancy type or details on the HVAC systems used. IFCSite could additionally contain a geometrical representation of the terrain itself, but also the context geometry and vegetation, that could, among others, be used for daylight and energy simulations. Material properties or schedules of this optional context geometry could also be added here. The IfcProject should add the final information on owner history, IFC schema version, define the coordinate system, the true north and units. Conversions to other classification systems like the Uniclass or Omniclass could also be implemented, either by a predefined or user-defined mapping of Ifc codes to other classification codes. Small unitests checking for example if any of the elements clash (self intersect) or if the model contains all required objects could be added as a final step before writing the file. When all is ready, multiple ways of writing and exporting should be possible; obviously a .ifc file, but also a .JSON file and maybe a .xml file. The possibility to export only parts of the model, eg. without the geometry, or after a filtering, should also be possible. A simple quantity takeoff (possibly using IfcQuantitySets) should be possible to export easily. Especially the material quantities, eg. subdivided by types or spaces, could be helpful for environmental analysis. A light model containing only the spaces and relevant properties of their constructions (could it be exported as .gbxml?) would be useful for energy or daylight analysis with EnergyPlus or Radiance.

Lastly, the grouping at the bottom, shows ideas for additional nodes that would be helpful. It contains, among others, nodes for decomposing all created classes and entities from libraries like materials, constructions and schedules. Querying and filtering elements based on names, ids and all associated attributes and then modifying, displaying or deleting the elements, would also be essential. Doing this on a existing, imported .ifc file would finalise the basic version of the tool.

Links to code I intend to use

The work will be a continuation of IfcSverchok nodes found on https://github.com/IfcOpenShell/IfcOpenShell/tree/v0.7.0/src/ifcsverchok.

IfcOpenShell python API (https://github.com/IfcOpenShell/IfcOpenShell/tree/v0.7.0/src/ifcopenshell-python) will be utilised in many of the nodes.

Other functions from the BlenderBIM and native Sverchok code base will also be used.

Possibilities for further development

There is a huge potential for future development on top of a working, parametric IFC tool. Firstly, the described use case only utilised a selected part of the IFC schema, especially related to buildings. Many other features and details can be implemented in the building realm, but also whole other parts of the schema geared towards other infrastructures like bridges, tunnels and reads exist. Together, local urban plans and environments around the building could be modelled using IFC. Taking an IfcSpace first approach would presumably make it easy to associate the models with Ladybug tools’ Honeybee zones, enabling many environmental simulations. Constructions and materials could be linked to EnergyPlus’ or OpenStudio libraries making simulations seamless. Materials could also be linked to environmental Life Cycle Inventory Analysis (LCIA) data like Ecoinvent or Environmental Product Declarations (EPDs) from databases like the German ÖKOBAUDAT. Such a mapping would greatly simplify export to any environmental software like OpenLCA or other. Structural analysis and costing are yet another areas that could be built on top of IfcSverchok.

The nodes could possibly also be ported to FreeCAD using PyFlow and support the native IFC workflow. Maybe could some of the FreeCAD parts library (like the architectural parts) even be made available directly in Sverchok, making it possible to create native IFC models very efficiently.