My thanks to Doug Moen for pointing out Blender's node functionality which I
was not previously aware of.

To ensure that my ignorance becomes less, I would appreciate anything which
folks could share to expand/correct the following:

• Rhino has an optional node system, Grasshopper which affords full control
  of models?
• Blender --- in addition to the native node system (for materials only?)
  there is an add-on modeled on Grasshopper:
  http://nikitron.cc.ua/sverchok_en.html

For OpenSCAD and similar tools there is:

• OpenJSCAD --- version of this in the Microsoft Store, also available on
  the web
• BlockSCAD
• https://github.com/studiotc/NodeGraphInterface
• clikscad
• Antimony/Kokopelli --- I wish this ran on Windows --- I may break down
  and get a Mac at some point, or find time to set up a Linux box, but it's
  unfortunate that access to it is so limited

For 2D similar tools include:

• Processing --- programming based on JavaScript --- its use for
  CNC/CAD/CAM is described in the book Make: Design for CNC Furniture
  Projects and Fabrication Technique
• Nodebox --- elegant programmatic 2D drawing with nodes --- unfortunately,
  units in graphics (PDFs or SVGs) are rounded off, so only suited to
  decorative use, or use with single-piece projects (a sundial has been done)

CAM-specific tools include:

• Maker.JS --- a Microsoft Garage project extending node.js for making
  things
• Tool Path Language --- an opensource extension of JavaScript to create
  G-Code for directly controlling machines

Is there anything else which I've missed? I'd welcome any additions or
corrections. It's all going on:

• https://wiki.shapeoko.com/index.php/OpenSCAD
• https://wiki.shapeoko.com/index.php/CAD
• https://wiki.shapeoko.com/index.php/Programming

For my part, things I'd like to see:

• BlockSCAD available as an alternate interface in OpenSCAD:
  https://github.com/openscad/openscad/issues/3108
• BlockSCAD support for the Customizer:
  https://github.com/EinsteinsWorkshop/BlocksCAD/issues/48
• a formal technique/site for placing OpenSCAD projects online which isn't
  Thingiverse

OpenSCAD support for drawing in 2D --- I'm currently re-creating projects in
METAPOST using lualatex:
https://wiki.shapeoko.com/index.php/Design_into_3D:_box:_fitted and
https://github.com/WillAdams/Design_Into_3D/tree/master/box/fitted --- maybe
there's a better way to do this? I was successful with modeling a Chinese
Checkers board and projecting it into 2D so as to export a DXF:
https://community.carbide3d.com/t/design-into-3d-games-chinese-checkers/16056

William

--
Sent from: http://forum.openscad.org/

And it turns out I missed a node editor for FreeCAD:

https://forum.freecadweb.org/viewtopic.php?t=36299

--
Sent from: http://forum.openscad.org/

Forgive my ignorance but what is a "Node editing system" and in what context
is it relevant to OpenSCAD ?

...R

--
Sent from: http://forum.openscad.org/

It's the description of connected block diagramming/programming tools --- the
discussion of your program spurred the mention of Blender having such an
interface, and I'd like to fill in any gaps on such systems.

Is there some other terminology you feel would be better, or which you would
prefer for describing Clikscad?

William

--
Sent from: http://forum.openscad.org/

Instead of "Node editing system", I would suggest the more general term "Visual programming language".

https://en.wikipedia.org/wiki/Visual_programming_language

There is a (very incomplete) list of visual programming languages in that Wikipedia article.

For example, Sketch-n-sketch belongs in your list: it is a programming language for generating SVG models, which also lets you edit your source code by direct manipulation of the SVG model that is produced as the output. But, it isn't a node-editing system. The authors call it a "direct manipulation programming system", but I think it belongs in the category of visual programming languages.

https://ravichugh.github.io/sketch-n-sketch/

I've been working with OpenSCAD for a couple of years now, and while frustrating I appreciate problematic nature of the inherent
limitations, like being unable to interrogate values.

I have been playing around with ways in which the basic syntax might be extended that would provide more
flexibility and power in creating 3D models. I'm no computer language expert, but I think the extensions
I propose would ease a lot of frustrations with some of the inherent limitations of the language without
breaking any of the rules.

To start, I would propose an extension of the "dot" notation, that would allow one to refer to a value declaration and/or
function or module component of another module with a dot.

e.g.

module foo() {
valueA = 7;
valueB = 3;

function myFunc(num) = valueA + num;

cube([valueA, valueB, valueB]);

}

module bar() {
valueB = 8;

valueC = foo.valueA + foo.myFunc(valueB); // use the myFunc function of foo to calculate valueC

cube([valueA, valueB, valueC])
foo();

}

Scoping rules would remain as they are, in that value declarations would be at the scope of the called module or module part. i.e. for the
above example the cube created in module bar, valueB would = 8 but it would be 3 in foo.

The second extension would be the election of three operations as 'reserved' functions, union, difference and intersection such that one
could explicitly call that part of a module without calling the others:

module foo() {
valueA = 7;

intersection : {
	cylinder(d = 7, h = 4);
}

difference : {
	cube([8,3,2]);
}

union : {
	translate([9,3,3])
		cube([3,1,1]);
}

}

module bar() {
valueG = foo.valueA;

foo.union(); // would only execute foo.union;
foo(); // would execute intersection(){difference(){union(){<union code>}<difference code>}<intersection code>}

}

One could select the execution of nested module definitions in another module as well… not just the ‘reserved’ functions.

This would allow for a tighter coupling of a module's attributes to it's basic geometry. Simplistically, say one wants a walled cylinder but it will
this part would have differing bases depending on where the cylinder was used in a design. As it stands, one would need to either create
cumbersome code for the cylinder base to avoid the base cylinder definition to avoid 'filling' up the cylinder where the base was, or decouple
the difference operation from the declaration of the cylinder so it will clear out any of the base geometry that is placed in the
way of the shaft.

These two extensions of the syntax would also allow for comparatively effortless calculation of boundary regions where desired without
creating a performance penalty where it is not needed and provide for pseudo polling of an objects characteristics without actually
requiring access to unreachable object values.

I hope that what I see as a manifold increase in the expressive power and abstraction in creating openSCAD programs with these
suggestions for an extended syntax or self-evident... and I'd be interested in what the rest of you might think. If what I’m suggesting is unclear
Please let me know… I didn’t want to bog this proposal down with details if it’s obvious, but in doing that I have taken the risk that the improvement
And benefits of such extensions may not be evident.