On 2018-01-18 10:29, Parkinbot wrote:

My comment was not referring to STL or other output formats, only the
internal OpenSCAD definition of polyhedron. Ref. the OpenSCAD
documentation of polyhedron I lniked to. Either the documentation should
be changed to reflect the software, or the documented rule requiring
planar faces should be enforced.

OpenSCAD should tell the user when it receives clearly illegal input
according to documentation. Such illegal polyhedrons are usually a sign
of user error. There are many examples of novice users that run into
problems because they make mistakes in this area. My comment was
motivated to help such users.

Experienced users like yourself may "abuse" it to achieve useful special
effects like you describe. This is quite legitimate, but it sounds to me
like a different feature. You could perhaps serve both groups of users
by

a) Enforcing stricter rules on polyhedrons, and give good error messages
instead of silently accepting everything that is clearly wrong given
polyhedron definitions. This would help novice users.

b) Introduce a new feature to serve the more advanced needs you
describe. For example you could introduce a new object type called
"polygonsoup" (or whatever name you prefer) that has exactly the same
input syntax as polyhedron, but with relaxed rules, allowing previews of
polygons in 3d space.

Or, if you don't like a new type, then the default behaviour of
polyhedron could be as in a), but an extra "relaxed_rules=true"
parameter could relax the rules, so you get b).

Carsten Arnholm

cacb wrote

Polyhedron and polygon is like Peek and Poke of BASIC. While it opens the
door to hell, it does all the rest, what you can't do with the ordinary
language. History has shown that any accepted language needs such backdoors
and I don't see anything wrong in having some features for power users of
OpenSCAD, as they give most of the qualified feedback and do most of the
testing and "marketing" by producing impressive designs. To be honest,
without polyhedron I would have dropped the language after three weeks of
use, latest. In my eyes it is the real expressive power of OpenSCAD. Why
castrate it - and break a lot of code out there? Because a novice user can
stumble over it? If you offer a solution that differences out several
primitives with little differences, he will stumble at this point. You are
using and propagating AngleScript, because it lets you do things, that
OpenSCAD doesn't let you do. So you will understand this point.
I wouldn't touch these primitives, but opt to more emphazise the difference
between CSG and CGAL in the documentation. Most people especially beginners
don't know this essential difference.
F6 can (and should) give warnings about improper topologies, like it does
when it finds a singularity. But why should it prevent me with an error from
writing out an improper topology into an STL?

Why sacrifice parts of the expressive power of CSG (e.g. color), only
because CGAL is not rich enough? There is a F5 and a F6. And they lead into
different worlds. E.g. I use OpenSCAD a lot to produce animations and to
explain things visually. You don't need proper polyhedrons or manifolds for
that, but fast and powerful code.

I would also provide a built-in import function like

data = import("mystl.stl");

that lets me implement all sorts of query and modifier stuff like

function boundary(data) = ...

or write code like

polyhedron(data[0]. data[1]);

and introduce at least a rudimentary interface for data import in a
standardized format (binary and ASCII). This would offer a pathway to solve
most of the severe problems (like quering a design), more experienced people
run into after having invested some learning time into OpenSCAD and trying
to implement something more sophisticated. Of course the import function
should be extended to support all data formats, OpenSCAD can write out.
Currently one has to write (or find) code that converts these formats into
SCAD code, which is very clumsy.

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

On 1/18/2018 1:29 AM, Parkinbot wrote:

I have no idea whether there's  anything in the format spec, but it's
quite frustrating to generate something with OpenSCAD, feed it to my
slicer, and have my slicer misbehave because it doesn't follow the rules.

(As best I can tell, usually this happens when there are extremely small
features that start running into the OpenSCAD resolution limits - like
when I took my 25.4:1 scale model of my house and then scaled it down by
a further 25.4:1.)

(Intuitively, I would say that a string of points that aren't coplanar
cannot be a face of a polyhedron.  They might be something else, and I
don't have a problem with having a way to create and manipulate them
under a different name.)

Is there a middle ground here where error messages are displayed when an
invalid STL file is created, so that you can avoid feeding that STL to
your slicer while the other OpenSCAD features remain intact?  Perhaps I
am missing a subtlety here

Jon

On 1/18/2018 12:20 PM, Jordan Brown wrote:

--
Sent from my desktop computer.
I do not receive emails while away from my desk,
nor do I receive texts on my main phone number
(which is a land line).
If you know that I am on the road, please text me.
If you know that I am home, please email me.

JordanBrown wrote

Currently there is either no hint (emptying the cache can help), or a
cryptic CGAL error or a warning in the case of a singularity.
The current workaround to have a user defined polyhedron explicitly tested
for manifoldness is to union it with something else (any Boolean operation
will do) starting from an empty cache.

mypolyhedron();
cube();

There was a planarity bug connected with polyhedra faces in the late 2017
dev builds, which has been fixed in the 2018.1.x Have you tried to update?
It is also known that you can sometimes heal a small scale design by scaling
it up, while a scale-down is never a good idea.

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

On 18. jan. 2018 15:23, Parkinbot wrote:

My point was simply that the door to hell does not have to be wide open
for everyone all the time. You can open it when you want to.

I think you scanned my post too fast, because I never said there is
anything wrong with power features, on the contrary I said power
features are legitimate. My message is to support the needs of both
novices as well as power users, and my post suggested ways of doing it.

To my knowledge, nobody suggests dropping polyhedron.

Carsten Arnholmdy

On 1/18/2018 10:03 AM, Parkinbot wrote:

I don't use polyhedra very much.  My top-level comment was that
generating STL files that don't follow the rules is rude.

And a side comment that by a common-sense definition, a list of points
that's not coplanar is not a polyhedron face.

I did need a scaled-down version of the model.  (After all, it's a model
of my house; it has to include a copy of the model https://xkcd.com/878/.)

I don't remember how I got it to print.  Maybe I just ignored the things
the slicer did wrong.  I might have been better off having the STL be
full-sized (about a meter across) and then scaling down in the slicer.

JordanBrown wrote

If you buy a product or pay a lot money for the licence, the word "rude"
might apply ...

If you want constructive help it is a good idea to show some code that
misbehaves and - again - to test it with the latest development snapshot
first.

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

On 19/01/18 21:00, Parkinbot wrote:

On the contrary if its free (as in beer) and open source then it would
be "rude" to make some inappropriate output to a STL file, if not at
least because you're sure gonna get called out on it... in public... so
better to do it right....