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

nop head nop.head at gmail.com
Tue Nov 12 17:02:36 EST 2019

My point is that all objects that can be printed are 2 manifold. Therefore
there is no reason why OpenSCAD needs to be able to model objects that
aren't 2-manifold because that can never be a valid design intent.

The fact that a 3D printer never exactly matches a model due to tolerances
is a different thing. My 3D printers always produce manifold objects so it
makes no sense to send them a non-manifold design because no matter how
accurate they are they cannot print it.

>Why is there any practical difference between two cubes that share an
edge, two cubes that are separated by a micrometer, and two cubes that
overlap by a micrometer?

Because separate cubes separated by a micrometer is a valid design intent.
When sent to a 3D printer it creates two separate cubes with their own
outlines. Yes most likely they will be weakly bonded but easily separated.
Sending  a design with a shared edge is nonsense as it never exists in
reality, only in maths. Sending a design where they overlap by one micron
only make sense on a printer that can produce 1 micron walls. So if they
overlap it should be my much more than that.

So the set of printable objects is ones that have two separate boundaries
plus those that overlap by the minimum feature size. It does not include
the case where they share an edge, so why should OpenSCAD and all the
downstream tools cater for that edge case? Better to tell the user it is an
invalid design intent.

On Tue, 12 Nov 2019 at 18:31, Jordan Brown <openscad at jordan.maileater.net>

> On 11/11/2019 11:19 PM, nop head wrote:
> Since all real objects are 2-manifold I don't see why OpenSCAD needs to be
> able to handle non-manifold designs. What advantage is it?
> Not having to take care to never allow two objects to touch?  Not having
> to explain to people what "manifold" means?
> (This isn't contrived; I've had real modeling cases where two objects
> happened to touch at a single point.  I had to figure out what was
> happening and then artificially tweak them apart.)
> If you want to print two cubes next to each then leave a small gap.
> Why?  Why should I have to do this, when the intent is obvious?
> They will then get two separate perimeters. If you want to print two cubes
> that are joined overlap them by your printers minimum wall width. Your
> model then represents what  you want your printer to print. If you export
> two cubes sharing an edge who knows what the printer will do? It is much
> better to give an error as soon as possible to avoid creating a model that
> can't be printed. Yes the printer may print something but it won't match
> the physically impossible model.
> My point is that *it doesn't matter* what the printer does.
> Why is there any practical difference between two cubes that share an
> edge, two cubes that are separated by a micrometer, and two cubes that
> overlap by a micrometer?  The printer's resolution isn't anywhere near that
> small. It can't match *any* of the three, yet the software treats them all
> as fundamentally different, and considers two "possible" and the third
> "impossible".
> When you say "can't be printed", do you mean "that the software can't
> handle", or do you mean "where what is printed does not perfectly match the
> mathematical model"?  If the software can't handle it, that's exactly the
> problem I'd like to see solved.  If the printed object does not perfectly
> match the mathematical model... *nothing* printed ever perfectly matches
> the mathematical model.  cube(100) is supposed to generate a cube 100 units
> on a side.  What gets printed is the result of mushing together a bunch of
> cylinders of plastic - the sides aren't flat, the edges are round instead
> of right angles, and it's measurably off 100 units.  Printing is *always*
> an approximation of the mathematical model.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20191112/c977cf98/attachment.html>

More information about the Discuss mailing list