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

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 u

various other technologies, be it node-like on Sverchok or FreeCAD, or even another data schema like IFC. So the future relationship I would imagine is Topologic fundamentally is separate from IFC, y

Looks fine to me, but as I said, I'm not sure it's possible to run Sverchok scripts like this.

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 w

the code by disassociating Topologic from sverchok and Blender; not to abandon them! On the contrary: to make the topologic code more sustainable and versatile. Once the refactoring is done, under th

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 / arc

(Quote)

with input and output. That is not dependent on sverchok or even blender. But in any case, all code is free and open source so you can use it as you wish.

I can definitely use topologic but I do not see my users using Sverchok. I have not used topologicPy but if I can package it into a simple Blender workflow I do believe I can convince at least a few

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 polyg

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.

Here's the Sverchok take on the table:

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

As to what language we use to define the parametric library, I used Sverchok because:

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 / ci

Sverchok can do this, but it relies on Sverchok knowledge and means we need to maintain Sverchok compatibility. It also makes it slightly more tricky to automate (you'd have to rerun the graph, and I

I'm less keen on Sverchok, given that a Sverchok dependency means that breakage is a bit more likely to happen (and has happened a few times already on Ladybug Tools) compared to pure bmesh scripting.

So it turns out it's rather simple to parametrize the 2d meshes with Sverchok: (you just pick the affected vertices in the edit mode and internalize them in the note node)

As I said I'm working on a sverchok library, so it should be quite easy to feed it the values and export the objects. The only thing that's missing is the ifc node to write both 2d and 3d representati