Ahh, OpenSCAD only supports solids, so arbitrary lines for 2D representations. That's a pretty unfortunate showstopper.
CAD Sketcher (which is similar to the FreeCAD solution, as they both use the same solver) also doesn't quite give all the necessary functionality, like visibility depending on booleans, or loops / arrays. Also that's just the 2D sketch, we need the 3D geometry too.
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.
The DSL could be inspired by OpenSCAD (it is very well designed, and from what I have seen is pretty easy to recreate for the most part) but have additional support for 2D unclosed polylines and support for arcs. FreeCAD could then use the resultant geometry directly through IFC, or FreeCAD and OpenSCAD can use the geometry through OpenCASCADE's results via IfcOpenShell.
To cater for graphical authoring, the script could allow for loading from Blender objects, which have vertex groups with naming conventions that affect whether it is affected in the X/Y/Z direction, or no vertex groups at all for non-parametric behaviour.
Just to visualise what we're talking about here:
We'll create a library generator script, which takes the values from the BOLTS database and the parametric library and generates a static ifc library, right?
As to what language we use to define the parametric library, I used Sverchok because:
it's ready to go
you need basically zero sverchok knowledge to create the simplest parametric objects
you can easily add parameters to static meshes
you can create arbitrarily complex objects when you learn sverchok
But I know it's not the optimal solution, I was hoping the JSON export of the script could be reused as we discussed here https://community.osarch.org/discussion/328/geometry-nodes-in-blender#latest
@JanF indeed your diagram sums it up nicely.
The reason I'm hesitant about Sverchok for the parametric library is that we lose the ability to store arcs and extrusion - it comes out all as meshes. But Sverchok also has many strengths which makes it very appropriate for mesh based things.
I guess maybe we don't need to lock ourselves to any particular "engine". There's no reason why we can't support everything - Sverchok, script, OpenSCAD, geometry nodes, etc. We can start with one and in the future we can always make it modular and support multiple "engines".
@JanF how would you recreate the OpenSCAD example I provided of a table with N chairs spaced along it in Sverchok? Maybe it's the programmer in me speaking, but it seems that the OpenSCAD code is incredibly concise, whereas I wouldn't know how to easily do it in Sverchok without a lot of nodes... I have a lot to learn in Sverchok.
Hehe this inspired me to test it out in a GN tree.
A lot of nodes but they're all simple maths operations. Until we have a dedicated equation node I'm afraid this is how it might look :)
I'll share the blend if anyone wants to play with it. Cheers
PS ideal if you're planning on receiving all your friends at once >< 
@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.
@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).
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.
@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)
Oh right, the information is lost once the mesh is generated, gotcha. :)
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.
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.
Login or Register to reply.