[HN Gopher] GraphSCAD - A User Friendly Nodal Editor for OpenSCA...
       ___________________________________________________________________
        
       GraphSCAD - A User Friendly Nodal Editor for OpenSCAD (2018)
        
       Author : app4soft
       Score  : 115 points
       Date   : 2021-10-10 09:42 UTC (13 hours ago)
        
 (HTM) web link (graphscad.blogspot.com)
 (TXT) w3m dump (graphscad.blogspot.com)
        
       | willvarfar wrote:
       | This is a bit of a tangent but I wish I could find a tool for
       | designing houses that was graphical but underneath based on a
       | programming language.
       | 
       | There are several cad and floor planner software that are for
       | designing houses, and modelling software like sketch up that are
       | more general. All seem to be awkward or incomplete.
       | 
       | Sketch up is perhaps the fastest for visualizing the shell, but
       | is painful to sketch something with exact measurements. You end
       | up sketching on paper and then trying to enter it into the
       | computer.
       | 
       | Sweet home 3D is clunky. Homestyler is actually really good, but
       | doesn't do roofs and lifts.
       | 
       | You can actually do great getting-a-feel sketches in The Sims
       | (honest!) but the grid is all wrong.
       | 
       | And all of them treat walls and things as solid volumes. There's
       | no snap-to-grid on standard studwork spacings or picking walls
       | based on cavity.
       | 
       | So much could be done in code eg sorting out wiring, plumbing
       | etc.
       | 
       | Building models like openscad does hints at a direction where you
       | lay out the general building and code can auto fit to actually
       | make it buildable and produce working construction drawings etc.
       | Even start computing structural aspects etc.
       | 
       | If anyone knows the killer software for designing houses easily
       | but properly, please let me know! I may have missed something. ;)
        
         | ToJans wrote:
         | Warning: self promotion ahead, but you've asked for it.
         | 
         | I built a company around this [0], but it's not open source,
         | and I haven't exposed the dev platform to the public yet, and
         | might only expose it to licensed partners.
         | 
         | It is a platform to create online 3d configurators for
         | consumers and sales, driven by scripted templates that generate
         | 3d components according to some configuration... Currently I'm
         | leveraging webpack hot reloading, but an online IDE is on the
         | roadmap for next year.
         | 
         | There are a lot of caveats in designing such a system,
         | especially if you want to keep the performance top notch on
         | mobile, and you want to have a modern dev experience.
         | 
         | The biggest value however is in the 3d components itself:
         | simple components that compose well and allow you to build
         | basically anything in a few days if you know what you need...
         | 
         | If I'd need to build it from scratch now (almost a decade
         | later), I could probably build a cleaner, better performing
         | platform in a couple of months in deep crunch mode.
         | 
         | However, if you have never done this before, it might take
         | quite a few mistakes and a lot of refactoring before you get it
         | right. (During the first 2 years I rebuilt the core 5 times
         | because I had yet another use case that didn't fit in the
         | models customers were asking for.)
         | 
         | If you are serious and have lots of houses to design, I might
         | be able to help.
         | 
         | TBH the current website and the configurators on it are old and
         | need some love, but if you want to see a good example of a
         | client leveraging this tool, check this link [1], and click on
         | 3d design.
         | 
         | Upfront: it's not cheap.
         | 
         | [0] https://virtualsaleslab.com
         | 
         | [1] https://brustor.com/en
        
         | leeuw01 wrote:
         | It would also be great if you had some kind of declarative
         | specification language which could generate (parts of)
         | buildings.
        
         | Iv wrote:
         | FreeCad is a generic parametric CAD software. It is not
         | designed for houses, but it allows to create constraints-based
         | designs and is scriptable through python.
         | 
         | So not a 100% match but it checks several of your items. If you
         | are considering something as remote as openSCAD, I think you
         | should give a try to FreeCAD and look at a few tutorials (its
         | workflow is not the most intuitive thing)
        
           | drran wrote:
           | See Arch[0] module for FreeCAD.
           | 
           | [0]: https://wiki.freecadweb.org/Arch_Workbench
        
           | ur-whale wrote:
           | > it allows to create constraints-based designs
           | 
           | I've never seen an architect using a constraints-type CAD
           | design workflow.
           | 
           | I always thought constraint-based design is typical
           | mechanical engineering thinking.
           | 
           | Do architects work with constraints as well?
        
             | app4soft wrote:
             | > I've never seen an architect using a constraints-type CAD
             | design workflow.
             | 
             | Take a look on _PARAM-O_ [0], the visual scripting solution
             | for Archicad powered by _VisualScriptEngine_.[1]
             | 
             | Also, here _is VisualScriptCAD_ [2], based on
             | _VisualScriptEngine_.
             | 
             | [0] https://graphisoft.com/param-o
             | 
             | [1] https://github.com/kovacsv/VisualScriptEngine
             | 
             | [2] https://github.com/kovacsv/VisualScriptCAD
        
         | ramboldio wrote:
         | TrussFab takes care of the structural aspect:
         | https://hpi.de/baudisch/projects/trussfab.html
        
         | DrPhish wrote:
         | It's not FOSS, and not parametric in the way you're thinking,
         | but versions of it work in wine: Chief architect. I use an OLD
         | version I have of it, for visualizing renos mostly, but it has
         | all the smarts to properly get you to something buildable to
         | code with all the BOMs. You set your defaults for materials and
         | measurements, which can be changed after the fact to give it a
         | bit of a "parametric light" feel. I wish there was something as
         | powerful and fully featured in the FOSS space.
        
         | fsloth wrote:
         | Industry has such workflows but they currently revolve around
         | heavy products like Tekla Structures, Grasshopper/Rhino, Revit,
         | Archicad and so on.
         | 
         | I'm not aware of "light" version for "non-professional"
         | residential projects.
         | 
         | The thing about buildability is that when you want an
         | _actually_ buildable model you want vendor components(windows,
         | curtain walls and whatnot), manufacturable details and so on
         | and those come out of the box AFAIK only in a product like
         | Tekla Structures.
         | 
         | Industry is reaching a stage where the house that is to be
         | built on-site can be _actually_ modeled in 3D - the current WOW
         | is mostly that the 3D model is used to output 2d drawings and
         | then manual building ensues as it has for centuries /decades
         | with details that are not exactly right, lots of manual
         | fittings and ad-hoc installations if HVAC and so on.
         | 
         | BIM 3D models are only now becoming detailed enough with enough
         | cross domain support to _actually_ model the whole thing.
        
         | contingencies wrote:
         | Multi-domain, complex or wicked problems often have these
         | challenges: in mechanical design, electronic design, software
         | development, as well as traditional architecture. Parametric
         | approaches typically break down when articulating the
         | constraints becomes more tedious than simply solving them out
         | of band if the number of times the problem will repeat is
         | tolerable. Likewise, parametric approaches can excel when
         | articulation is easy or where fitness functions are
         | straightforward to define and generative solutions are
         | feasible. Tool complexity creates training/hiring issues, and
         | being tied to a tool challenges solution longevity. _Use the
         | right tool for the job._
         | 
         | As far as houses go, check out
         | https://blenderbim.org/community.html - very capable
         | developers.
        
         | mrfusion wrote:
         | You could make openscad modules for the various parts of your
         | house sketch and use those. I'm not sure if that would work
         | well or not.
        
           | ur-whale wrote:
           | OpenSCAD style thinking is CSG (constructive solid geometry).
           | 
           | It basically thinks of geometry in terms of volumes.
           | 
           | Architects think mostly in term of surfaces.
           | 
           | If you give them volumes, they're unlikely to know what to do
           | with your design other than re-creating the model from
           | scratch in their favorite tool from dimensionned 2D
           | projections of the computed model.
        
       | leoedin wrote:
       | Has anyone used this? How does using nodes compare to using text
       | syntax?
       | 
       | One of the big problems I've found with openSCAD is that beyond a
       | certain level of complexity it gets very hard to keep a good
       | mental model of the constituent parts of your 3D model in your
       | head, and so changes become hard. This is generally after things
       | get rotated a few times. Does this make that easier?
        
         | jacquesm wrote:
         | I've used it to create some parametric stuff (an alternative
         | layout piano keyboard), it's super powerful.
         | 
         | Here is an example:                   module slice(r = 10, deg
         | = 30) {                  degn = (deg % 360 > 0) ? deg % 360 :
         | deg % 360 + 360;                  difference() {
         | circle(r, $fn=100);                      if (degn > 180)
         | intersection_for(a = [0, 180 - degn]) rotate(a) translate([-r,
         | 0, 0]) square(r * 2);                      else union() for(a =
         | [0, 180 - degn]) rotate(a) translate([-r, 0, 0]) square(r * 2);
         | }              }              module 3d_slice(height, r, deg) {
         | linear_extrude(height = height) slice(r, deg);         }
         | module key(c, n, l, padlength, a) {                   padangle
         | = 6;                      // support
         | color("brown") render() rotate([90,0,0]) translate ([0,0,13 *
         | n]) difference() {   3d_slice(12, l, a);
         | 3d_slice(12,l-(padlength-3),a+0.1); };                  //
         | keypad                        color(c) render()
         | rotate([90,0,0]) translate ([0,0,-6 + 13 * n]) difference() {
         | 3d_slice(24, l, a+padangle);
         | 3d_slice(24,l-(padlength-3),a+padangle+0.1); 3d_slice(24, l,
         | a);};                   }              module note(n) {
         | colors = ["red", "black", "white", "black", "white",
         | "white", "black", "white", "black", "white", "black", "white"];
         | tone   = n % 12;                        // angles just below
         | the keypad                          aa = 3.5;               ab
         | = 6; // this one is important, too small and you won't be able
         | to press the key all the way down               ac = 8.25;
         | ad = 10;                        hingeoffset = 6;
         | keypad = 30;               length = 225;               width =
         | 12;               height = 12;               space = 1;
         | xlat = (width + space) * n;                    if ((n % 2) ==
         | 1) {                    l = length - keypad + hingeoffset;
         | color("brown") render() rotate([90,0,0]) translate
         | ([-6,-hingeoffset,xlat]) cube([l,width,height]);
         | key(colors[tone], n, length-3*keypad, keypad, ad);
         | key(colors[tone], n, length-keypad, keypad, ab);
         | }           else {                          // long keys
         | l = length + hingeoffset;                    // base
         | color("brown") render() rotate([90,0,0]) translate
         | ([-6,-hingeoffset,xlat]) cube([l,width,height]);
         | // inner key                          key(colors[tone], n,
         | length-2*keypad, keypad, ac);                          // outer
         | key                          key(colors[tone], n, length,
         | keypad, aa);                 }                }
         | for (i=[0:60]) {             note(i);             }
        
         | eurasiantiger wrote:
         | Use less nesting and more modules.
        
         | contingencies wrote:
         | I've noticed the same. Partly, the need to maintain a complete
         | mental model is obviated by the fast-iterating IDE (ie. a try-
         | it-and-see approach) and comments. Haven't tried this frontend
         | yet but it seems a good match to the structure of abstraction.
        
         | agumonkey wrote:
         | a lot of software use node based UI
         | 
         | most movie grade CGI (houdini, maya) or compositors were made
         | this way
         | 
         | since most tasks don't require an abnormally large network it's
         | ok (when it's not they try to implement submodules of some
         | kind, it's pretty ad-hoc but it's not supposed to be the
         | average use case)
         | 
         | one value of these is that it's obviously (and visually) lazy
         | reactive. You can do the same with text but it's harder to see
         | input/outputs on text IMO.
        
           | ur-whale wrote:
           | > a lot of software use node based UI
           | 
           | Yes, and as pointed out in another comment, it does not scale
           | well.
           | 
           | It's nice for the "tweak" phase of - say - finalizing a shot
           | in a CGI movie, but when you start to get more than a few
           | thousand nodes in a setup, it's very hard to do anything.
           | 
           | There are mitigation solutions, such as grouping and
           | collapsing of nodes, but that only goes so far.
           | 
           | Another annoying thing with node-based systems:
           | - collaborative work is hard          - version control is
           | hard
        
             | agumonkey wrote:
             | People made full blown characters rigging and scenes with a
             | blend of node and direct interaction. It's not just for
             | trivial tasks only.
        
           | app4soft wrote:
           | > _most movie grade CGI (houdini, maya) or compositors were
           | made this way_
           | 
           | Yeah. Upcoming _Olive Video Editor_ `0.2.x` would be fully on
           | nodes.[0,1]
           | 
           | [0] https://olivevideoeditor.org/020.php
           | 
           | [1] https://github.com/olive-editor/olive
        
             | agumonkey wrote:
             | heh, the late 90s are back
        
         | bsdubernerd wrote:
         | openSCAD has a few operators to highlight/isolate the current
         | syntax block. Have you ever used those?
         | 
         | Working on a project using openscad is not that different than
         | using other cad programs: you should split your model into
         | "modules"/functions and use composition effectively.
         | 
         | I generally find nodal interfaces quite inefficient in general
         | and scale very poorly in every context I've seen them.
         | 
         | The biggest problem with openSCAD for me is that there's no way
         | to "measure" in the preview window. As in: just pick two faces
         | and give me the parallel distance and/or vertex-to-vertex
         | distance. I don't care about precision of the preview, let me
         | double-check!
         | 
         | You have no idea how often this comes up when connecting
         | multiple parts. Computing the distance manually, while
         | possible, is such a nuisance. Every respectable CAD program
         | gives you a distance when clicking on things for this reason.
         | Somehow FreeCAD made this quite unnecessarily clunky that I
         | have to rely on addons and openscad is missing it completely :(
        
           | ur-whale wrote:
           | > The biggest problem with openSCAD for me is that there's no
           | way to "measure" in the preview window
           | 
           | I agree, except for the fact that I would go one step
           | further.
           | 
           | OpenSCAD would be amazing if it would let you "interrogate" a
           | piece of geometry returned by a module, something along the
           | lines of:                    - get the AABB of the model
           | - cast a ray onto the  odel and get a sorted list of
           | intersections          - intersect two pieces of geometry and
           | get a polyline out of it
           | 
           | and use the result of these "introspections" as parameters
           | for subsequent manipulation/modification of the object.
           | 
           | If OpenSCAD could do this, it'd be simply amazing.
           | 
           | But I suspect it's hard to do in the current way it's
           | implemented: what I am describing kind of breaks the current
           | OpenSCAD paradigm because it would force injection of data
           | coming from the "geometry stream" into the control parameters
           | of downstream processing nodes.
           | 
           | I don't think the engine is designed to handle this well.
        
             | phkahler wrote:
             | You might try exporting objects as STL and then link them
             | in Solvespace. Edge builds do support binary STL files and
             | it will identify edge vertices for building additional
             | geometry.
        
               | ur-whale wrote:
               | Yeah, but then you're not in OpenSCAD anymore, and any
               | subsequent building step has to happen in solvespace,
               | which while it is a nice package, does not have the
               | flexibility of openscad.
        
           | PostThisTooFast wrote:
           | Nodal UIs work very well for image compositing.
        
         | ur-whale wrote:
         | > it gets very hard to keep a good mental model of the
         | constituent parts of your 3D model in your head
         | 
         | I had that exact problem initially.
         | 
         | Then I realized that the problem was exactly identical to
         | designing large-scale code: however big your brain, you won't
         | be able to keep all the details in your head after some point
         | and therefore you need to design things hierarchically or in
         | some sort of modular fashion, just like when you write code.
         | 
         | And this is where OpenSCAD really shines: if you apply the same
         | kind of engineering discipline to your 3D models that you would
         | to a large-scale and complex piece of code, you can make things
         | that are _way_ more complex than you would with a WYSIWYG type
         | environment _and_ have them fully parametric to boot.
         | 
         | The one thing that I find lacking is self-introspection
         | capabilities, i.e if I am in a caller piece of OpenSCAD code,
         | calling to an OpenSCAD module that returns a piece of geometry,
         | I would love to be able to "probe" the returned geometry from
         | the caller in order to use it in the bigger piece I'm building.
         | 
         | As a simple example of what I mean: it'd be great to have the
         | AABB of the model returned by a module, or be able throw an
         | arbitrary ray at it and get the first intersection so as to
         | properly design the piece next to it.
        
       | nine_k wrote:
       | Honest question: are such nodal editors easier for you than the
       | indented text?
       | 
       | If so, how do you navigate the charts? How do you organize stuff
       | in nice planar graphs? How do you manage to see enough with such
       | a low information density, compared to text? What are the key
       | advantages you see?
       | 
       | (Disclaimer: yes, I did use OpenSCAD to describe moderately
       | complex geometry.)
        
         | adamnemecek wrote:
         | It makes it somewhat clearer what flows where.
        
       | ur-whale wrote:
       | This type of tool will only reach its full potential when it can
       | really go both ways, i.e going back and forth from nodal
       | representation to actual code seamlessly.
       | 
       | And by seamlessly, I mean not losing your loops and recursive
       | calls after doing minor editing to the nodal representation.
       | 
       | This is - of course - not easy (and no surprise, this tools does
       | not pull it off), but it's a goal worth pursuing.
        
         | hobofan wrote:
         | Yes, it seems like there are very few efforts that work towards
         | seamless visual<->text code editing.
         | 
         | Even for things like React apps where you have pretty clear
         | composable building blocks in the form of components, I only
         | know of Utopia[0] as an ongoing project.
         | 
         | I've worked towards having a React-based interface for
         | OpenJSCAD with Landau[1], where one of the goals was having an
         | editor like Utopia to make most of the editing capabilites
         | available in a standard 3D editor interface that edits the
         | variables in the code.
         | 
         | [0]: https://utopia.app/
         | 
         | [1]: https://github.com/landaujs/landau
        
           | willvarfar wrote:
           | Wow! Just ... wow! Super cool! But how far has this gotten?
        
             | hobofan wrote:
             | Landau has gotten "good enough" to replace
             | OpenSCAD/OpenJSCAD for my personal 3d printing use-cases,
             | where the main benefit I was looking for as a first step is
             | better reusability via npm packages and a familiar
             | interface via React. E.g. in a non-public project of mine
             | that contains a Raspberry PI case, I can just import a 3D
             | model of the RPI[0] to visually ensure that it correctly
             | fits the case, and easily keep them in sync.
             | 
             | As I don't really have time to maintain it, development
             | usually moves forward when I find time for my 3d printing
             | hobby, so I wouldn't advise anyone to rely on it.
             | 
             | Since the space of alternative React renderers has been
             | explored more and more in the last years (e.g. Remotion[1]
             | for producing videos), I assumed that a "proper version" of
             | Landau would exist by now, but AFAIK there isn't one.
             | 
             | [0]: https://github.com/hobofan/landau-rpi
             | 
             | [1]: https://www.remotion.dev/
        
         | 95014_refugee wrote:
         | The "problem" with this is insisting on a free-text-editable
         | version of "the code", which makes everything much harder than
         | it needs to be.
         | 
         | A better approach is to go the other way, i.e. maintain the AST
         | and project it in an editable fashion, whether that be in a
         | graphical sense, textually, etc.
         | 
         | This lets you constrain the edit gestures to things that are
         | valid in the context of the AST, and avoids the problem where
         | the user has typed a bunch of gibberish and you can no longer
         | "back convert" to some other representation.
         | 
         | A really good (but sadly largely abandoned) example of this is
         | https://mbeddr.com
        
           | ur-whale wrote:
           | I don't disagree with you ... I am simply noting that this is
           | a problem area that seems generic enough to apply to a _lot_
           | of situations, but there surprisingly seems to be very little
           | research going on to solve the problem properly and in a
           | general manner.
        
       | transfire wrote:
       | Can't wait to try!
       | 
       | Is the text code and node graph node interchangeable? I.e. can i
       | edit code and see the changes in the graph?
        
         | andybak wrote:
         | Yeah but no but...
         | 
         | https://gist.github.com/andybak/f98742b37b801849e1584b7faddc...
         | 
         | This is the code generated for a single cuboid.
         | 
         | EDIT - looking a bit closer, it might not be that bad. That
         | seems to be mostly library functions. The actual user code is
         | fairly concise:                   function
         | node_cube_matrix(i=0,j=0,k=0,l=0,m=0,n=0) = translate([0,0,0]);
         | module node_cube(i=0,j=0,k=0,l=0,m=0,n=0)          {
         | cube([2,1,1],center=false);          }
         | node_cube();
        
       | kongin wrote:
       | I feel exceedingly stupid for never having thought about
       | something so simple.
        
       | app4soft wrote:
       | GitHub repo: https://github.com/graphscad/graphscad
       | 
       | Dimitri Kolovitz's profile on Thingiverse:
       | https://www.thingiverse.com/kolovitz/designs
        
         | Ennea wrote:
         | The Git repo does not seem to contain the actual application.
        
           | FeepingCreature wrote:
           | And the actual application doesn't seem to be opensource.
           | Welp.
        
             | solarkraft wrote:
             | Oh. Oof.
        
               | app4soft wrote:
               | Here is a _GraphSCAD_ thread on OpenSCAD form.[0]
               | 
               | Also here is _Node Graph Interace_ to OpenSCAD in
               | Java.[1]
               | 
               | FTR, I may recommend take a look on _VisualScriptCAD_ [2]
               | and _DynFreeCAD_ [3].
               | 
               | [0] https://forum.openscad.org/Graphscad-A-New-Nodal-
               | editor-for-...
               | 
               | [1] https://github.com/studiotc/NodeGraphInterface
               | 
               | [2] https://github.com/kovacsv/VisualScriptCAD
               | 
               | [3] https://github.com/infeeeee/DynFreeCAD
        
       | nullsmack wrote:
       | Is this actually abandoned? It doesn't look like there's been any
       | activity at all since 2018.
        
       ___________________________________________________________________
       (page generated 2021-10-10 23:01 UTC)