Here's the Sverchok take on the table:
The stretching part stays the same, (twice for two axes of the table, once for the chairs), there are only five new nodes for the array.
That looks awesome, it's a good mix of regular meshes plus purely procedural.
However for the chairs how do you propose to preserve the arcs? I also notice that the edges are all separate, is there a way to keep that all as one connected polyline (otherwise we'd generate a lot of edges, or have to reverse engineer the polylines afterwards)
Well in this case sverchok doesn't really care if it's a mesh or a curve, so if we output directly to ifc it only depends on the input.
I'm more worried about the previous question, @nikitron - does sverchok know it's finished calculating? Can we just load a sverchok script, update once, export the output and move to the next sverchok script?
But how would it output directly to IFC? Blender doesn't have the concept of a circle or a 3 point arc, so we can't use that to replace the mesh input that you have, Blender also doesn't support polygons with inner voids, so we'd have to tessellate them, so I'm not quite sure how Sverchok can help here ... unless you're suggesting a bunch of IFC nodes in Sverchok?
@Moult said:
Or maybe Blender is the wrong tool for this? What if this was implemented in FreeCAD instead? They have the parametric solver, it can be scripted, it can connect to BOLTS, and it can export out true curves and circles to IFC.
FreeCad supports configuration tables https://forum.freecadweb.org/viewtopic.php?t=42183
So its quite a good tool for this... I Imagine we could have a parametric object controlled by a table that could change more representation objects at once and bake them to IFC...
I Guess It could be quite similar to Revit workflow when editing a family...
@JanF yeah unfortunately the IfcSverchok nodes aren't capable of that (yet), and it's still quite a bit of time until that happens (although if we did the Python-based OpenSCAD inspired IFC functions I suggested earlier, those could later then be turned into nodes).
Blender curves don't quite meet the requirements of IFC profiles, IFC profiles are straight segments plus 3 point arcs, or circles. Blender curves are not true circles, don't know they are circles, and aren't 3-point arcs. That's why they were never used for the profile editing tool in the BlenderBIM Add-on, because they aren't appropriate.
@carlopav indeed FreeCAD might be a good solution, how does FreeCAD work right now with supporting exporting individual IFC extrusions with inner boundaries and indexed polycurves with line segments and arc segments? To me those are the critical parametric features I'd like to retain (I assume mesh support is no problem).
@Gorgious said:
What about geometry nodes curves ?
The problem is not that blender can't draw a curve in the form of a circle, it can, it just doesn't know it's a circle. So to map it to ifc curves (straight+arcs) you'd have to use some analysis. (But for example rhino or vectorworks can do that, I'm just not sure how reliable the algorithms are)
Another solution is to do something similar to OpenSCAD's language but create our own sort-of-DSL that's really just a bunch of clean Python functions that is IFC based. This would mean that arcs / circles are preserved, and extrusions vs meshes are also preserved. It would also mean that the IFC would be more "native" rather than reverse engineering results from Sverchok/SolveSpace/FreeCAD/Blender Shapekeys, drivers, rigs, etc.
I'd take this over FreeCAD then, how complicated is it to create the "DSL" (if I understand it correctly it's just a python library for geometry creation right)?
Yeah the more I think about it even if we do use FreeCAD there would still be reverse engineering, which is totally fine for other bolts backends (and maybe even ideal for FreeCAD as a BOLTS backend) but it seems the only way to fully guarantee high quality IFC is to ... well, write code specific to IFC.
I think it's actually pretty easy to write. Simple things like rectangle, circle, and indexed polycurve (with maybe 2-point arc and 3-point arc helpers) is all that is necessary for 2D, followed by an extrusion function and maybe a few shortcuts for cubes and cylinders (which is just the rectangle / circle + extrusion). Booleans are already handled by IFC so just a stack is all that needs to be done.
Once this is written, then we can actually convert it to nodes, or use it as the basis for more detailed solid modeling features in Blender / FreeCAD (kind of like the new profile editing tool), or even leave it as a script so that people can use pure code to generate complex IFC geometry with the IfcOpenShell API.
And of course we can still support Sverchok/FreeCAD/Geometry Nodes/OpenSCAD in the future for objects that are well suited to it (e.g. complex or strange meshes that have no benefit from circles / arcs, any other arbitrary shape like product catalogues where there is no benefit to having it stored in simple coded CSG operations)
Let me brainstorm a bit about how it might be designed and put together a prototype. Even if it turns out to be completely inappropriate for this usecase, I can imagine other types of editing/code based geometry generation that would find these util functions to be helpful.
Here's a mockup of what an IFC-centric shape builder class might look like. There are a number of things that are quite IFC specific that makes other generators perhaps less suitable. Things already mentioned like arcs or circles, but there are also the concept of how each extrusion has its own extrusion vector and local position. These signatures are inspired by OpenSCAD, but tailored to an IFC geometry paradigm.
# Class mockup
ShapeBuilder()
__init__:
self.items = []
polyline(points) -> returns IfcIndexedPolyCurve
rectangle(x, y, size) -> returns IfcIndexedPolyCurve
circle(x, y, r) -> returns IfcCircle
profile(outer, inner=None, name=None, type="AREA") -> returns IfcArbitraryClosedProfileDef or IfcArbitraryProfileDefWithVoids
translate(curve_or_item, create_copy=False) -> returns None
rotate(curve_or_item, create_copy=False) -> returns None
mirror(curve_or_item, create_copy=False) -> returns None
extrude(profile, position, vector, magnitude) -> IfcExtrudedAreaSolid, will append to self.items
get_items()
get_representation(context)
# How IFC shapes are built (only basic extrusions will be supported as a first version)
IfcShapeRepresentation
-> Items (IfcExtrudedAreaSolid)
-> SweptArea (IfcArbitraryClosedProfileDef or IfcArbitraryProfileDefWithVoids)
-> IfcIndexedPolyCurve (subtype of IfcCurve)
-> IfcCircle (subtype of IfcCurve)
-> Position (IfcAxis2Placement3D)
-> ExtrudedDirection (IfcDirection - should default to +Z where possible, +Z is the local Z axis of the "Position" matrix, i.e. 0,0,1)
-> Depth
These functions could be used elsewhere too, like in IfcSverchok, other parametric IFC things like railing generators, door and window generators, fabrication MEP generation, etc. It also opens up a whole new opportunity of coding with IFC ... in the past, if you wanted to create geometry with IFC you really needed a graphical environment, this offers a whole new code-based geometry creator.
That said, I think it's also super important to support geometry nodes and Sverchok because they can run circles around code in many situations. I'm inspired by the ease at which @JanF and @Gorgious can create these things. So... why not support everything? All we really need is a standard way to run(inputs), and get_output(). For geometry nodes, it looks as though there is a clear input and outputs, and if the node inputs matched the BOLTS variables, then all that is needed is a little wrapper to run it. For Sverchok, I'm less certain. I noticed you can set the name of "Number" sliders, perhaps a convention can be that number sliders with a name matching the BOLTS input are used as inputs? For the output, I'm really not sure, I think we'd need verts, edges, and faces (v+e for 2D, v+f for 3D) ... but @JanF do you know how to nominate an "output" node? Or do we need to create our own special output node?
Here's some pseudocode, what do you guys think? If we standardise the class interface, then in theory this approach can then be easily reused for people not interested in IFC (e.g. if FreeCAD wanted pure OCC Breps), or cast down to triangulated meshes via IfcOpenShell and used generally across any platform.
def create_ifc_type(bolts_class, object_name, bolts_parameters):
engines = [ifc_code_engine, sverchok_engine, geometry_nodes_engine, openscad_engine, freecad_engine]
for engine in engines:
creator = engine.get_shape_creator(bolts_class, object_name)
if creator:
break
creator.run(self.file, bolts_class, object_name, bolts_parameters) # no return value, directly creates IFC data
class SverchokEngine:
@classmethod
def get_creator(cls, bolts_class, object_name):
if object_name in bpy.data.node_trees:
self.node_tree = bpy.data.node_trees[object_name]
return cls
if isfile('path/to/{object_name}.json'):
load_file(object_name.json)
self.node_tree = create_node_tree()
return cls
def run(...):
self.node_tree.run() (?)
geometry = get_v_e_f()
convert_to_ifc(geometry)
ifc.create_entity(ifc_class, ...)
class GeometryNodesEngine:
...
@Moult said:
Here's a mockup of what an IFC-centric shape builder class might look like. ...
Great, looks about how I pictured it. Is there a reason you want to define also the transformations? I thougt we would only define the geometry objects the way we need them and use existing libraries like sympy or shapely?
... I noticed you can set the name of "Number" sliders, perhaps a convention can be that number sliders with a name matching the BOLTS input are used as inputs? For the output, I'm really not sure, I think we'd need verts, edges, and faces (v+e for 2D, v+f for 3D) ... but @JanF do you know how to nominate an "output" node? Or do we need to create our own special output node?
Not sure I understand the question, I suppose the node would output the ifcelement?
Here's some pseudocode, what do you guys think? If we standardise the class interface, then in theory this approach can then be easily reused for people not interested in IFC (e.g. if FreeCAD wanted pure OCC Breps), or cast down to triangulated meshes via IfcOpenShell and used generally across any platform.
Looks fine to me, but as I said, I'm not sure it's possible to run Sverchok scripts like this.
@JanF defining the transformations is only if someone wants to use pure IFC code, where they can benefit from the fact that each extrusion can have its own placement. If they use another engine, then naturally their forfeit that ability.
Sverchok generates a list of verts, edges, and faces, but how do you know at which point of the graph those are the outputs? It would be better not to have to create an actual Blender object/mesh to use it. Can you label one node as "Output" and then in Python find that node and get its V/E/F output?
I'm a bit confused, I thought you created the Sverchok IfcNodes? Are you asking if I'm able to do that too? This is a sample node created using the "scripted node", it's really quite trivial:
Can I turn the code into output nodes? Yes. Can we export the Sverchok tree into code and use it in a python script? I don't know, that's what I said earlier.
But I would focus on creating a pure code solution, for me it's fine, I've created most of my objects in gdl. I just think for many architects code is a no go, so I'd like to support Sverchok in the future.
There is also now basic Sverchok support for any IFC object which will help with Sverchok integration. This is a generic integration not specific to generating content libraries, where you can have any IFC element be represented by a Sverchok graph. It needs a bit more work to be tailored towards content libraries - hopefully this way we can support many methods of content creation: programmatic, node based, etc.
There is also now basic Sverchok support for any IFC object which will help with Sverchok integration. This is a generic integration not specific to generating content libraries, where you can have any IFC element be represented by a Sverchok graph. It needs a bit more work to be tailored towards content libraries - hopefully this way we can support many methods of content creation: programmatic, node based, etc.
Hi,
I'm an architect from Sweden, now digging in and having spare time over to get a hold of BlenderBim.
If I like to create some of my own IFC types, like the ones you added that are Neufert, but with Swedish standards and according to SWE regulations, and also with typical 2d representation lines etc. Is there a good guide on how to do this? A library of items?
For example, when we add furniture in Sweden, we use a certain area around beds, tables etc that shows the accessibility for people in wheelchair, this would also be great to be able to hide / unhide etc, so I really feel the urge to get a hold of the process - if it's not to complicated?
@CGR Any IFC that has IfcTypes in it can work as a library. Have you seen this already?
For example, when we add furniture in Sweden, we use a certain area around beds, tables etc that shows the accessibility for people in wheelchair, this would also be great to be able to hide / unhide etc, so I really feel the urge to get a hold of the process - if it's not to complicated?
I think that to create the possibility to hide and unhide things, for now, is a little more complicated. Parametric geometry is created through code or IfcSverchock.
@CGR in addition to manually building them yourself, would you be interested in helping add to a free database of these dimensions and locations so that anybody can generate these shapes (i.e. with their own bed style, but still with correct dimensions)? This is a little more complex since it involved figuring out a way to store the data and we can help write the code that reads / generates it, but it would bit a great little step towards standardised libraries around the world.
@bruno_perdigao said: @CGR Any IFC that has IfcTypes in it can work as a library. Have you seen this already?
For example, when we add furniture in Sweden, we use a certain area around beds, tables etc that shows the accessibility for people in wheelchair, this would also be great to be able to hide / unhide etc, so I really feel the urge to get a hold of the process - if it's not to complicated?
I think that to create the possibility to hide and unhide things, for now, is a little more complicated. Parametric geometry is created through code or IfcSverchock.
Perfect, had looked through his videos but misses that one ?
@Moult said: @CGR in addition to manually building them yourself, would you be interested in helping add to a free database of these dimensions and locations so that anybody can generate these shapes (i.e. with their own bed style, but still with correct dimensions)? This is a little more complex since it involved figuring out a way to store the data and we can help write the code that reads / generates it, but it would bit a great little step towards standardised libraries around the world.
Yea , that would be great, I guess I need to find out how you did with the neufert models in the excel file and see if I could come up with a categorisation that could be generated automatically. But I will probably need to ask some questions here a long the way so it becomes correct :)
TBC
we use a certain area around beds, tables etc that shows the accessibility for people in wheelchair, this would also be great to be able to hide / unhide etc, so I really feel the urge to get a hold of the process - if it's not to complicated?
Also, too, not as versatile, but you could assign the clearances to a 'Clearance' context...
I don't think, however, there is a mechanism for turning off a certain context now, but i'm sure there could be.
So I've finally found some time and did a bit of work on this. https://github.com/JanFilipec/IFC-library-generator
here you can find my version of the IFC library generator script, which takes a csv file as an input (so you can just define the standard dimensions you want to have in a spreadsheet) and spits out a library of IfcTypes.
The parametric objects are also loaded from a separate python library, to make management of the parametric libraries easier.
Comments
@Gorgious
Nice work! Putin would like that table.
Here's the Sverchok take on the table:
The stretching part stays the same, (twice for two axes of the table, once for the chairs), there are only five new nodes for the array.
That looks awesome, it's a good mix of regular meshes plus purely procedural.
However for the chairs how do you propose to preserve the arcs? I also notice that the edges are all separate, is there a way to keep that all as one connected polyline (otherwise we'd generate a lot of edges, or have to reverse engineer the polylines afterwards)
Well in this case sverchok doesn't really care if it's a mesh or a curve, so if we output directly to ifc it only depends on the input.
I'm more worried about the previous question, @nikitron - does sverchok know it's finished calculating? Can we just load a sverchok script, update once, export the output and move to the next sverchok script?
But how would it output directly to IFC? Blender doesn't have the concept of a circle or a 3 point arc, so we can't use that to replace the mesh input that you have, Blender also doesn't support polygons with inner voids, so we'd have to tessellate them, so I'm not quite sure how Sverchok can help here ... unless you're suggesting a bunch of IFC nodes in Sverchok?
I thought the ifc nodes were ready, what's the status after the gsoc? @mdjska
Blender has curves, we can use those as input.
FreeCad supports configuration tables https://forum.freecadweb.org/viewtopic.php?t=42183
So its quite a good tool for this... I Imagine we could have a parametric object controlled by a table that could change more representation objects at once and bake them to IFC...
I Guess It could be quite similar to Revit workflow when editing a family...
@JanF yeah unfortunately the IfcSverchok nodes aren't capable of that (yet), and it's still quite a bit of time until that happens (although if we did the Python-based OpenSCAD inspired IFC functions I suggested earlier, those could later then be turned into nodes).
Blender curves don't quite meet the requirements of IFC profiles, IFC profiles are straight segments plus 3 point arcs, or circles. Blender curves are not true circles, don't know they are circles, and aren't 3-point arcs. That's why they were never used for the profile editing tool in the BlenderBIM Add-on, because they aren't appropriate.
@carlopav indeed FreeCAD might be a good solution, how does FreeCAD work right now with supporting exporting individual IFC extrusions with inner boundaries and indexed polycurves with line segments and arc segments? To me those are the critical parametric features I'd like to retain (I assume mesh support is no problem).
What about geometry nodes curves ?
Hmmm i dont know, but i will check. Would be nice to be able to model in PartDesign workbench and have the most basic features directly mapped to IFC.
The problem is not that blender can't draw a curve in the form of a circle, it can, it just doesn't know it's a circle. So to map it to ifc curves (straight+arcs) you'd have to use some analysis. (But for example rhino or vectorworks can do that, I'm just not sure how reliable the algorithms are)
Oh right, the information is lost once the mesh is generated, gotcha. :)
I'd take this over FreeCAD then, how complicated is it to create the "DSL" (if I understand it correctly it's just a python library for geometry creation right)?
Yeah the more I think about it even if we do use FreeCAD there would still be reverse engineering, which is totally fine for other bolts backends (and maybe even ideal for FreeCAD as a BOLTS backend) but it seems the only way to fully guarantee high quality IFC is to ... well, write code specific to IFC.
I think it's actually pretty easy to write. Simple things like rectangle, circle, and indexed polycurve (with maybe 2-point arc and 3-point arc helpers) is all that is necessary for 2D, followed by an extrusion function and maybe a few shortcuts for cubes and cylinders (which is just the rectangle / circle + extrusion). Booleans are already handled by IFC so just a stack is all that needs to be done.
Once this is written, then we can actually convert it to nodes, or use it as the basis for more detailed solid modeling features in Blender / FreeCAD (kind of like the new profile editing tool), or even leave it as a script so that people can use pure code to generate complex IFC geometry with the IfcOpenShell API.
And of course we can still support Sverchok/FreeCAD/Geometry Nodes/OpenSCAD in the future for objects that are well suited to it (e.g. complex or strange meshes that have no benefit from circles / arcs, any other arbitrary shape like product catalogues where there is no benefit to having it stored in simple coded CSG operations)
Let me brainstorm a bit about how it might be designed and put together a prototype. Even if it turns out to be completely inappropriate for this usecase, I can imagine other types of editing/code based geometry generation that would find these util functions to be helpful.
Here's a mockup of what an IFC-centric shape builder class might look like. There are a number of things that are quite IFC specific that makes other generators perhaps less suitable. Things already mentioned like arcs or circles, but there are also the concept of how each extrusion has its own extrusion vector and local position. These signatures are inspired by OpenSCAD, but tailored to an IFC geometry paradigm.
These functions could be used elsewhere too, like in IfcSverchok, other parametric IFC things like railing generators, door and window generators, fabrication MEP generation, etc. It also opens up a whole new opportunity of coding with IFC ... in the past, if you wanted to create geometry with IFC you really needed a graphical environment, this offers a whole new code-based geometry creator.
That said, I think it's also super important to support geometry nodes and Sverchok because they can run circles around code in many situations. I'm inspired by the ease at which @JanF and @Gorgious can create these things. So... why not support everything? All we really need is a standard way to run(inputs), and get_output(). For geometry nodes, it looks as though there is a clear input and outputs, and if the node inputs matched the BOLTS variables, then all that is needed is a little wrapper to run it. For Sverchok, I'm less certain. I noticed you can set the name of "Number" sliders, perhaps a convention can be that number sliders with a name matching the BOLTS input are used as inputs? For the output, I'm really not sure, I think we'd need verts, edges, and faces (v+e for 2D, v+f for 3D) ... but @JanF do you know how to nominate an "output" node? Or do we need to create our own special output node?
Here's some pseudocode, what do you guys think? If we standardise the class interface, then in theory this approach can then be easily reused for people not interested in IFC (e.g. if FreeCAD wanted pure OCC Breps), or cast down to triangulated meshes via IfcOpenShell and used generally across any platform.
Great, looks about how I pictured it. Is there a reason you want to define also the transformations? I thougt we would only define the geometry objects the way we need them and use existing libraries like sympy or shapely?
Not sure I understand the question, I suppose the node would output the ifcelement?
Looks fine to me, but as I said, I'm not sure it's possible to run Sverchok scripts like this.
@JanF defining the transformations is only if someone wants to use pure IFC code, where they can benefit from the fact that each extrusion can have its own placement. If they use another engine, then naturally their forfeit that ability.
Sverchok generates a list of verts, edges, and faces, but how do you know at which point of the graph those are the outputs? It would be better not to have to create an actual Blender object/mesh to use it. Can you label one node as "Output" and then in Python find that node and get its V/E/F output?
I'm a bit confused, I thought you created the Sverchok IfcNodes? Are you asking if I'm able to do that too? This is a sample node created using the "scripted node", it's really quite trivial:
Can I turn the code into output nodes? Yes. Can we export the Sverchok tree into code and use it in a python script? I don't know, that's what I said earlier.
But I would focus on creating a pure code solution, for me it's fine, I've created most of my objects in gdl. I just think for many architects code is a no go, so I'd like to support Sverchok in the future.
So according to the discussion
https://github.com/nortikin/sverchok/discussions/4792#discussioncomment-4310697
we can run sverchok scripts headlessly. The ifcnodes work as well, so now I just need a few free evenings and we'll have a prototype.
So the first test is working!
I sucessfully imported the database, filtered it and generated a ifc library containing object types with 3D and 2D representations. (theres only one type of object in the library right now, so they all end up a box/plane)
https://github.com/JanFilipec/Sverchok-Tutorials/tree/main/Sverchok ifcProjectLibrary
A few updates on this which will be in today's release. Thanks to the awesome work by Andrej730 there is now an IFC4 AU Library based on the spreadsheet of numbers: https://github.com/IfcOpenShell/IfcOpenShell/tree/v0.7.0/src/blenderbim/blenderbim/bim/data/libraries
These were programmatically generated with a new ShapeBuilder class that is similar to how OpenSCAD works except that it's tailored to IFC: https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/ifcopenshell-python/ifcopenshell/util/representation.py#L77 - so any new objects can be relatively easily added in the future. Here's the generation script: https://github.com/IfcOpenShell/IfcOpenShell/blob/v0.7.0/src/blenderbim/scripts/generate_furniture_library.py - can obviously be cleaned up a bit and modularised to allow people to easily extend with their own programmatically generated shapes, but it's a start.
There is also now basic Sverchok support for any IFC object which will help with Sverchok integration. This is a generic integration not specific to generating content libraries, where you can have any IFC element be represented by a Sverchok graph. It needs a bit more work to be tailored towards content libraries - hopefully this way we can support many methods of content creation: programmatic, node based, etc.
This is so sooo awesome!
Hi,
I'm an architect from Sweden, now digging in and having spare time over to get a hold of BlenderBim.
If I like to create some of my own IFC types, like the ones you added that are Neufert, but with Swedish standards and according to SWE regulations, and also with typical 2d representation lines etc. Is there a good guide on how to do this? A library of items?
For example, when we add furniture in Sweden, we use a certain area around beds, tables etc that shows the accessibility for people in wheelchair, this would also be great to be able to hide / unhide etc, so I really feel the urge to get a hold of the process - if it's not to complicated?
//C
@CGR Any IFC that has IfcTypes in it can work as a library. Have you seen this already?
I think that to create the possibility to hide and unhide things, for now, is a little more complicated. Parametric geometry is created through code or IfcSverchock.
@CGR in addition to manually building them yourself, would you be interested in helping add to a free database of these dimensions and locations so that anybody can generate these shapes (i.e. with their own bed style, but still with correct dimensions)? This is a little more complex since it involved figuring out a way to store the data and we can help write the code that reads / generates it, but it would bit a great little step towards standardised libraries around the world.
Perfect, had looked through his videos but misses that one ?
Yea , that would be great, I guess I need to find out how you did with the neufert models in the excel file and see if I could come up with a categorisation that could be generated automatically. But I will probably need to ask some questions here a long the way so it becomes correct :)
TBC
Would love if there was some mechanism where we could turn on/off things in our types.
Maybe 'type aggregates' could be an approach: https://github.com/IfcOpenShell/IfcOpenShell/pull/3328
Also, too, not as versatile, but you could assign the clearances to a 'Clearance' context...
I don't think, however, there is a mechanism for turning off a certain context now, but i'm sure there could be.
So I've finally found some time and did a bit of work on this.
https://github.com/JanFilipec/IFC-library-generator
here you can find my version of the IFC library generator script, which takes a csv file as an input (so you can just define the standard dimensions you want to have in a spreadsheet) and spits out a library of IfcTypes.
The parametric objects are also loaded from a separate python library, to make management of the parametric libraries easier.