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?
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.
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 :(
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
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.
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);
}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.
Yeah. Upcoming Olive Video Editor `0.2.x` would be fully on nodes.[0,1]
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