[OpenSCAD] User Poll: What do you want to see from OpenSCAD development?

tifn tiphaine.turpin at free.fr
Fri Nov 29 19:27:33 EST 2019


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/



More information about the Discuss mailing list