[OpenSCAD] User Poll: What do you want to see from OpenSCAD development?
nop head
nop.head at gmail.com
Mon Nov 11 10:49:44 EST 2019
> 3MF meshes are 3D printable, so how can it simultaneously be true that
they aren't "physically realizable"?
Just because a 3D printer spits something out doesn't mean it produces an
object that is not 2 manifold. It will either be joined with a finite
thickness or be separated. There will not be a shared edge as there is no
physical meaning to that. The boundary of a read 3D object will always be
2-mainfold.
On Mon, 11 Nov 2019 at 15:07, Doug Moen <doug at moens.org> wrote:
> Hi Ronaldo.
>
> The STL file format is ambiguous. There is no formal written standard.
> Different slicers interpret the same STL file in different ways.
>
> OpenSCAD tries to work around this ambiguity by restricting its output to
> an unambigous subset of STL, which is 2-manifold, watertight, and
> non-self-intersecting.
>
> The 3MF standard is unambigous. There are rules for what constitutes a
> valid mesh, and there are rules for how a slicer should interpret a valid
> mesh. Since it is very difficult, in general, to avoid generating meshes
> that are free from self-intersection, 3MF even has rules for how a slicer
> should interpret self-intersection.
>
> 3MF meshes are required to be 2-manifold, but this means something subtly
> different from what it means in OpenSCAD. An STL mesh is just a list of
> triangles, where each triangle is 3 vertices, and each vertex is 3 numbers.
> In 3MF, there is a level of indirection, as I said before. There is a
> vertex list, which assigns a number (a vertex id) to each vertex, and there
> is a list of triangles, where each triangle is 3 vertex IDs. In 3MF, the
> 2-manifold restriction is defined in terms of vertex IDs. It is legal in
> some cases for two distinct vertex IDs to have the same coordinates. This
> loophole exists so that you can represent 2 cubes sharing an edge.
>
> Doug Moen.
>
> On Mon, Nov 11, 2019, at 12:32 PM, Ronaldo Persiano wrote:
>
> On Mon, 11 Nov 2019 at 04:17, Doug Moen <doug at moens.org> wrote:
>
>
>
> The specific problem being referenced here is that if you have two
> polyhedra that don't intersect (with a non-zero intersection volume), but
> they touch at a vertex or touch at an edge, then you can't represent that
> in an STL file, because the polygon mesh is not 2-manifold.
>
>
> Sorry but STL file format can represent objects (in a broad sense) that
> are not 2-manifolds. As a soup of triangles, STL file format can represent
> the faces of the two cubes sharing just an edge and even flaps. What STL
> cannot represent is its topology as an aggregate of 2-manifolds like 3MF
> seems to do.
>
> I don't know the specification of 3MF but if it is able to represent the
> following:
>
> cube(10);
> translate([5,5,0]) cube(10);
>
>
> not as an union but as an aggregate of two cubes (the same way it would
> represent if the intersect only in an edge), then we may have troubles
> trying to print it because slicers seems to be non consistent in their way
> to interpret that aggregate. A long time ago I have done a test how
> different slicers interpret such aggregate by writing an STL file that
> represent it. And I have found two distinct interpretations: in the former,
> the union was produced; in the later, the common points of the two cubes
> were off the resulting object. Perhaps now they had converged to a common
> interpretation by using the same rule to recognize what points are inside
> the object.
>
> On 11 Nov 2019 at 07:34, nop head <nop.head at gmail.com> wrote:
>
>
> Two cubes cannot share a zero width edge. They either overlap by at least
> one atom or are separate. It is no coincidence that STL can represents all
> physically realisable objects.
>
>
> The STL file format is able to represent two cubes sharing a zero width
> edge. To do it yourself, join the two STL files (keeping only one header
> and one tail) representing each cube. The 2-manifold concept is not a
> physical one but a mathematical abstraction so not necessarily able to be
> physically realizable.
> _______________________________________________
> OpenSCAD mailing list
> Discuss at lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss at lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20191111/9faac6f7/attachment.html>
More information about the Discuss
mailing list