User Poll: What do you want to see from OpenSCAD development?
On 11/22/2019 12:14 PM, nop head wrote:
I use this: https://github.com/nophead/NopSCADlib#Clip Not quite what
you want but it can clip against any plane perpendicular to one of the
axes.
Sure. Like I said, easy enough, but you have to decide how big the cube
should be, and that's annoying.
BTW, why the polyhedron rather than a cube? It sure seems like a
translated cube would be simpler.
Here's the one I wrote some time back:
// @brief Clip children against a specified plane
// @param o point on the plane
// @param v normal vector; retain only this direction
// @param <children> objects to clip
// @note
// Limited to 200x200x200 cube.
module clip(o=[0,0,0],v=[0,0,1]) {
sz = 200;
r = norm(v);
intersection() {
children();
translate(o)
rotate([0, 0, atan2(v[1], v[0])])
rotate([0, acos(v[2]/r), 0])
jcube([sz, sz, sz], centerx=true, centery=true);
}
}
jcube is a cube that you can center on the three axes independently.
Even that usage is legacy in this project; my current standard would be
jcube([sz,sz,sz], justify=[0,0,1]), which expands to
justify(justify=[0,0,1], dims=[sz,sz,sz]) cube([sz,sz,sz]). I don't
immediately remember why jcube doesn't support a single size argument.
Details of those left as an exercise for the reader.
(I wrote that a long time ago, and I never used the rotate capabilities
much if at all, and I haven't checked the trig today. If I got it
wrong, please let me know and I'll be suitably embarrassed.)
While I would be happy to have some of the things already mentioned by others
(like a good standard library, or intersection/difference with a virtually
infinite half-space), the thing that is on top of everything else is:
robustness with respect to incorrect geometry, either happening from bad
user input (polyhedron primitive, bad STL import) or as the result of some
operation which happen to be non 2-manifold or otherwise unsupported.
By robust, I mean that the input to polyhedron, import,... should be fully
validated, the errors properly described in terms of the user code, and any
issue discovered while rendering should be reported immediately, clearly,
and precisely in terms of the SCAD program, not as CGAL assert failures
which only refer to the CGAL implementation.
This is somewhat related to the spawned discussion Discuss manifoldness,
co-incident faces edges etc
http://forum.openscad.org/Discuss-manifoldness-co-incident-faces-edges-etc-td27862i80.html
about lifting current limitations on allowed geometry. I am in favor of
supporting as many "mathematically meaningful" cases as possible in this
respect (in the limits of the CGAL capabilities and people's time to
implement them of course), independently of notions of printable, physical
object. The arguments for allowing such cases like two cubes touching at an
edge have been thoroughly explained.
But whether the limitations are addressed or not, it is essential to check
for incorrect geometry. This is definitely a usability issue, not only for
beginners, and it is very often reported. Here are "a few" occurrences in
the issue tracker
#2351 https://github.com/openscad/openscad/issues/2351
#3117 https://github.com/openscad/openscad/issues/3117
#3107 https://github.com/openscad/openscad/issues/3107
#3100 https://github.com/openscad/openscad/issues/3100
#2847 https://github.com/openscad/openscad/issues/2847
#3082 https://github.com/openscad/openscad/issues/3082
#3034 https://github.com/openscad/openscad/issues/3034
#3023 https://github.com/openscad/openscad/issues/3023
It is absolutely incorrect to close them as not being bugs, it only make
more users spend time reporting an issue which is well known to developers
and experts, but extremely surprising from an outsider's viewpoint. When I
contributed to the first one in the above list (and spent time to reduce the
original test case to just one simple facet), the final argument to close it
was that "this could consume a lot of energy for no gain with correct
geometry". This is absurd, we could say similarly that type-checking
consumes a lot of energy for no gain for well-typed programs. By the way I
am also not convinced either by the "lot of energy". I'm not familiar with
CGAL and it's invariants, but I imagine that someone who knows the code
could add calls to at least validate user input with reasonable effort.
I can perfectly understand that some other issues may have higher priority,
and developers are of course free to work on what they want, but it should
at least be recognized as an issue. No one can seriously consider it a
normal thing that the following two lines:
polyhedron(points=[[1,0,0],[0,0,0],[-0.1,1,0],[0,2,0]],faces=[[0,1,3,2]]);
cube([1,1,1]);
give the following output (with version 2019.11.19.nightly):
CGAL error: assertion violation!
Expression : itl != it->second.end()
File : /usr/include/CGAL/Nef_3/SNC_external_structure.h
Line : 1152
Explanation:
Refer to the bug-reporting instructions at
http://www.cgal.org/bug_report.html
Aborted (core dumped)
--
Sent from: http://forum.openscad.org/
tifn wrote
When I contributed to the first one in the above list (and spent time to
reduce the
original test case to just one simple facet), the final argument to close
it
was that "this could consume a lot of energy for no gain with correct
geometry".
I closed it because you had reproduced the issue, confirming it was a
malformed polyhedron producing the CGAL assertion. Nothing to be fixed in
OpenSCAD. We get CGAL assertion error reports regularly, very few - close to
zero, are other than bad STLs or poly's.
What I actually said was
There is some discussion on whether to expend resources checking validity
of poly's & import individually prior to render, but this could consume a
lot of energy for no gain with correct geometry.
I agree with you that a CGAL assertion is not a very user friendly method to
report problems with geometry.
Admin - email* me if you need anything, or if I've done something stupid...
- click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
--
Sent from: http://forum.openscad.org/
tifn wrote
polyhedron(points=[[1,0,0],[0,0,0],[-0.1,1,0],[0,2,0]],faces=[[0,1,3,2]]);
cube([1,1,1]);
give the following output (with version 2019.11.19.nightly):
CGAL error: assertion violation!
Expression : itl != it->second.end()
File : /usr/include/CGAL/Nef_3/SNC_external_structure.h
Line : 1152
Explanation:
Refer to the bug-reporting instructions at
http://www.cgal.org/bug_report.html
Aborted (core dumped)
tifn, what did you use that output the last 4 lines?
I don't see that in the GUI (Windows/Debian) or command-line (Windows).
Admin - email* me if you need anything, or if I've done something stupid...
- click on my MichaelAtOz label, there is a link to email me.
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
--
Sent from: http://forum.openscad.org/
MichaelAtOz wrote
I closed it because you had reproduced the issue, confirming it was a
malformed polyhedron producing the CGAL assertion. Nothing to be fixed in
OpenSCAD. [...]
I precisely disagree with that, I'm advocating that there is something to
be fixed in OpenSCAD.
I will answer the "core dump" part in the issue.
--
Sent from: http://forum.openscad.org/
Considering the advent of function literals, some builtin OpenSCAD
functions might allow an additional function argument like in the following
examples:
function max() ( or min() ):
L = [ ["one", 1] , ["zero",0], ["two",2] ];
pick = function(x) x[1];
echo( max(L, fn=pick)[0] ); // ECHO: "two"
or, even better with a comparison function:
L = list of strings
compare = function(a,b) lexicographic_comparison (a,b); // user provided
a = max(L, fn=compare);
function search():
L = [ ["one", [1, 0] ] , ["zero", [0,12] ], ["two",[2,1] ] ];
pick = function(x) x[1][1] ;
echo( search(12, L, fn=pick) ); // ECHO: ["zero", [0,12] ]
That would increase a lot the power of those functions.
Similarly, I would use the heck out of map(), filter(), and reduce()
primitives, a la other functional languages.
On Mon, Dec 2, 2019 at 5:52 AM Ronaldo Persiano rcmpersiano@gmail.com
wrote:
Considering the advent of function literals, some builtin OpenSCAD
functions might allow an additional function argument like in the following
examples:
function max() ( or min() ):
L = [ ["one", 1] , ["zero",0], ["two",2] ];
pick = function(x) x[1];
echo( max(L, fn=pick)[0] ); // ECHO: "two"
or, even better with a comparison function:
L = list of strings
compare = function(a,b) lexicographic_comparison (a,b); // user provided
a = max(L, fn=compare);
function search():
L = [ ["one", [1, 0] ] , ["zero", [0,12] ], ["two",[2,1] ] ];
pick = function(x) x[1][1] ;
echo( search(12, L, fn=pick) ); // ECHO: ["zero", [0,12] ]
That would increase a lot the power of those functions.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
For instance right now I'm working on a library for doing affine transforms
on points/paths, to help me build up objects for use with polyhedron().
Right now if I want to compose the convenience functions I've written for
doing so, my points end up being translated back and forth from Cartesian
to homogenous coordinates. If I had a reduce() primitive, I could take the
different matrices I want to apply, and multiply them together. Of course i
could do that manually, and for now I will if I think it's a performance
sensitive area, but that sort of defeats the purpose of having my
convenience functions.
On Mon, Dec 2, 2019 at 9:41 AM Max Bond max.o.bond@gmail.com wrote:
Similarly, I would use the heck out of map(), filter(), and reduce()
primitives, a la other functional languages.
On Mon, Dec 2, 2019 at 5:52 AM Ronaldo Persiano rcmpersiano@gmail.com
wrote:
Considering the advent of function literals, some builtin OpenSCAD
functions might allow an additional function argument like in the following
examples:
function max() ( or min() ):
L = [ ["one", 1] , ["zero",0], ["two",2] ];
pick = function(x) x[1];
echo( max(L, fn=pick)[0] ); // ECHO: "two"
or, even better with a comparison function:
L = list of strings
compare = function(a,b) lexicographic_comparison (a,b); // user provided
a = max(L, fn=compare);
function search():
L = [ ["one", [1, 0] ] , ["zero", [0,12] ], ["two",[2,1] ] ];
pick = function(x) x[1][1] ;
echo( search(12, L, fn=pick) ); // ECHO: ["zero", [0,12] ]
That would increase a lot the power of those functions.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I don't think min()/max() and similar functions are good
candidates for extension, if at all, they should get simpler
(but that's hard to impossible to do).
I see function arguments are things like linear_extrude()
where the function parameter could really add huge value.
Fold/Reduce is already possible right now, although it's
a bit awkward with passing along the vector index, e.g. like
fold = function(i, v, f, off = 0) len(v) > off ? fold(f(i, v[off]), v, f, off + 1) : i;
Which is why I think we really want the array/vector slicing
which would change it to
fold = function(i, v, f) len(v) > 0 ? fold(f(i, v[0]), v[1:], f) : i;
With fold, here's max and the max with picking:
max = function(v) fold(0, v, function(x, y) y > x ? y : x);
echo(max([1, 6, 2, 9, 3])); // ECHO: 9
maxp = function(v) fold(["", -1], v, function(x, y) y[1] > x[1] ? y : x);
echo(maxp([ ["one", 1] , ["zero",0], ["two",2] ])[0]); // ECHO: "two"
ciao,
Torsten.
The case I definitely needed this for was sort... I did an
implementation of merge sort and quick sort, both of which desperately
need a comparison function argument to be properly generic...
On Mon, Dec 2, 2019 at 3:09 PM Torsten Paul Torsten.Paul@gmx.de wrote:
I don't think min()/max() and similar functions are good
candidates for extension, if at all, they should get simpler
(but that's hard to impossible to do).
I see function arguments are things like linear_extrude()
where the function parameter could really add huge value.
Fold/Reduce is already possible right now, although it's
a bit awkward with passing along the vector index, e.g. like
fold = function(i, v, f, off = 0) len(v) > off ? fold(f(i, v[off]), v, f, off + 1) : i;
Which is why I think we really want the array/vector slicing
which would change it to
fold = function(i, v, f) len(v) > 0 ? fold(f(i, v[0]), v[1:], f) : i;
With fold, here's max and the max with picking:
max = function(v) fold(0, v, function(x, y) y > x ? y : x);
echo(max([1, 6, 2, 9, 3])); // ECHO: 9
maxp = function(v) fold(["", -1], v, function(x, y) y[1] > x[1] ? y : x);
echo(maxp([ ["one", 1] , ["zero",0], ["two",2] ])[0]); // ECHO: "two"
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org