Sverchok IFC Nodes create IfcWall

So did anyone try to actually build ifc files with the sverchok nodes? What am I missing? I'm simply trying to create a wall using the sverchok nodes only. I have two problems:

  • I can't get the ifc Create Entity node to build a list of IfcIndexedPolygonalFaces so that I could feed it to the IfcPolygonalFaceSet. I only get the first polygon from the list
  • The created ifc is not valid
  • Also the elements are written several times to the file


  • IfcSverchok is very, very incomplete. More reading: - Would you like to help take it forward? :)

  • Sure, but the discussion on github is not exactly motivating :D I mean I have some experience with nodes (mostly grasshopper) but I certainly would not call myself an expert.
    Given the pace of development of IfcOpenShell I think the autogenerated nodes as a foundation are the only option, if that would reliably work, we could easily build some higher level nodes on top for normal users. But I honestly have no idea where to start with something like that.

  • edited June 9

    I am currently trying to learn Blender/BlenderBIM and Sverchok. I come from Grasshopper background so would be happy join in on this initiative and help out in some way.

  • @JanF and @kaiaurelienzh great! Have either of you used GeometryGym's IFC nodes? If you get familiar with it and are able to demonstrate how to use it to me, I can replicate that behaviour in Sverchok.

  • I know of GeometryGym but have never used their nodes before, will take some further research. I think it's proprietary so would need to fork out a licence?

  • Well, ping @geometrygym - what are your thoughts on a Sverchok port?

  • Our grasshopper nodes are presently hand crafted. Most are constructors, so if an automated creation of the nodes can be developed the benefits would be significant. Certainly it's on our roadmap to automate a lot more of our grasshopper plugin for future versions. But raw constructors with every attribute visible will make it harder on users.
    There's also other considerations of a graph based generation of IFC. Are objects immutable (How do you manage model manipulation (not just creation)? Is the model created top down or bottom up? These and other aspects have been barriers relating to a development of a geometry gym port to other environments such as Dynamo.
    We do charge users for our Grasshopper developments, although I believe the biggest benefit is the technical support.
    As a small standalone business, Geometry Gym has no resources to donate to a Sverchok port at this point in time.

  • 100% agree that automated node creation is the way to go. Also agree that raw constructors will lead to poor usability.

    I think most model manipulation can "just work" if we use the IfcOpenShell API, since this is already increasingly battle tested in a native authoring environment.

    I'll find some time and add creating a prototype to the todo list. @JanF and @kaiaurelienzh do either of you code or would like to contribute codewise?

  • @Moult yes I am a coder, in Python + C#. Happy to contribute.

  • I'm a bit skeptical about the usability of nodes on complex structures in real world situations.

  • @stephen_l After spaghetti code we now have spaghetti node :)

  • Great @kaiaurelienzh let's organise a session to build an API node together, and see how far we can get. I'm in the Sydney timezone. What time/date works well for you? I'd prefer between 8am and 10pm Sydney time.

    @stephen_l I quite regularly see nodes as complex as that screenshot, and even more complex, used to deliver large commercial projects. Some authors secretly take pride in how many nodes it takes :D

  • @stephen_l i don't think it is very different from normal programming, in more complex projects you simply have to divide it into smaller blocks (but you're right, as far as I know sverchok lacks grasshopper's ability to group nodes into higher level nodes right now)

  • @JanF yes you can group sverchok nodes into a custom node and choose which parameters to expose.

  • @Moult Sounds good, I'm from Melbourne so same timezone as you. I'd prefer Saturday morning if that's okay? Say, 11am or so? But I am flexible.
    @stephen_l agree that spaghetti is far from ideal and the goal would be to use code instead of nodes to generate building systems. However, commercial and complex projects are regularly delivered in practice every day using visual programming in AEC.

Sign In or Register to comment.