Two objects can't share an edge in reality, so there is no reason to send
such models to a 3D printer. If you want them joined then have some
overlap, if not leave a gap.

On 27 February 2018 at 14:45, Jordan Brown openscad@jordan.maileater.net
wrote:

Jordan,

The manifold condition is demanded mainly for technical reasons.
Fortunately, it agrees with the common sense for 3D printing as nophead
likes to say. But many algorithms would be more complex if the manifold
condition is not met. For instance, imagine a slicer algorithm computing
the outer hotend path of a layer. When it arrives to the edge of the mesh,
it should decide where to go from there. If the edge is common to two cubes
there are three possible ways to go on and the algorithm should keep a
record of the decision it makes there in order to avoid retracing a path
already taken. With a manifold condition there is only one way to go on
from an edge and you don't need to keep any record.

2018-02-27 11:45 GMT-03:00 Jordan Brown openscad@jordan.maileater.net:

On Tue, Feb 27, 2018 at 04:28:45PM +0000, nop head wrote:

My printer makes the outsides of objects quite accurately. But when I
command a 3mm hole in openscad, I get something quite a lot smaller.

I can then command a 3.5mm hole and get something that fits a 3mm
bolt. Great.

The problem with this approach is that I can design perfect objects
for my printer, but they will work "not well" for others.

The objects STL/openscad that we publish should be as close as
possible to "what works". People should preferably tell the slicer to
increase the hole sizes etc.etc.

Suppose I have

union () {
cube ([20,20,1]);
translate ([10,0,0]) cube (10);
translate ([0,10,0]) cube (10);
}

In theory two of these can mate. In practice, to make it work
you would have to do something like this.

tol=0.2;
union () {
cube ([20,20,1]);
translate ([10+tol,0,0]) cube ([10-tol,10,10]);
translate ([0,10+tol,0]) cube ([10,10-tol,10]);
}

So... I would think that "edges in common" are something that happen
commonly "theoretically ideal" files. And it would be preferable to be
able to load such theoretical files into slicers because that
eliminates the tolerances that individual printers have from the
object-description-files.

Roger. 

--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
-- BitWizard writes Linux device drivers for any device you may have! --
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

I can, by the way, readily believe that in a polygon soup it may be
difficult or perhaps even impossible to decide what parts are inside and
what parts are outside.  If you have six cubes laid out touching around
a central cubic void, I could easily believe that it would be hard to
tell whether that central cube should or should not be filled.  That
seems like a key problem with a "polygon soup" structure.

On 2/27/2018 8:28 AM, nop head wrote:

Can't they?

For all macroscopic purposes, they can - if I take two cubes and shove
them corner-to-corner, they sure look like they are sharing an edge.

Yes, I understand that at some microscopic / mathematical level they
aren't, but why do I have to care about that?

On 2/27/2018 9:02 AM, Ronaldo Persiano wrote:

If my two cubes were separated by a tiny distance - say, a micrometer -
then the slicer would know what to do.  It would probably try (and
probably fail) to separate the two paths by a micrometer, and the result
would probably be either a tiny gap or a tiny overlap.

If my two cubes were joined by a similarly tiny distance, the slicer
would again know what to do.  It would probably consider putting plastic
across the joint, realize that the plastic would have to be much smaller
than the extrusion width, and either leave a gap or lay down plastic far
larger than that called for by the model.

So if the slicer can handle a gap of epsilon, and it can handle a joint
of epsilon, and it produces pretty much the same result in both cases,
why does a gap of zero cause its brain to explode?  Or perhaps I should
say:  why SHOULD a gap of zero cause its brain to explode?

In 3D printing, the resolution is around 100um (depending on printer and
axis blah blah blah).  Anything below that is too small to care about...
so why should we have to care about it?

I can get that the algorithms might be a little simpler, but how many
slicer developers are there and how many model designers are there? 
Which does it make sense to optimize for?

Also:  it seems like your slicer algorithm will inevitably be faced with
issues like this, because it's dealing with physical reality, not math. 
If the two cubes have a joint that is only one extrusion width wide, the
slicer is faced with the same three-way choice.  Similarly if it's three
extrusion widths wide, when making the second loop.  In fact, the "zero"
case seems easier - there (if you've defined that the edge of the
mathematical object should be the edge of the physical object) it's
clear that it must stay on the "same" cube, because the centerline of
the extrusion must be 0.5EW inside the mathematical boundary... and
transitioning onto that other cube would necessarily take the plastic
outside of the bounds of the mathematical object.

Sorry, I thought I read ahead before responding, but it seems not.

On 2/27/2018 11:50 AM, Troberg wrote:

Exactly!  :-)

As you will have seen, that was my guess.

This is a "polygon soup" problem, that would be solved using a data
structure that directly represents polyhedra, right?

JordanBrown wrote

I'm not sure that "directly represents polyhedra" means anything.
Something like a voxel model would not have these issues, but has its own
drawbacks.

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

On 2018-02-28 00:43, Jordan Brown wrote:

No, the issue of where the material is and where the void is, is
unrelated to the question of "polygon soup" vs. an explicitly connected
polyhedron, assuming the "polygon soup" is reasonable enough that
connectivity can be inferred from it.

What is is "inside" is entirely determined by the triangle face normal
vectors. The normal vector is computed from the 3 triangle vertex
coordinates, i.e. cross product of 2 vectors. It is the local order of
the triangle vertices that determines which way the face normal points
and therefore also where "inside" and "outside" is. This can be either
way in both a polyhedron and a polygon soup representation.

To make a meaningful solid you need to have faces that are properly
connected to a single neighbour at each edge (2 manifold) and the
normals must be consistently pointing the same way ("outwards") from one
face to its neighbour. The face normal requirement is valid also when
you have a polygon soup like STL.

Your six cube example is ok wrt. defining inside/outside as long as the
face normals all point out of the cubes. You will however have 12 edges
that are not 2 manifold (they are each referenced by 4 faces rather than
2).

size = 10;
delta = 0;
union() {
translate([-size+delta,0,0])cube(size,center=true);
translate([0,-size+delta,0])cube(size,center=true);
translate([+size-delta,0,0])cube(size,center=true);
translate([0,+size-delta,0])cube(size,center=true);
translate([0,0,-size+delta])cube(size,center=true);
translate([0,0,+size-delta])cube(size,center=true);
}

The material volume of this is well defined (6000) even if it is not
2-manifold. You could print it, but it would fall apart. For a real-life
print you would set delta to some reasonable small value, and the model
becomes 2-manifold and would hold together.

Carsten Arnholm

On 2/28/2018 12:52 AM, arnholm@arnholm.org wrote:

If you have a real polyhedron definition, where you know which triangles
belong together and how they are connected, do you still need to care
about normal vectors?

(Assuming that you define the rest of the universe to be "outside".)

Intuitively, it seems like a particular volume is "inside" if in getting
there from the outside you have to cross an odd number of faces.

Yes.

Right.  It was intended as a geometry discussion point, not something
really printable.  (But two cubes with touching edges, on top of another
object, would be not-2-manifold, but would be reasonably sensible to print.)