Manifolds and sharing edges/faces

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Manifolds and sharing edges/faces

jim_klessig
Someone wrote 

"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. "

To my mind, that is only true if you DEFINE "reality" as not having conjoined faces. 
IF you allow for "reality" to have conjoined faces, then you will find them every where. A block of 1*1*2 is in "reality" two  1*1*1 cubes with a common face. 

Why should "overlap be a requirement of them being "joined"? If any thing I would think "overlap" should be the "forbidden concept". That is the thing you can not actually realize in the real world.



Sent from my U.S. Cellular® Smartphone

-------- Original message --------
Date: 2/27/18 9:00 AM (GMT-08:00)
Subject: Discuss Digest, Vol 39, Issue 27

Send Discuss mailing list submissions to
[hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
or, via email, send a message with subject or body 'help' to
[hidden email]

You can reach the person managing the list at
[hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss digest..."


Today's Topics:

   1. Re: damaged STL file? (Jordan Brown)
   2. Re: damaged STL file? (Carsten Arnholm)
   3. Re: damaged STL file? (nop head)
   4. Re: damaged STL file? (doug moen)
   5. Re: damaged STL file? (Ronaldo Persiano)
   6. Re: damaged STL file? (nop head)
   7. Re: damaged STL file? (Ronaldo Persiano)
   8. Re: damaged STL file? (nop head)
   9. Re: damaged STL file? (Ronaldo Persiano)
  10. Re: damaged STL file? ([hidden email])
  11. Re: damaged STL file? (Gadgetmind)
  12. Re: damaged STL file? (nop head)
  13. Re: damaged STL file? (Mark Schafer)
  14. Re: damaged STL file? (Rogier Wolff)
  15. Why are manifolds important? (Jordan Brown)
  16. Re: damaged STL file? (doug moen)
  17. Re: Why are manifolds important? (nop head)


----------------------------------------------------------------------

Message: 1
Date: Mon, 26 Feb 2018 09:35:32 -0800
From: Jordan Brown <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>,
[hidden email]
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

On 2/26/2018 7:41 AM, [hidden email] wrote:
> In general I think the thread illustrates the somewhat fuzzy nature of
> repairing problematic polyhedra in general and STL files in particular
> (STLs do not provide any topology, it must be guessed). Several repair
> tools exist but they appear to make different assumptions leading to
> different results.

Are there other file formats that would be better?? Getting designers
like OpenSCAD and slicers to *both* implement something new would be
tough, but if there are clear benefits maybe it could be done.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180226/830a8339/attachment-0001.html>

------------------------------

Message: 2
Date: Mon, 26 Feb 2018 20:44:57 +0100
From: Carsten Arnholm <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8; format=flowed

On 26. feb. 2018 18:35, Jordan Brown wrote:
> Are there other file formats that would be better?? Getting designers
> like OpenSCAD and slicers to *both* implement something new would be
> tough, but if there are clear benefits maybe it could be done.

Yes, there are better formats (see below), but STL seems so entrenched
that it is very hard to get wide enough support for anything else. Some
requirements to a non-STL format I guess would be

1) Suited for polyhedron exchange between CAD applications, not just CAD
to slicers.

2) Unambiguous format, with explicit topology

3) Efficient binary storage, plus equivalent ascii text version with
same info. Binary/Ascii should be transparent to users.

4) It must be *very* simple.

etc.

OpenSCAD already support other 3D formats in addition to STL

OFF - http://paulbourke.net/dataformats/off/
AMF - https://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format

Both of the above satisfy 1) and 2). AMF in its simplest form is quite
nice, but not terribly efficient, plus in my opinion it forgets 4) so it
will never become universal. OFF is a nice contender, but it does not
seem to be simple enough to be popular.

STL is both wasteful and ambiguous, it is just a sea of free floating
triangles. The binary format does not contain the same info as the text
format, etc. Its popularity is due to history only.

It seems to me super simplicity is a key. So any alternative format
should be even simpler than STL. Given that existing alternatives are
not very popular, we might as well propose something new to compete,
making simplicity the key feature while fixing some of the STL issues.
In my mind it could be something like

* simple file header to identify ASCII/Binary
* vertex coordinates stored only once
* triangle faces only
* faces defined by references to vertices, implicit normals

In other words, just the bare minimum, equivalent to the info that goes
into OpenSCAD polyhedron command. The text format would be more compact
than STL and simpler to read. The binary format would also be more
compact than STL since coordinates would be mentioned only once, and
therefore also not have any issues with interpretation.

You could say it is far too simple. But if you want it to be widely
adopted it must be extremely simple and fast. We could call it STL2 and
say it is how STL should have been defined in 1985 or so :-)

I don't have any illusions it would be successful, but if it was adopted
I think it would be helpful in avoiding some of the "damaged STL" issues
(not all) and enable easier sharing of models between various applications.

Just my thoughts, nothing else.

Carsten Arnholm



------------------------------

Message: 3
Date: Mon, 26 Feb 2018 20:00:48 +0000
From: nop head <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<CAEEmnrPb=[hidden email]>
Content-Type: text/plain; charset="utf-8"

STL is unambiguous if it is written correctly and only used to represent a
manifold model with no self intersections. That is sufficient for 3D
printing as all 3D printed objects are manifold.

While other representations can also represent non-manifold objects it
pushes the problem downstream. How do you print a non-manifold object?



On 26 February 2018 at 19:44, Carsten Arnholm <[hidden email]> wrote:

> On 26. feb. 2018 18:35, Jordan Brown wrote:
>
>> Are there other file formats that would be better?  Getting designers
>> like OpenSCAD and slicers to *both* implement something new would be tough,
>> but if there are clear benefits maybe it could be done.
>>
>
> Yes, there are better formats (see below), but STL seems so entrenched
> that it is very hard to get wide enough support for anything else. Some
> requirements to a non-STL format I guess would be
>
> 1) Suited for polyhedron exchange between CAD applications, not just CAD
> to slicers.
>
> 2) Unambiguous format, with explicit topology
>
> 3) Efficient binary storage, plus equivalent ascii text version with same
> info. Binary/Ascii should be transparent to users.
>
> 4) It must be *very* simple.
>
> etc.
>
> OpenSCAD already support other 3D formats in addition to STL
>
> OFF - http://paulbourke.net/dataformats/off/
> AMF - https://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format
>
> Both of the above satisfy 1) and 2). AMF in its simplest form is quite
> nice, but not terribly efficient, plus in my opinion it forgets 4) so it
> will never become universal. OFF is a nice contender, but it does not seem
> to be simple enough to be popular.
>
> STL is both wasteful and ambiguous, it is just a sea of free floating
> triangles. The binary format does not contain the same info as the text
> format, etc. Its popularity is due to history only.
>
> It seems to me super simplicity is a key. So any alternative format should
> be even simpler than STL. Given that existing alternatives are not very
> popular, we might as well propose something new to compete, making
> simplicity the key feature while fixing some of the STL issues. In my mind
> it could be something like
>
> * simple file header to identify ASCII/Binary
> * vertex coordinates stored only once
> * triangle faces only
> * faces defined by references to vertices, implicit normals
>
> In other words, just the bare minimum, equivalent to the info that goes
> into OpenSCAD polyhedron command. The text format would be more compact
> than STL and simpler to read. The binary format would also be more compact
> than STL since coordinates would be mentioned only once, and therefore also
> not have any issues with interpretation.
>
> You could say it is far too simple. But if you want it to be widely
> adopted it must be extremely simple and fast. We could call it STL2 and say
> it is how STL should have been defined in 1985 or so :-)
>
> I don't have any illusions it would be successful, but if it was adopted I
> think it would be helpful in avoiding some of the "damaged STL" issues (not
> all) and enable easier sharing of models between various applications.
>
> Just my thoughts, nothing else.
>
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> 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/20180226/225993fd/attachment-0001.html>

------------------------------

Message: 4
Date: Mon, 26 Feb 2018 15:29:48 -0500
From: doug moen <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

3MF is a superior alternative to AMF.
* It is less ambiguous, due to explicit rules on how to interpret certain
non-manifold models that AMF leaves undefined. Specifically, it allows self
intersection and overlapping triangles. Here's one reason why this is
important. The union operation is not closed with respect to manifold
meshes. If you union two manifold meshes, the result may not be manifold. I
feel this is actually a defect in the definition of "manifold", because I
think it's intolerable if you can't union two arbitrary shapes and be
guaranteed to get a meaningful result. In any case, 3MF fixes this by
defining the result of the union of two manifold meshes to be a valid 3MF
model in all cases. AMF does not do this.
* 3MF is an open standard, and AMF is not (you have to pay money for a copy
of the AMF standard, and you can't redistribute your copy of this secret,
proprietary information.)
* 3MF has an open source library on github which interprets the standard.
* Nop head asks "how do you print a non-manifold object?". Well, the 3MF
standard and the associated library implementation gives some unambiguous
answers to that, for the cases that I mention above.

OpenSCAD has a 3MF implementation underway:
https://github.com/openscad/openscad/pull/1802.

The Cura slicer used to have an AMF implementation, but got rid of it, and
they now implement 3MF instead.

I feel it is not productive or useful at this point to design yet another
mesh file format.

On 26 February 2018 at 14:44, Carsten Arnholm <[hidden email]> wrote:

> On 26. feb. 2018 18:35, Jordan Brown wrote:
>
>> Are there other file formats that would be better?  Getting designers
>> like OpenSCAD and slicers to *both* implement something new would be tough,
>> but if there are clear benefits maybe it could be done.
>>
>
> Yes, there are better formats (see below), but STL seems so entrenched
> that it is very hard to get wide enough support for anything else. Some
> requirements to a non-STL format I guess would be
>
> 1) Suited for polyhedron exchange between CAD applications, not just CAD
> to slicers.
>
> 2) Unambiguous format, with explicit topology
>
> 3) Efficient binary storage, plus equivalent ascii text version with same
> info. Binary/Ascii should be transparent to users.
>
> 4) It must be *very* simple.
>
> etc.
>
> OpenSCAD already support other 3D formats in addition to STL
>
> OFF - http://paulbourke.net/dataformats/off/
> AMF - https://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format
>
> Both of the above satisfy 1) and 2). AMF in its simplest form is quite
> nice, but not terribly efficient, plus in my opinion it forgets 4) so it
> will never become universal. OFF is a nice contender, but it does not seem
> to be simple enough to be popular.
>
> STL is both wasteful and ambiguous, it is just a sea of free floating
> triangles. The binary format does not contain the same info as the text
> format, etc. Its popularity is due to history only.
>
> It seems to me super simplicity is a key. So any alternative format should
> be even simpler than STL. Given that existing alternatives are not very
> popular, we might as well propose something new to compete, making
> simplicity the key feature while fixing some of the STL issues. In my mind
> it could be something like
>
> * simple file header to identify ASCII/Binary
> * vertex coordinates stored only once
> * triangle faces only
> * faces defined by references to vertices, implicit normals
>
> In other words, just the bare minimum, equivalent to the info that goes
> into OpenSCAD polyhedron command. The text format would be more compact
> than STL and simpler to read. The binary format would also be more compact
> than STL since coordinates would be mentioned only once, and therefore also
> not have any issues with interpretation.
>
> You could say it is far too simple. But if you want it to be widely
> adopted it must be extremely simple and fast. We could call it STL2 and say
> it is how STL should have been defined in 1985 or so :-)
>
> I don't have any illusions it would be successful, but if it was adopted I
> think it would be helpful in avoiding some of the "damaged STL" issues (not
> all) and enable easier sharing of models between various applications.
>
> Just my thoughts, nothing else.
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> 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/20180226/cafd3473/attachment-0001.html>

------------------------------

Message: 5
Date: Mon, 26 Feb 2018 17:36:13 -0300
From: Ronaldo Persiano <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

I agree that STL is a waster format. But Arnholm four point proposal does
not assure a manifold definition neither it is more restrict than STL
format. In fact, any model expressed in a STL file may be expressed by an
OpenSCAD command whether it is a manifold or not.

Besides, with the advent of multi-material 3D print, a more general format
will be demanded representing a partition of the space in many adjacent
volumes to be filled with different materials. Although each of those
volumes might be a manifold, the whole model is not anymore.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180226/77021b5e/attachment-0001.html>

------------------------------

Message: 6
Date: Mon, 26 Feb 2018 20:46:40 +0000
From: nop head <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

I have never seen a physical solid object that isn't manifold. Surely that
is impossible, so if everything you can 3D print is manifold why do need to
represent non-manifolds. They only exist mathematically, not physically.

On 26 February 2018 at 20:36, Ronaldo Persiano <[hidden email]>
wrote:

> I agree that STL is a waster format. But Arnholm four point proposal does
> not assure a manifold definition neither it is more restrict than STL
> format. In fact, any model expressed in a STL file may be expressed by an
> OpenSCAD command whether it is a manifold or not.
>
> Besides, with the advent of multi-material 3D print, a more general format
> will be demanded representing a partition of the space in many adjacent
> volumes to be filled with different materials. Although each of those
> volumes might be a manifold, the whole model is not anymore.
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> 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/20180226/ff950978/attachment-0001.html>

------------------------------

Message: 7
Date: Mon, 26 Feb 2018 18:27:32 -0300
From: Ronaldo Persiano <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<CA+i9EaCOWiMjCOt+WvzEqJ5+E81zeQK97G9YFQ71LPEtOU+R=[hidden email]>
Content-Type: text/plain; charset="utf-8"

> I have never seen a physical solid object that isn't manifold. Surely that
> is impossible, so if everything you can 3D print is manifold why do need to
> represent non-manifolds. They only exist mathematically, not physically.
>
?
Consider two same axis cylinders joined end to end by an union operation.
If they have the same diameter, the union will be a longer cylinder. But if
the top cylinder should be 3D printed with a opaque filament and the bottom
one with a translucent one, the longer cylinder is not a good model for
printing it. We may want a two distinct volume with a common face. That is
not neither the union of two cylinders nor a manifold.

?I agree with you but 3D printing is not the only goal of CAD system in
general and of OpenSCAD in special. It would be legitimate to use OpenSCAD
for illustration, for instance. In an illustration of a car, why must the
motor hood have a thickness instead of being just the top hood surface?
Another non-manifold object.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180226/d6d1f4a3/attachment-0001.html>

------------------------------

Message: 8
Date: Mon, 26 Feb 2018 22:59:08 +0000
From: nop head <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

Yes STL can't represent two manifolds touching but even if it could you
can't use it for multi-materials because there is no way to associate
properties. The simple solution is to use multiple STLs as I did nearly
nine years ago now
http://hydraraptor.blogspot.co.uk/2009/11/hacking-with-erik.html.

Yes STL is no good for illustrations or CAD interchange, it was only ever
intended for 3D printing.

On 26 February 2018 at 21:27, Ronaldo Persiano <[hidden email]>
wrote:

>
> I have never seen a physical solid object that isn't manifold. Surely that
>> is impossible, so if everything you can 3D print is manifold why do need to
>> represent non-manifolds. They only exist mathematically, not physically.
>>
> ?
> Consider two same axis cylinders joined end to end by an union operation.
> If they have the same diameter, the union will be a longer cylinder. But if
> the top cylinder should be 3D printed with a opaque filament and the bottom
> one with a translucent one, the longer cylinder is not a good model for
> printing it. We may want a two distinct volume with a common face. That is
> not neither the union of two cylinders nor a manifold.
>
> ?I agree with you but 3D printing is not the only goal of CAD system in
> general and of OpenSCAD in special. It would be legitimate to use
> OpenSCAD for illustration, for instance. In an illustration of a car, why
> must the motor hood have a thickness instead of being just the top hood
> surface? Another non-manifold object.
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> 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/20180226/e7a312b5/attachment-0001.html>

------------------------------

Message: 9
Date: Mon, 26 Feb 2018 21:44:02 -0300
From: Ronaldo Persiano <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

>
>
> Yes STL can't represent
> ??
> two manifolds touching but even if it could you
> ??
> can't use it for multi-materials because there is no way to associate
> properties. The simple solution is to use multiple STLs as I did nearly
> nine years ago now http://hydraraptor.blogspot.co.uk/2009/11/hacking-with-
> erik.html.
>

?You are right saying that STL can't be used for multi-materials because
there is no way to associate properties. But it can represent
?
two manifolds touching. Given the STL of a cube, add two more triangles
subdividing the rectangle joining two opposed cube edges. If you want,
duplicate each of these triangles with opposed normals.

My point is: we need a model more general  than manifolds to comprise
things like multi-material 3D printing without hacked solutions. May be 3MF
is the solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180226/b7781289/attachment-0001.html>

------------------------------

Message: 10
Date: Tue, 27 Feb 2018 09:08:08 +0100
From: [hidden email]
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=US-ASCII; format=flowed

On 2018-02-26 21:29, doug moen wrote:
> 3MF is a superior alternative to AMF.

That may be so. I agree that any proprietary nature of AMF is another
argument against it.

I had a very quick glance at the 3MF specs. The PDF is 50+ pages and
talks about many non-trivial aspects unrelated to the model itself.
Although it seems well documented, it does not quite meet my simplicity
requirement (#4). It is also XML based. I really like XML, but it means
it will not be super fast, and not compact.

There are very odd requirements in 3MF that the model must be in the
positive octant of the coordinate space. This tells me the format is not
generally intended for data exchange between application (failing my
#1), but probably intended specifically for 3d printers. So it isn't
what I had in mind.

> * It is less ambiguous, due to explicit rules on how to interpret
> certain non-manifold models that AMF leaves undefined. Specifically,
> it allows self intersection and overlapping triangles.

Ok, I will be blunt and say this is likely to kill it as a useful format
for exchange. It will cause problems. Consider implementing a 3MF
importer in OpenSCAD.

> Here's one
> reason why this is important. The union operation is not closed with
> respect to manifold meshes. If you union two manifold meshes, the
> result may not be manifold.

union() {
    cube(100);
    translate([100,100,0])cube(100);
}

The above example will typically result in a model which is explicitly
not allowed in 3MF, unless you duplicate the common edge.

https://3mf.io/wp-content/uploads/2017/10/3MF_Core_Spec_v1.2_28129.pdf
page 28

> * 3MF is an open standard, and AMF is not (you have to pay money for a
> copy of the AMF standard, and you can't redistribute your copy of this
> secret, proprietary information.)

Good point.

> OpenSCAD has a 3MF implementation underway:
> https://github.com/openscad/openscad/pull/1802.

That's interesting.

> I feel it is not productive or useful at this point to design yet
> another mesh file format.

My feeling is that if 3MF is the alternative, then STL will continue to
dominate due to its inertia. I may draft an alternative if nobody else
is interested. It will be either successful or ignored, so no harm done
:-) I guess 3MF will be useful for its purpose, but in my opinion there
should be a simpler and more compact alternative, and it isn't today's
STL.


Carsten Arnholm



------------------------------

Message: 11
Date: Tue, 27 Feb 2018 08:30:18 +0000
From: Gadgetmind <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>, nop head
<[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 26/02/18 22:59, nop head wrote:
> The simple solution is to use multiple STLs

I was musing on this recently.

I wanted to print a triangular prism on its side (toblerone!) with the
top flattened and a V notch then cut in this to let me stand a thin
object in it.

It wouldn't need any infill other than where the flat/notch on the top
was. I can design an object that's all the outside faces (with
thickness) and a support designed in, but would it actually work? Would
OpenSCAD cope/barf and would a slicer be happy with an object with
interior voids?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180227/fdeaad16/attachment-0001.html>

------------------------------

Message: 12
Date: Tue, 27 Feb 2018 08:58:55 +0000
From: nop head <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

> I really like XML, but it means it will not be super fast, and not
compact.

IIRC 3ML has a zip wrapper to make the XML compact. It won't be supper fast
though but compared to OpenSCAD rendering and slicer execution time, not to
mention 3D printing time, I doubt speed will be an issue.

On 27 February 2018 at 08:08, <[hidden email]> wrote:

> On 2018-02-26 21:29, doug moen wrote:
>
>> 3MF is a superior alternative to AMF.
>>
>
> That may be so. I agree that any proprietary nature of AMF is another
> argument against it.
>
> I had a very quick glance at the 3MF specs. The PDF is 50+ pages and talks
> about many non-trivial aspects unrelated to the model itself. Although it
> seems well documented, it does not quite meet my simplicity requirement
> (#4). It is also XML based. I really like XML, but it means it will not be
> super fast, and not compact.
>
> There are very odd requirements in 3MF that the model must be in the
> positive octant of the coordinate space. This tells me the format is not
> generally intended for data exchange between application (failing my #1),
> but probably intended specifically for 3d printers. So it isn't what I had
> in mind.
>
> * It is less ambiguous, due to explicit rules on how to interpret
>> certain non-manifold models that AMF leaves undefined. Specifically,
>> it allows self intersection and overlapping triangles.
>>
>
> Ok, I will be blunt and say this is likely to kill it as a useful format
> for exchange. It will cause problems. Consider implementing a 3MF importer
> in OpenSCAD.
>
> Here's one
>> reason why this is important. The union operation is not closed with
>> respect to manifold meshes. If you union two manifold meshes, the
>> result may not be manifold.
>>
>
> union() {
>    cube(100);
>    translate([100,100,0])cube(100);
> }
>
> The above example will typically result in a model which is explicitly not
> allowed in 3MF, unless you duplicate the common edge.
>
> https://3mf.io/wp-content/uploads/2017/10/3MF_Core_Spec_v1.2_28129.pdf
> page 28
>
> * 3MF is an open standard, and AMF is not (you have to pay money for a
>> copy of the AMF standard, and you can't redistribute your copy of this
>> secret, proprietary information.)
>>
>
> Good point.
>
> OpenSCAD has a 3MF implementation underway:
>> https://github.com/openscad/openscad/pull/1802.
>>
>
> That's interesting.
>
> I feel it is not productive or useful at this point to design yet
>> another mesh file format.
>>
>
> My feeling is that if 3MF is the alternative, then STL will continue to
> dominate due to its inertia. I may draft an alternative if nobody else is
> interested. It will be either successful or ignored, so no harm done :-) I
> guess 3MF will be useful for its purpose, but in my opinion there should be
> a simpler and more compact alternative, and it isn't today's STL.
>
>
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> 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/20180227/ca80ce47/attachment-0001.html>

------------------------------

Message: 13
Date: Tue, 27 Feb 2018 22:44:58 +1300
From: Mark Schafer <[hidden email]>
To: [hidden email]
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="us-ascii"

An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180227/95eb53a9/attachment-0001.html>

------------------------------

Message: 14
Date: Tue, 27 Feb 2018 13:43:19 +0100
From: Rogier Wolff <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=us-ascii

On Tue, Feb 27, 2018 at 08:30:18AM +0000, Gadgetmind wrote:

> On 26/02/18 22:59, nop head wrote:
> >The simple solution is to use multiple STLs
>
> I was musing on this recently.
>
> I wanted to print a triangular prism on its side (toblerone!) with
> the top flattened and a V notch then cut in this to let me stand a
> thin object in it.
>
> It wouldn't need any infill other than where the flat/notch on the
> top was. I can design an object that's all the outside faces (with
> thickness) and a support designed in, but would it actually work?
> Would OpenSCAD cope/barf and would a slicer be happy with an object
> with interior voids?

I tried doing what you proposed in a few minutes, but hte version with
"support designed in" was too difficult for me in a few minutes. But I'm
pretty sure it would work.

The "standard" way to quickly get such supports is to make it a wall
instead.


v=0; // use v=1 to be able to see the cutout stick out.


module tob1()
{
  difference () {
    translate ([100,0,0]) rotate ([0,-90,0]) cylinder (d=20,h=100,$fn=3);
    // toblerone, on it side, where I want it.
 
    translate ([-1,-5,7]) cube ([110,10,10]);
    // flattened

    scale ([1,.1,1]) translate ([-1,0,5]) rotate ([0,90,0]) cylinder (d=10,h=102,$fn=3);
    // with a V-notch.
  }
}

module tob2()
{
  difference () {
    tob1 ();
   
#    translate ([1-2*v,-0.050,-4.5]) cube ([98+4*v,.10,5.4]) ;
  }
}

tob2();


--
** [hidden email] ** 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.



------------------------------

Message: 15
Date: Tue, 27 Feb 2018 06:45:45 -0800
From: Jordan Brown <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: [OpenSCAD] Why are manifolds important?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

One of the things that has puzzled me is the requirement that objects
for 3D printing be manifold.

First, I should note that I'm not strong on the math involved and so I'm
not *absolutely* sure what "manifold" means.

I understand that it's bad for objects to be self-intersecting.? A
self-intersecting object ... isn't exactly an object at all, and has no
translation to physical reality.? Well, except maybe through implicitly
unioning.? And, absent "polyhedra" and "polygons" that aren't polyhedra
or polygons, is there any way to get self-intersecting objects in OpenSCAD?

But I don't understand the requirement to avoid shared edges.

    cube(1);
    translate([1,1,0]) cube(1);

Why is this a problem?? Yeah, it's got a piece that's zero thickness
right along where the two cubes touch, but that doesn't seem any harder
than having it be infinitesimal.? It's more or less obvious what I mean,
so why should I have to worry about it?? Why should I have to keep
nudging objects around so that they don't touch, when in the physical
reality that I'm trying to model they *do* touch?

(And if you ask "should the slicer put a filament between the two
cubes", my answer is "I don't care".? If I wanted them to be separate
objects I would have kept them separate, and if I wanted them to be
solidly joined I would have made them solidly joined.? Again, this seems
like an extreme case of a piece of an object that is much smaller than
the extrusion width or thickness, or two objects that mathematically
don't touch but are separated by less than the printer resolution.)

Is it all about making unambiguous sense out of polygon soup?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180227/417922ec/attachment-0001.html>

------------------------------

Message: 16
Date: Tue, 27 Feb 2018 10:40:37 -0500
From: doug moen <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

Carsten:

A 3MF file can contain multiple objects. Each object has a mesh and a
material ID. This is how multi-extruder, multi-material 3D prints are
supported. You define one object for each material or colour. There is no
problem if two objects share faces. That's normal for a multi-material
print.

Within an object, a mesh is defined as an array of vertices (each vertex
has an integer index) and an array of triangles (each triangle has 3 vertex
indices).

It is legal to have two vertices with the same (x,y,z) coordinates, but
different indices.

In section 4.1, the standard says:
  "Manifold Edges: Every triangle edge in the mesh shares common vertex
endpoints with the edge of exactly 1 other triangle."

But, in this sentence, the meaning of two vertices being the same is that
they have the same index, not that they have the same (x,y,z) coordinates.
So 3MF is not a triangle soup format like STL, and a manifold mesh in 3MF
can represent a larger set of shapes than a manifold mesh in STL.

In section 4.1.3, the standard says:
  "The vertices element contains all the <vertex> elements for this object.
The vertices represent the corners of each triangle in the mesh. The order
of these elements defines an implicit 0-based index that is referenced by
other elements, such as the <triangle> element. The producer SHOULD NOT
include duplicate vertices unless coalescing duplicates would create
non-manifold edges."

On 27 February 2018 at 03:08, <[hidden email]> wrote:

> On 2018-02-26 21:29, doug moen wrote:
>
>> 3MF is a superior alternative to AMF.
>>
>
> That may be so. I agree that any proprietary nature of AMF is another
> argument against it.
>
> I had a very quick glance at the 3MF specs. The PDF is 50+ pages and talks
> about many non-trivial aspects unrelated to the model itself. Although it
> seems well documented, it does not quite meet my simplicity requirement
> (#4). It is also XML based. I really like XML, but it means it will not be
> super fast, and not compact.
>
> There are very odd requirements in 3MF that the model must be in the
> positive octant of the coordinate space. This tells me the format is not
> generally intended for data exchange between application (failing my #1),
> but probably intended specifically for 3d printers. So it isn't what I had
> in mind.
>
> * It is less ambiguous, due to explicit rules on how to interpret
>> certain non-manifold models that AMF leaves undefined. Specifically,
>> it allows self intersection and overlapping triangles.
>>
>
> Ok, I will be blunt and say this is likely to kill it as a useful format
> for exchange. It will cause problems. Consider implementing a 3MF importer
> in OpenSCAD.
>
> Here's one
>> reason why this is important. The union operation is not closed with
>> respect to manifold meshes. If you union two manifold meshes, the
>> result may not be manifold.
>>
>
> union() {
>    cube(100);
>    translate([100,100,0])cube(100);
> }
>
> The above example will typically result in a model which is explicitly not
> allowed in 3MF, unless you duplicate the common edge.
>
> https://3mf.io/wp-content/uploads/2017/10/3MF_Core_Spec_v1.2_28129.pdf
> page 28
>
> * 3MF is an open standard, and AMF is not (you have to pay money for a
>> copy of the AMF standard, and you can't redistribute your copy of this
>> secret, proprietary information.)
>>
>
> Good point.
>
> OpenSCAD has a 3MF implementation underway:
>> https://github.com/openscad/openscad/pull/1802.
>>
>
> That's interesting.
>
> I feel it is not productive or useful at this point to design yet
>> another mesh file format.
>>
>
> My feeling is that if 3MF is the alternative, then STL will continue to
> dominate due to its inertia. I may draft an alternative if nobody else is
> interested. It will be either successful or ignored, so no harm done :-) I
> guess 3MF will be useful for its purpose, but in my opinion there should be
> a simpler and more compact alternative, and it isn't today's STL.
>
>
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> 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/20180227/1cafb99d/attachment-0001.html>

------------------------------

Message: 17
Date: Tue, 27 Feb 2018 16:28:45 +0000
From: nop head <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] Why are manifolds important?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

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 <[hidden email]>
wrote:

> One of the things that has puzzled me is the requirement that objects for
> 3D printing be manifold.
>
> First, I should note that I'm not strong on the math involved and so I'm
> not *absolutely* sure what "manifold" means.
>
> I understand that it's bad for objects to be self-intersecting.  A
> self-intersecting object ... isn't exactly an object at all, and has no
> translation to physical reality.  Well, except maybe through implicitly
> unioning.  And, absent "polyhedra" and "polygons" that aren't polyhedra or
> polygons, is there any way to get self-intersecting objects in OpenSCAD?
>
> But I don't understand the requirement to avoid shared edges.
>
> cube(1);
> translate([1,1,0]) cube(1);
>
> Why is this a problem?  Yeah, it's got a piece that's zero thickness right
> along where the two cubes touch, but that doesn't seem any harder than
> having it be infinitesimal.  It's more or less obvious what I mean, so why
> should I have to worry about it?  Why should I have to keep nudging objects
> around so that they don't touch, when in the physical reality that I'm
> trying to model they *do* touch?
>
> (And if you ask "should the slicer put a filament between the two cubes",
> my answer is "I don't care".  If I wanted them to be separate objects I
> would have kept them separate, and if I wanted them to be solidly joined I
> would have made them solidly joined.  Again, this seems like an extreme
> case of a piece of an object that is much smaller than the extrusion width
> or thickness, or two objects that mathematically don't touch but are
> separated by less than the printer resolution.)
>
> Is it all about making unambiguous sense out of polygon soup?
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> 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/20180227/3672d2ca/attachment-0001.html>

------------------------------

Subject: Digest Footer

_______________________________________________
Discuss mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


------------------------------

End of Discuss Digest, Vol 39, Issue 27
***************************************

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Manifolds and sharing edges/faces

nophead
If two cubes share a face then the can be unioned and the result is manifold. What they can't do is share a single edge or a single vertex.

On 27 February 2018 at 17:25, jim.klessig <[hidden email]> wrote:
Someone wrote 

"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. "

To my mind, that is only true if you DEFINE "reality" as not having conjoined faces. 
IF you allow for "reality" to have conjoined faces, then you will find them every where. A block of 1*1*2 is in "reality" two  1*1*1 cubes with a common face. 

Why should "overlap be a requirement of them being "joined"? If any thing I would think "overlap" should be the "forbidden concept". That is the thing you can not actually realize in the real world.



Sent from my U.S. Cellular® Smartphone

-------- Original message --------
Date: 2/27/18 9:00 AM (GMT-08:00)
Subject: Discuss Digest, Vol 39, Issue 27

Send Discuss mailing list submissions to
[hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
or, via email, send a message with subject or body 'help' to
[hidden email]

You can reach the person managing the list at
[hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss digest..."


Today's Topics:

   1. Re: damaged STL file? (Jordan Brown)
   2. Re: damaged STL file? (Carsten Arnholm)
   3. Re: damaged STL file? (nop head)
   4. Re: damaged STL file? (doug moen)
   5. Re: damaged STL file? (Ronaldo Persiano)
   6. Re: damaged STL file? (nop head)
   7. Re: damaged STL file? (Ronaldo Persiano)
   8. Re: damaged STL file? (nop head)
   9. Re: damaged STL file? (Ronaldo Persiano)
  10. Re: damaged STL file? ([hidden email])
  11. Re: damaged STL file? (Gadgetmind)
  12. Re: damaged STL file? (nop head)
  13. Re: damaged STL file? (Mark Schafer)
  14. Re: damaged STL file? (Rogier Wolff)
  15. Why are manifolds important? (Jordan Brown)
  16. Re: damaged STL file? (doug moen)
  17. Re: Why are manifolds important? (nop head)


----------------------------------------------------------------------

Message: 1
Date: Mon, 26 Feb 2018 09:35:32 -0800
From: Jordan Brown <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>,
[hidden email]
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

On 2/26/2018 7:41 AM, [hidden email] wrote:
> In general I think the thread illustrates the somewhat fuzzy nature of
> repairing problematic polyhedra in general and STL files in particular
> (STLs do not provide any topology, it must be guessed). Several repair
> tools exist but they appear to make different assumptions leading to
> different results.

Are there other file formats that would be better?? Getting designers
like OpenSCAD and slicers to *both* implement something new would be
tough, but if there are clear benefits maybe it could be done.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180226/830a8339/attachment-0001.html>

------------------------------

Message: 2
Date: Mon, 26 Feb 2018 20:44:57 +0100
From: Carsten Arnholm <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8; format=flowed

On 26. feb. 2018 18:35, Jordan Brown wrote:
> Are there other file formats that would be better?? Getting designers
> like OpenSCAD and slicers to *both* implement something new would be
> tough, but if there are clear benefits maybe it could be done.

Yes, there are better formats (see below), but STL seems so entrenched
that it is very hard to get wide enough support for anything else. Some
requirements to a non-STL format I guess would be

1) Suited for polyhedron exchange between CAD applications, not just CAD
to slicers.

2) Unambiguous format, with explicit topology

3) Efficient binary storage, plus equivalent ascii text version with
same info. Binary/Ascii should be transparent to users.

4) It must be *very* simple.

etc.

OpenSCAD already support other 3D formats in addition to STL

OFF - http://paulbourke.net/dataformats/off/
AMF - https://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format

Both of the above satisfy 1) and 2). AMF in its simplest form is quite
nice, but not terribly efficient, plus in my opinion it forgets 4) so it
will never become universal. OFF is a nice contender, but it does not
seem to be simple enough to be popular.

STL is both wasteful and ambiguous, it is just a sea of free floating
triangles. The binary format does not contain the same info as the text
format, etc. Its popularity is due to history only.

It seems to me super simplicity is a key. So any alternative format
should be even simpler than STL. Given that existing alternatives are
not very popular, we might as well propose something new to compete,
making simplicity the key feature while fixing some of the STL issues.
In my mind it could be something like

* simple file header to identify ASCII/Binary
* vertex coordinates stored only once
* triangle faces only
* faces defined by references to vertices, implicit normals

In other words, just the bare minimum, equivalent to the info that goes
into OpenSCAD polyhedron command. The text format would be more compact
than STL and simpler to read. The binary format would also be more
compact than STL since coordinates would be mentioned only once, and
therefore also not have any issues with interpretation.

You could say it is far too simple. But if you want it to be widely
adopted it must be extremely simple and fast. We could call it STL2 and
say it is how STL should have been defined in 1985 or so :-)

I don't have any illusions it would be successful, but if it was adopted
I think it would be helpful in avoiding some of the "damaged STL" issues
(not all) and enable easier sharing of models between various applications.

Just my thoughts, nothing else.

Carsten Arnholm



------------------------------

Message: 3
Date: Mon, 26 Feb 2018 20:00:48 +0000
From: nop head <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<CAEEmnrPb=[hidden email]>
Content-Type: text/plain; charset="utf-8"

STL is unambiguous if it is written correctly and only used to represent a
manifold model with no self intersections. That is sufficient for 3D
printing as all 3D printed objects are manifold.

While other representations can also represent non-manifold objects it
pushes the problem downstream. How do you print a non-manifold object?



On 26 February 2018 at 19:44, Carsten Arnholm <[hidden email]> wrote:

> On 26. feb. 2018 18:35, Jordan Brown wrote:
>
>> Are there other file formats that would be better?  Getting designers
>> like OpenSCAD and slicers to *both* implement something new would be tough,
>> but if there are clear benefits maybe it could be done.
>>
>
> Yes, there are better formats (see below), but STL seems so entrenched
> that it is very hard to get wide enough support for anything else. Some
> requirements to a non-STL format I guess would be
>
> 1) Suited for polyhedron exchange between CAD applications, not just CAD
> to slicers.
>
> 2) Unambiguous format, with explicit topology
>
> 3) Efficient binary storage, plus equivalent ascii text version with same
> info. Binary/Ascii should be transparent to users.
>
> 4) It must be *very* simple.
>
> etc.
>
> OpenSCAD already support other 3D formats in addition to STL
>
> OFF - http://paulbourke.net/dataformats/off/
> AMF - https://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format
>
> Both of the above satisfy 1) and 2). AMF in its simplest form is quite
> nice, but not terribly efficient, plus in my opinion it forgets 4) so it
> will never become universal. OFF is a nice contender, but it does not seem
> to be simple enough to be popular.
>
> STL is both wasteful and ambiguous, it is just a sea of free floating
> triangles. The binary format does not contain the same info as the text
> format, etc. Its popularity is due to history only.
>
> It seems to me super simplicity is a key. So any alternative format should
> be even simpler than STL. Given that existing alternatives are not very
> popular, we might as well propose something new to compete, making
> simplicity the key feature while fixing some of the STL issues. In my mind
> it could be something like
>
> * simple file header to identify ASCII/Binary
> * vertex coordinates stored only once
> * triangle faces only
> * faces defined by references to vertices, implicit normals
>
> In other words, just the bare minimum, equivalent to the info that goes
> into OpenSCAD polyhedron command. The text format would be more compact
> than STL and simpler to read. The binary format would also be more compact
> than STL since coordinates would be mentioned only once, and therefore also
> not have any issues with interpretation.
>
> You could say it is far too simple. But if you want it to be widely
> adopted it must be extremely simple and fast. We could call it STL2 and say
> it is how STL should have been defined in 1985 or so :-)
>
> I don't have any illusions it would be successful, but if it was adopted I
> think it would be helpful in avoiding some of the "damaged STL" issues (not
> all) and enable easier sharing of models between various applications.
>
> Just my thoughts, nothing else.
>
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> 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/20180226/225993fd/attachment-0001.html>

------------------------------

Message: 4
Date: Mon, 26 Feb 2018 15:29:48 -0500
From: doug moen <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

3MF is a superior alternative to AMF.
* It is less ambiguous, due to explicit rules on how to interpret certain
non-manifold models that AMF leaves undefined. Specifically, it allows self
intersection and overlapping triangles. Here's one reason why this is
important. The union operation is not closed with respect to manifold
meshes. If you union two manifold meshes, the result may not be manifold. I
feel this is actually a defect in the definition of "manifold", because I
think it's intolerable if you can't union two arbitrary shapes and be
guaranteed to get a meaningful result. In any case, 3MF fixes this by
defining the result of the union of two manifold meshes to be a valid 3MF
model in all cases. AMF does not do this.
* 3MF is an open standard, and AMF is not (you have to pay money for a copy
of the AMF standard, and you can't redistribute your copy of this secret,
proprietary information.)
* 3MF has an open source library on github which interprets the standard.
* Nop head asks "how do you print a non-manifold object?". Well, the 3MF
standard and the associated library implementation gives some unambiguous
answers to that, for the cases that I mention above.

OpenSCAD has a 3MF implementation underway:
https://github.com/openscad/openscad/pull/1802.

The Cura slicer used to have an AMF implementation, but got rid of it, and
they now implement 3MF instead.

I feel it is not productive or useful at this point to design yet another
mesh file format.

On 26 February 2018 at 14:44, Carsten Arnholm <[hidden email]> wrote:

> On 26. feb. 2018 18:35, Jordan Brown wrote:
>
>> Are there other file formats that would be better?  Getting designers
>> like OpenSCAD and slicers to *both* implement something new would be tough,
>> but if there are clear benefits maybe it could be done.
>>
>
> Yes, there are better formats (see below), but STL seems so entrenched
> that it is very hard to get wide enough support for anything else. Some
> requirements to a non-STL format I guess would be
>
> 1) Suited for polyhedron exchange between CAD applications, not just CAD
> to slicers.
>
> 2) Unambiguous format, with explicit topology
>
> 3) Efficient binary storage, plus equivalent ascii text version with same
> info. Binary/Ascii should be transparent to users.
>
> 4) It must be *very* simple.
>
> etc.
>
> OpenSCAD already support other 3D formats in addition to STL
>
> OFF - http://paulbourke.net/dataformats/off/
> AMF - https://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format
>
> Both of the above satisfy 1) and 2). AMF in its simplest form is quite
> nice, but not terribly efficient, plus in my opinion it forgets 4) so it
> will never become universal. OFF is a nice contender, but it does not seem
> to be simple enough to be popular.
>
> STL is both wasteful and ambiguous, it is just a sea of free floating
> triangles. The binary format does not contain the same info as the text
> format, etc. Its popularity is due to history only.
>
> It seems to me super simplicity is a key. So any alternative format should
> be even simpler than STL. Given that existing alternatives are not very
> popular, we might as well propose something new to compete, making
> simplicity the key feature while fixing some of the STL issues. In my mind
> it could be something like
>
> * simple file header to identify ASCII/Binary
> * vertex coordinates stored only once
> * triangle faces only
> * faces defined by references to vertices, implicit normals
>
> In other words, just the bare minimum, equivalent to the info that goes
> into OpenSCAD polyhedron command. The text format would be more compact
> than STL and simpler to read. The binary format would also be more compact
> than STL since coordinates would be mentioned only once, and therefore also
> not have any issues with interpretation.
>
> You could say it is far too simple. But if you want it to be widely
> adopted it must be extremely simple and fast. We could call it STL2 and say
> it is how STL should have been defined in 1985 or so :-)
>
> I don't have any illusions it would be successful, but if it was adopted I
> think it would be helpful in avoiding some of the "damaged STL" issues (not
> all) and enable easier sharing of models between various applications.
>
> Just my thoughts, nothing else.
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> 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/20180226/cafd3473/attachment-0001.html>

------------------------------

Message: 5
Date: Mon, 26 Feb 2018 17:36:13 -0300
From: Ronaldo Persiano <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

I agree that STL is a waster format. But Arnholm four point proposal does
not assure a manifold definition neither it is more restrict than STL
format. In fact, any model expressed in a STL file may be expressed by an
OpenSCAD command whether it is a manifold or not.

Besides, with the advent of multi-material 3D print, a more general format
will be demanded representing a partition of the space in many adjacent
volumes to be filled with different materials. Although each of those
volumes might be a manifold, the whole model is not anymore.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180226/77021b5e/attachment-0001.html>

------------------------------

Message: 6
Date: Mon, 26 Feb 2018 20:46:40 +0000
From: nop head <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

I have never seen a physical solid object that isn't manifold. Surely that
is impossible, so if everything you can 3D print is manifold why do need to
represent non-manifolds. They only exist mathematically, not physically.

On 26 February 2018 at 20:36, Ronaldo Persiano <[hidden email]>
wrote:

> I agree that STL is a waster format. But Arnholm four point proposal does
> not assure a manifold definition neither it is more restrict than STL
> format. In fact, any model expressed in a STL file may be expressed by an
> OpenSCAD command whether it is a manifold or not.
>
> Besides, with the advent of multi-material 3D print, a more general format
> will be demanded representing a partition of the space in many adjacent
> volumes to be filled with different materials. Although each of those
> volumes might be a manifold, the whole model is not anymore.
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> 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/20180226/ff950978/attachment-0001.html>

------------------------------

Message: 7
Date: Mon, 26 Feb 2018 18:27:32 -0300
From: Ronaldo Persiano <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<CA+i9EaCOWiMjCOt+WvzEqJ5+E81zeQK97G9YFQ71LPEtOU+R=[hidden email]>
Content-Type: text/plain; charset="utf-8"

> I have never seen a physical solid object that isn't manifold. Surely that
> is impossible, so if everything you can 3D print is manifold why do need to
> represent non-manifolds. They only exist mathematically, not physically.
>
?
Consider two same axis cylinders joined end to end by an union operation.
If they have the same diameter, the union will be a longer cylinder. But if
the top cylinder should be 3D printed with a opaque filament and the bottom
one with a translucent one, the longer cylinder is not a good model for
printing it. We may want a two distinct volume with a common face. That is
not neither the union of two cylinders nor a manifold.

?I agree with you but 3D printing is not the only goal of CAD system in
general and of OpenSCAD in special. It would be legitimate to use OpenSCAD
for illustration, for instance. In an illustration of a car, why must the
motor hood have a thickness instead of being just the top hood surface?
Another non-manifold object.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180226/d6d1f4a3/attachment-0001.html>

------------------------------

Message: 8
Date: Mon, 26 Feb 2018 22:59:08 +0000
From: nop head <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

Yes STL can't represent two manifolds touching but even if it could you
can't use it for multi-materials because there is no way to associate
properties. The simple solution is to use multiple STLs as I did nearly
nine years ago now
http://hydraraptor.blogspot.co.uk/2009/11/hacking-with-erik.html.

Yes STL is no good for illustrations or CAD interchange, it was only ever
intended for 3D printing.

On 26 February 2018 at 21:27, Ronaldo Persiano <[hidden email]>
wrote:

>
> I have never seen a physical solid object that isn't manifold. Surely that
>> is impossible, so if everything you can 3D print is manifold why do need to
>> represent non-manifolds. They only exist mathematically, not physically.
>>
> ?
> Consider two same axis cylinders joined end to end by an union operation.
> If they have the same diameter, the union will be a longer cylinder. But if
> the top cylinder should be 3D printed with a opaque filament and the bottom
> one with a translucent one, the longer cylinder is not a good model for
> printing it. We may want a two distinct volume with a common face. That is
> not neither the union of two cylinders nor a manifold.
>
> ?I agree with you but 3D printing is not the only goal of CAD system in
> general and of OpenSCAD in special. It would be legitimate to use
> OpenSCAD for illustration, for instance. In an illustration of a car, why
> must the motor hood have a thickness instead of being just the top hood
> surface? Another non-manifold object.
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> 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/20180226/e7a312b5/attachment-0001.html>

------------------------------

Message: 9
Date: Mon, 26 Feb 2018 21:44:02 -0300
From: Ronaldo Persiano <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

>
>
> Yes STL can't represent
> ??
> two manifolds touching but even if it could you
> ??
> can't use it for multi-materials because there is no way to associate
> properties. The simple solution is to use multiple STLs as I did nearly
> nine years ago now http://hydraraptor.blogspot.co.uk/2009/11/hacking-with-
> erik.html.
>

?You are right saying that STL can't be used for multi-materials because
there is no way to associate properties. But it can represent
?
two manifolds touching. Given the STL of a cube, add two more triangles
subdividing the rectangle joining two opposed cube edges. If you want,
duplicate each of these triangles with opposed normals.

My point is: we need a model more general  than manifolds to comprise
things like multi-material 3D printing without hacked solutions. May be 3MF
is the solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180226/b7781289/attachment-0001.html>

------------------------------

Message: 10
Date: Tue, 27 Feb 2018 09:08:08 +0100
From: [hidden email]
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=US-ASCII; format=flowed

On 2018-02-26 21:29, doug moen wrote:
> 3MF is a superior alternative to AMF.

That may be so. I agree that any proprietary nature of AMF is another
argument against it.

I had a very quick glance at the 3MF specs. The PDF is 50+ pages and
talks about many non-trivial aspects unrelated to the model itself.
Although it seems well documented, it does not quite meet my simplicity
requirement (#4). It is also XML based. I really like XML, but it means
it will not be super fast, and not compact.

There are very odd requirements in 3MF that the model must be in the
positive octant of the coordinate space. This tells me the format is not
generally intended for data exchange between application (failing my
#1), but probably intended specifically for 3d printers. So it isn't
what I had in mind.

> * It is less ambiguous, due to explicit rules on how to interpret
> certain non-manifold models that AMF leaves undefined. Specifically,
> it allows self intersection and overlapping triangles.

Ok, I will be blunt and say this is likely to kill it as a useful format
for exchange. It will cause problems. Consider implementing a 3MF
importer in OpenSCAD.

> Here's one
> reason why this is important. The union operation is not closed with
> respect to manifold meshes. If you union two manifold meshes, the
> result may not be manifold.

union() {
    cube(100);
    translate([100,100,0])cube(100);
}

The above example will typically result in a model which is explicitly
not allowed in 3MF, unless you duplicate the common edge.

https://3mf.io/wp-content/uploads/2017/10/3MF_Core_Spec_v1.2_28129.pdf
page 28

> * 3MF is an open standard, and AMF is not (you have to pay money for a
> copy of the AMF standard, and you can't redistribute your copy of this
> secret, proprietary information.)

Good point.

> OpenSCAD has a 3MF implementation underway:
> https://github.com/openscad/openscad/pull/1802.

That's interesting.

> I feel it is not productive or useful at this point to design yet
> another mesh file format.

My feeling is that if 3MF is the alternative, then STL will continue to
dominate due to its inertia. I may draft an alternative if nobody else
is interested. It will be either successful or ignored, so no harm done
:-) I guess 3MF will be useful for its purpose, but in my opinion there
should be a simpler and more compact alternative, and it isn't today's
STL.


Carsten Arnholm



------------------------------

Message: 11
Date: Tue, 27 Feb 2018 08:30:18 +0000
From: Gadgetmind <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>, nop head
<[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 26/02/18 22:59, nop head wrote:
> The simple solution is to use multiple STLs

I was musing on this recently.

I wanted to print a triangular prism on its side (toblerone!) with the
top flattened and a V notch then cut in this to let me stand a thin
object in it.

It wouldn't need any infill other than where the flat/notch on the top
was. I can design an object that's all the outside faces (with
thickness) and a support designed in, but would it actually work? Would
OpenSCAD cope/barf and would a slicer be happy with an object with
interior voids?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180227/fdeaad16/attachment-0001.html>

------------------------------

Message: 12
Date: Tue, 27 Feb 2018 08:58:55 +0000
From: nop head <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

> I really like XML, but it means it will not be super fast, and not
compact.

IIRC 3ML has a zip wrapper to make the XML compact. It won't be supper fast
though but compared to OpenSCAD rendering and slicer execution time, not to
mention 3D printing time, I doubt speed will be an issue.

On 27 February 2018 at 08:08, <[hidden email]> wrote:

> On 2018-02-26 21:29, doug moen wrote:
>
>> 3MF is a superior alternative to AMF.
>>
>
> That may be so. I agree that any proprietary nature of AMF is another
> argument against it.
>
> I had a very quick glance at the 3MF specs. The PDF is 50+ pages and talks
> about many non-trivial aspects unrelated to the model itself. Although it
> seems well documented, it does not quite meet my simplicity requirement
> (#4). It is also XML based. I really like XML, but it means it will not be
> super fast, and not compact.
>
> There are very odd requirements in 3MF that the model must be in the
> positive octant of the coordinate space. This tells me the format is not
> generally intended for data exchange between application (failing my #1),
> but probably intended specifically for 3d printers. So it isn't what I had
> in mind.
>
> * It is less ambiguous, due to explicit rules on how to interpret
>> certain non-manifold models that AMF leaves undefined. Specifically,
>> it allows self intersection and overlapping triangles.
>>
>
> Ok, I will be blunt and say this is likely to kill it as a useful format
> for exchange. It will cause problems. Consider implementing a 3MF importer
> in OpenSCAD.
>
> Here's one
>> reason why this is important. The union operation is not closed with
>> respect to manifold meshes. If you union two manifold meshes, the
>> result may not be manifold.
>>
>
> union() {
>    cube(100);
>    translate([100,100,0])cube(100);
> }
>
> The above example will typically result in a model which is explicitly not
> allowed in 3MF, unless you duplicate the common edge.
>
> https://3mf.io/wp-content/uploads/2017/10/3MF_Core_Spec_v1.2_28129.pdf
> page 28
>
> * 3MF is an open standard, and AMF is not (you have to pay money for a
>> copy of the AMF standard, and you can't redistribute your copy of this
>> secret, proprietary information.)
>>
>
> Good point.
>
> OpenSCAD has a 3MF implementation underway:
>> https://github.com/openscad/openscad/pull/1802.
>>
>
> That's interesting.
>
> I feel it is not productive or useful at this point to design yet
>> another mesh file format.
>>
>
> My feeling is that if 3MF is the alternative, then STL will continue to
> dominate due to its inertia. I may draft an alternative if nobody else is
> interested. It will be either successful or ignored, so no harm done :-) I
> guess 3MF will be useful for its purpose, but in my opinion there should be
> a simpler and more compact alternative, and it isn't today's STL.
>
>
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> 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/20180227/ca80ce47/attachment-0001.html>

------------------------------

Message: 13
Date: Tue, 27 Feb 2018 22:44:58 +1300
From: Mark Schafer <[hidden email]>
To: [hidden email]
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="us-ascii"

An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180227/95eb53a9/attachment-0001.html>

------------------------------

Message: 14
Date: Tue, 27 Feb 2018 13:43:19 +0100
From: Rogier Wolff <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID: <20180227124319.GO4755@BitWizard.nl>
Content-Type: text/plain; charset=us-ascii

On Tue, Feb 27, 2018 at 08:30:18AM +0000, Gadgetmind wrote:

> On 26/02/18 22:59, nop head wrote:
> >The simple solution is to use multiple STLs
>
> I was musing on this recently.
>
> I wanted to print a triangular prism on its side (toblerone!) with
> the top flattened and a V notch then cut in this to let me stand a
> thin object in it.
>
> It wouldn't need any infill other than where the flat/notch on the
> top was. I can design an object that's all the outside faces (with
> thickness) and a support designed in, but would it actually work?
> Would OpenSCAD cope/barf and would a slicer be happy with an object
> with interior voids?

I tried doing what you proposed in a few minutes, but hte version with
"support designed in" was too difficult for me in a few minutes. But I'm
pretty sure it would work.

The "standard" way to quickly get such supports is to make it a wall
instead.


v=0; // use v=1 to be able to see the cutout stick out.


module tob1()
{
  difference () {
    translate ([100,0,0]) rotate ([0,-90,0]) cylinder (d=20,h=100,$fn=3);
    // toblerone, on it side, where I want it.
 
    translate ([-1,-5,7]) cube ([110,10,10]);
    // flattened

    scale ([1,.1,1]) translate ([-1,0,5]) rotate ([0,90,0]) cylinder (d=10,h=102,$fn=3);
    // with a V-notch.
  }
}

module tob2()
{
  difference () {
    tob1 ();
   
#    translate ([1-2*v,-0.050,-4.5]) cube ([98+4*v,.10,5.4]) ;
  }
}

tob2();


--
** [hidden email] ** http://www.BitWizard.nl/ ** <a href="tel:+31%2015%20260%200998" value="+31152600998" target="_blank">+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.



------------------------------

Message: 15
Date: Tue, 27 Feb 2018 06:45:45 -0800
From: Jordan Brown <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: [OpenSCAD] Why are manifolds important?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

One of the things that has puzzled me is the requirement that objects
for 3D printing be manifold.

First, I should note that I'm not strong on the math involved and so I'm
not *absolutely* sure what "manifold" means.

I understand that it's bad for objects to be self-intersecting.? A
self-intersecting object ... isn't exactly an object at all, and has no
translation to physical reality.? Well, except maybe through implicitly
unioning.? And, absent "polyhedra" and "polygons" that aren't polyhedra
or polygons, is there any way to get self-intersecting objects in OpenSCAD?

But I don't understand the requirement to avoid shared edges.

    cube(1);
    translate([1,1,0]) cube(1);

Why is this a problem?? Yeah, it's got a piece that's zero thickness
right along where the two cubes touch, but that doesn't seem any harder
than having it be infinitesimal.? It's more or less obvious what I mean,
so why should I have to worry about it?? Why should I have to keep
nudging objects around so that they don't touch, when in the physical
reality that I'm trying to model they *do* touch?

(And if you ask "should the slicer put a filament between the two
cubes", my answer is "I don't care".? If I wanted them to be separate
objects I would have kept them separate, and if I wanted them to be
solidly joined I would have made them solidly joined.? Again, this seems
like an extreme case of a piece of an object that is much smaller than
the extrusion width or thickness, or two objects that mathematically
don't touch but are separated by less than the printer resolution.)

Is it all about making unambiguous sense out of polygon soup?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180227/417922ec/attachment-0001.html>

------------------------------

Message: 16
Date: Tue, 27 Feb 2018 10:40:37 -0500
From: doug moen <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

Carsten:

A 3MF file can contain multiple objects. Each object has a mesh and a
material ID. This is how multi-extruder, multi-material 3D prints are
supported. You define one object for each material or colour. There is no
problem if two objects share faces. That's normal for a multi-material
print.

Within an object, a mesh is defined as an array of vertices (each vertex
has an integer index) and an array of triangles (each triangle has 3 vertex
indices).

It is legal to have two vertices with the same (x,y,z) coordinates, but
different indices.

In section 4.1, the standard says:
  "Manifold Edges: Every triangle edge in the mesh shares common vertex
endpoints with the edge of exactly 1 other triangle."

But, in this sentence, the meaning of two vertices being the same is that
they have the same index, not that they have the same (x,y,z) coordinates.
So 3MF is not a triangle soup format like STL, and a manifold mesh in 3MF
can represent a larger set of shapes than a manifold mesh in STL.

In section 4.1.3, the standard says:
  "The vertices element contains all the <vertex> elements for this object.
The vertices represent the corners of each triangle in the mesh. The order
of these elements defines an implicit 0-based index that is referenced by
other elements, such as the <triangle> element. The producer SHOULD NOT
include duplicate vertices unless coalescing duplicates would create
non-manifold edges."

On 27 February 2018 at 03:08, <[hidden email]> wrote:

> On 2018-02-26 21:29, doug moen wrote:
>
>> 3MF is a superior alternative to AMF.
>>
>
> That may be so. I agree that any proprietary nature of AMF is another
> argument against it.
>
> I had a very quick glance at the 3MF specs. The PDF is 50+ pages and talks
> about many non-trivial aspects unrelated to the model itself. Although it
> seems well documented, it does not quite meet my simplicity requirement
> (#4). It is also XML based. I really like XML, but it means it will not be
> super fast, and not compact.
>
> There are very odd requirements in 3MF that the model must be in the
> positive octant of the coordinate space. This tells me the format is not
> generally intended for data exchange between application (failing my #1),
> but probably intended specifically for 3d printers. So it isn't what I had
> in mind.
>
> * It is less ambiguous, due to explicit rules on how to interpret
>> certain non-manifold models that AMF leaves undefined. Specifically,
>> it allows self intersection and overlapping triangles.
>>
>
> Ok, I will be blunt and say this is likely to kill it as a useful format
> for exchange. It will cause problems. Consider implementing a 3MF importer
> in OpenSCAD.
>
> Here's one
>> reason why this is important. The union operation is not closed with
>> respect to manifold meshes. If you union two manifold meshes, the
>> result may not be manifold.
>>
>
> union() {
>    cube(100);
>    translate([100,100,0])cube(100);
> }
>
> The above example will typically result in a model which is explicitly not
> allowed in 3MF, unless you duplicate the common edge.
>
> https://3mf.io/wp-content/uploads/2017/10/3MF_Core_Spec_v1.2_28129.pdf
> page 28
>
> * 3MF is an open standard, and AMF is not (you have to pay money for a
>> copy of the AMF standard, and you can't redistribute your copy of this
>> secret, proprietary information.)
>>
>
> Good point.
>
> OpenSCAD has a 3MF implementation underway:
>> https://github.com/openscad/openscad/pull/1802.
>>
>
> That's interesting.
>
> I feel it is not productive or useful at this point to design yet
>> another mesh file format.
>>
>
> My feeling is that if 3MF is the alternative, then STL will continue to
> dominate due to its inertia. I may draft an alternative if nobody else is
> interested. It will be either successful or ignored, so no harm done :-) I
> guess 3MF will be useful for its purpose, but in my opinion there should be
> a simpler and more compact alternative, and it isn't today's STL.
>
>
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> 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/20180227/1cafb99d/attachment-0001.html>

------------------------------

Message: 17
Date: Tue, 27 Feb 2018 16:28:45 +0000
From: nop head <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] Why are manifolds important?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

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 <[hidden email]>
wrote:

> One of the things that has puzzled me is the requirement that objects for
> 3D printing be manifold.
>
> First, I should note that I'm not strong on the math involved and so I'm
> not *absolutely* sure what "manifold" means.
>
> I understand that it's bad for objects to be self-intersecting.  A
> self-intersecting object ... isn't exactly an object at all, and has no
> translation to physical reality.  Well, except maybe through implicitly
> unioning.  And, absent "polyhedra" and "polygons" that aren't polyhedra or
> polygons, is there any way to get self-intersecting objects in OpenSCAD?
>
> But I don't understand the requirement to avoid shared edges.
>
> cube(1);
> translate([1,1,0]) cube(1);
>
> Why is this a problem?  Yeah, it's got a piece that's zero thickness right
> along where the two cubes touch, but that doesn't seem any harder than
> having it be infinitesimal.  It's more or less obvious what I mean, so why
> should I have to worry about it?  Why should I have to keep nudging objects
> around so that they don't touch, when in the physical reality that I'm
> trying to model they *do* touch?
>
> (And if you ask "should the slicer put a filament between the two cubes",
> my answer is "I don't care".  If I wanted them to be separate objects I
> would have kept them separate, and if I wanted them to be solidly joined I
> would have made them solidly joined.  Again, this seems like an extreme
> case of a piece of an object that is much smaller than the extrusion width
> or thickness, or two objects that mathematically don't touch but are
> separated by less than the printer resolution.)
>
> Is it all about making unambiguous sense out of polygon soup?
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> 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/20180227/3672d2ca/attachment-0001.html>

------------------------------

Subject: Digest Footer

_______________________________________________
Discuss mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


------------------------------

End of Discuss Digest, Vol 39, Issue 27
***************************************

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Manifolds and sharing edges/faces

doug.moen
I think it is useful to note that this restriction that "two cubes can't share a single edge or single vertex" exists in the 2-manifold STL representation of a mesh. However, 3MF meshes don't have this restriction. And the CGAL "Nef polyhedron" mesh data structure (used to implement union and intersection in OpenSCAD) doesn't have this restriction. So it's technically possible to keep your meshes in a data structure that doesn't have this restriction, all the way from construction, through boolean operations, through export to 3MF and import into your slicer.

The difference is that in the "manifold STL" version of reality, the following is an illegal operation:

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

But in the CGAL Nef polyhedron/3MF version of reality, this is perfectly legal.

Currently, for this model, OpenSCAD produces a warning message:
   

WARNING: Object may not be a valid 2-manifold and may need repair!


Actually, this warning is needed for STL export, but not for 3MF export.


On 27 February 2018 at 12:33, nop head <[hidden email]> wrote:
If two cubes share a face then the can be unioned and the result is manifold. What they can't do is share a single edge or a single vertex.

On 27 February 2018 at 17:25, jim.klessig <[hidden email]> wrote:
Someone wrote 

"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. "

To my mind, that is only true if you DEFINE "reality" as not having conjoined faces. 
IF you allow for "reality" to have conjoined faces, then you will find them every where. A block of 1*1*2 is in "reality" two  1*1*1 cubes with a common face. 

Why should "overlap be a requirement of them being "joined"? If any thing I would think "overlap" should be the "forbidden concept". That is the thing you can not actually realize in the real world.



Sent from my U.S. Cellular® Smartphone

-------- Original message --------
Date: 2/27/18 9:00 AM (GMT-08:00)
Subject: Discuss Digest, Vol 39, Issue 27

Send Discuss mailing list submissions to
[hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
or, via email, send a message with subject or body 'help' to
[hidden email]

You can reach the person managing the list at
[hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss digest..."


Today's Topics:

   1. Re: damaged STL file? (Jordan Brown)
   2. Re: damaged STL file? (Carsten Arnholm)
   3. Re: damaged STL file? (nop head)
   4. Re: damaged STL file? (doug moen)
   5. Re: damaged STL file? (Ronaldo Persiano)
   6. Re: damaged STL file? (nop head)
   7. Re: damaged STL file? (Ronaldo Persiano)
   8. Re: damaged STL file? (nop head)
   9. Re: damaged STL file? (Ronaldo Persiano)
  10. Re: damaged STL file? ([hidden email])
  11. Re: damaged STL file? (Gadgetmind)
  12. Re: damaged STL file? (nop head)
  13. Re: damaged STL file? (Mark Schafer)
  14. Re: damaged STL file? (Rogier Wolff)
  15. Why are manifolds important? (Jordan Brown)
  16. Re: damaged STL file? (doug moen)
  17. Re: Why are manifolds important? (nop head)


----------------------------------------------------------------------

Message: 1
Date: Mon, 26 Feb 2018 09:35:32 -0800
From: Jordan Brown <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>,
[hidden email]
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

On 2/26/2018 7:41 AM, [hidden email] wrote:
> In general I think the thread illustrates the somewhat fuzzy nature of
> repairing problematic polyhedra in general and STL files in particular
> (STLs do not provide any topology, it must be guessed). Several repair
> tools exist but they appear to make different assumptions leading to
> different results.

Are there other file formats that would be better?? Getting designers
like OpenSCAD and slicers to *both* implement something new would be
tough, but if there are clear benefits maybe it could be done.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180226/830a8339/attachment-0001.html>

------------------------------

Message: 2
Date: Mon, 26 Feb 2018 20:44:57 +0100
From: Carsten Arnholm <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=utf-8; format=flowed

On 26. feb. 2018 18:35, Jordan Brown wrote:
> Are there other file formats that would be better?? Getting designers
> like OpenSCAD and slicers to *both* implement something new would be
> tough, but if there are clear benefits maybe it could be done.

Yes, there are better formats (see below), but STL seems so entrenched
that it is very hard to get wide enough support for anything else. Some
requirements to a non-STL format I guess would be

1) Suited for polyhedron exchange between CAD applications, not just CAD
to slicers.

2) Unambiguous format, with explicit topology

3) Efficient binary storage, plus equivalent ascii text version with
same info. Binary/Ascii should be transparent to users.

4) It must be *very* simple.

etc.

OpenSCAD already support other 3D formats in addition to STL

OFF - http://paulbourke.net/dataformats/off/
AMF - https://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format

Both of the above satisfy 1) and 2). AMF in its simplest form is quite
nice, but not terribly efficient, plus in my opinion it forgets 4) so it
will never become universal. OFF is a nice contender, but it does not
seem to be simple enough to be popular.

STL is both wasteful and ambiguous, it is just a sea of free floating
triangles. The binary format does not contain the same info as the text
format, etc. Its popularity is due to history only.

It seems to me super simplicity is a key. So any alternative format
should be even simpler than STL. Given that existing alternatives are
not very popular, we might as well propose something new to compete,
making simplicity the key feature while fixing some of the STL issues.
In my mind it could be something like

* simple file header to identify ASCII/Binary
* vertex coordinates stored only once
* triangle faces only
* faces defined by references to vertices, implicit normals

In other words, just the bare minimum, equivalent to the info that goes
into OpenSCAD polyhedron command. The text format would be more compact
than STL and simpler to read. The binary format would also be more
compact than STL since coordinates would be mentioned only once, and
therefore also not have any issues with interpretation.

You could say it is far too simple. But if you want it to be widely
adopted it must be extremely simple and fast. We could call it STL2 and
say it is how STL should have been defined in 1985 or so :-)

I don't have any illusions it would be successful, but if it was adopted
I think it would be helpful in avoiding some of the "damaged STL" issues
(not all) and enable easier sharing of models between various applications.

Just my thoughts, nothing else.

Carsten Arnholm



------------------------------

Message: 3
Date: Mon, 26 Feb 2018 20:00:48 +0000
From: nop head <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<CAEEmnrPb=[hidden email]>
Content-Type: text/plain; charset="utf-8"

STL is unambiguous if it is written correctly and only used to represent a
manifold model with no self intersections. That is sufficient for 3D
printing as all 3D printed objects are manifold.

While other representations can also represent non-manifold objects it
pushes the problem downstream. How do you print a non-manifold object?



On 26 February 2018 at 19:44, Carsten Arnholm <[hidden email]> wrote:

> On 26. feb. 2018 18:35, Jordan Brown wrote:
>
>> Are there other file formats that would be better?  Getting designers
>> like OpenSCAD and slicers to *both* implement something new would be tough,
>> but if there are clear benefits maybe it could be done.
>>
>
> Yes, there are better formats (see below), but STL seems so entrenched
> that it is very hard to get wide enough support for anything else. Some
> requirements to a non-STL format I guess would be
>
> 1) Suited for polyhedron exchange between CAD applications, not just CAD
> to slicers.
>
> 2) Unambiguous format, with explicit topology
>
> 3) Efficient binary storage, plus equivalent ascii text version with same
> info. Binary/Ascii should be transparent to users.
>
> 4) It must be *very* simple.
>
> etc.
>
> OpenSCAD already support other 3D formats in addition to STL
>
> OFF - http://paulbourke.net/dataformats/off/
> AMF - https://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format
>
> Both of the above satisfy 1) and 2). AMF in its simplest form is quite
> nice, but not terribly efficient, plus in my opinion it forgets 4) so it
> will never become universal. OFF is a nice contender, but it does not seem
> to be simple enough to be popular.
>
> STL is both wasteful and ambiguous, it is just a sea of free floating
> triangles. The binary format does not contain the same info as the text
> format, etc. Its popularity is due to history only.
>
> It seems to me super simplicity is a key. So any alternative format should
> be even simpler than STL. Given that existing alternatives are not very
> popular, we might as well propose something new to compete, making
> simplicity the key feature while fixing some of the STL issues. In my mind
> it could be something like
>
> * simple file header to identify ASCII/Binary
> * vertex coordinates stored only once
> * triangle faces only
> * faces defined by references to vertices, implicit normals
>
> In other words, just the bare minimum, equivalent to the info that goes
> into OpenSCAD polyhedron command. The text format would be more compact
> than STL and simpler to read. The binary format would also be more compact
> than STL since coordinates would be mentioned only once, and therefore also
> not have any issues with interpretation.
>
> You could say it is far too simple. But if you want it to be widely
> adopted it must be extremely simple and fast. We could call it STL2 and say
> it is how STL should have been defined in 1985 or so :-)
>
> I don't have any illusions it would be successful, but if it was adopted I
> think it would be helpful in avoiding some of the "damaged STL" issues (not
> all) and enable easier sharing of models between various applications.
>
> Just my thoughts, nothing else.
>
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> 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/20180226/225993fd/attachment-0001.html>

------------------------------

Message: 4
Date: Mon, 26 Feb 2018 15:29:48 -0500
From: doug moen <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

3MF is a superior alternative to AMF.
* It is less ambiguous, due to explicit rules on how to interpret certain
non-manifold models that AMF leaves undefined. Specifically, it allows self
intersection and overlapping triangles. Here's one reason why this is
important. The union operation is not closed with respect to manifold
meshes. If you union two manifold meshes, the result may not be manifold. I
feel this is actually a defect in the definition of "manifold", because I
think it's intolerable if you can't union two arbitrary shapes and be
guaranteed to get a meaningful result. In any case, 3MF fixes this by
defining the result of the union of two manifold meshes to be a valid 3MF
model in all cases. AMF does not do this.
* 3MF is an open standard, and AMF is not (you have to pay money for a copy
of the AMF standard, and you can't redistribute your copy of this secret,
proprietary information.)
* 3MF has an open source library on github which interprets the standard.
* Nop head asks "how do you print a non-manifold object?". Well, the 3MF
standard and the associated library implementation gives some unambiguous
answers to that, for the cases that I mention above.

OpenSCAD has a 3MF implementation underway:
https://github.com/openscad/openscad/pull/1802.

The Cura slicer used to have an AMF implementation, but got rid of it, and
they now implement 3MF instead.

I feel it is not productive or useful at this point to design yet another
mesh file format.

On 26 February 2018 at 14:44, Carsten Arnholm <[hidden email]> wrote:

> On 26. feb. 2018 18:35, Jordan Brown wrote:
>
>> Are there other file formats that would be better?  Getting designers
>> like OpenSCAD and slicers to *both* implement something new would be tough,
>> but if there are clear benefits maybe it could be done.
>>
>
> Yes, there are better formats (see below), but STL seems so entrenched
> that it is very hard to get wide enough support for anything else. Some
> requirements to a non-STL format I guess would be
>
> 1) Suited for polyhedron exchange between CAD applications, not just CAD
> to slicers.
>
> 2) Unambiguous format, with explicit topology
>
> 3) Efficient binary storage, plus equivalent ascii text version with same
> info. Binary/Ascii should be transparent to users.
>
> 4) It must be *very* simple.
>
> etc.
>
> OpenSCAD already support other 3D formats in addition to STL
>
> OFF - http://paulbourke.net/dataformats/off/
> AMF - https://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format
>
> Both of the above satisfy 1) and 2). AMF in its simplest form is quite
> nice, but not terribly efficient, plus in my opinion it forgets 4) so it
> will never become universal. OFF is a nice contender, but it does not seem
> to be simple enough to be popular.
>
> STL is both wasteful and ambiguous, it is just a sea of free floating
> triangles. The binary format does not contain the same info as the text
> format, etc. Its popularity is due to history only.
>
> It seems to me super simplicity is a key. So any alternative format should
> be even simpler than STL. Given that existing alternatives are not very
> popular, we might as well propose something new to compete, making
> simplicity the key feature while fixing some of the STL issues. In my mind
> it could be something like
>
> * simple file header to identify ASCII/Binary
> * vertex coordinates stored only once
> * triangle faces only
> * faces defined by references to vertices, implicit normals
>
> In other words, just the bare minimum, equivalent to the info that goes
> into OpenSCAD polyhedron command. The text format would be more compact
> than STL and simpler to read. The binary format would also be more compact
> than STL since coordinates would be mentioned only once, and therefore also
> not have any issues with interpretation.
>
> You could say it is far too simple. But if you want it to be widely
> adopted it must be extremely simple and fast. We could call it STL2 and say
> it is how STL should have been defined in 1985 or so :-)
>
> I don't have any illusions it would be successful, but if it was adopted I
> think it would be helpful in avoiding some of the "damaged STL" issues (not
> all) and enable easier sharing of models between various applications.
>
> Just my thoughts, nothing else.
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> 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/20180226/cafd3473/attachment-0001.html>

------------------------------

Message: 5
Date: Mon, 26 Feb 2018 17:36:13 -0300
From: Ronaldo Persiano <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

I agree that STL is a waster format. But Arnholm four point proposal does
not assure a manifold definition neither it is more restrict than STL
format. In fact, any model expressed in a STL file may be expressed by an
OpenSCAD command whether it is a manifold or not.

Besides, with the advent of multi-material 3D print, a more general format
will be demanded representing a partition of the space in many adjacent
volumes to be filled with different materials. Although each of those
volumes might be a manifold, the whole model is not anymore.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180226/77021b5e/attachment-0001.html>

------------------------------

Message: 6
Date: Mon, 26 Feb 2018 20:46:40 +0000
From: nop head <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

I have never seen a physical solid object that isn't manifold. Surely that
is impossible, so if everything you can 3D print is manifold why do need to
represent non-manifolds. They only exist mathematically, not physically.

On 26 February 2018 at 20:36, Ronaldo Persiano <[hidden email]>
wrote:

> I agree that STL is a waster format. But Arnholm four point proposal does
> not assure a manifold definition neither it is more restrict than STL
> format. In fact, any model expressed in a STL file may be expressed by an
> OpenSCAD command whether it is a manifold or not.
>
> Besides, with the advent of multi-material 3D print, a more general format
> will be demanded representing a partition of the space in many adjacent
> volumes to be filled with different materials. Although each of those
> volumes might be a manifold, the whole model is not anymore.
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> 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/20180226/ff950978/attachment-0001.html>

------------------------------

Message: 7
Date: Mon, 26 Feb 2018 18:27:32 -0300
From: Ronaldo Persiano <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<CA+i9EaCOWiMjCOt+WvzEqJ5+E81zeQK97G9YFQ71LPEtOU+R=[hidden email]>
Content-Type: text/plain; charset="utf-8"

> I have never seen a physical solid object that isn't manifold. Surely that
> is impossible, so if everything you can 3D print is manifold why do need to
> represent non-manifolds. They only exist mathematically, not physically.
>
?
Consider two same axis cylinders joined end to end by an union operation.
If they have the same diameter, the union will be a longer cylinder. But if
the top cylinder should be 3D printed with a opaque filament and the bottom
one with a translucent one, the longer cylinder is not a good model for
printing it. We may want a two distinct volume with a common face. That is
not neither the union of two cylinders nor a manifold.

?I agree with you but 3D printing is not the only goal of CAD system in
general and of OpenSCAD in special. It would be legitimate to use OpenSCAD
for illustration, for instance. In an illustration of a car, why must the
motor hood have a thickness instead of being just the top hood surface?
Another non-manifold object.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180226/d6d1f4a3/attachment-0001.html>

------------------------------

Message: 8
Date: Mon, 26 Feb 2018 22:59:08 +0000
From: nop head <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

Yes STL can't represent two manifolds touching but even if it could you
can't use it for multi-materials because there is no way to associate
properties. The simple solution is to use multiple STLs as I did nearly
nine years ago now
http://hydraraptor.blogspot.co.uk/2009/11/hacking-with-erik.html.

Yes STL is no good for illustrations or CAD interchange, it was only ever
intended for 3D printing.

On 26 February 2018 at 21:27, Ronaldo Persiano <[hidden email]>
wrote:

>
> I have never seen a physical solid object that isn't manifold. Surely that
>> is impossible, so if everything you can 3D print is manifold why do need to
>> represent non-manifolds. They only exist mathematically, not physically.
>>
> ?
> Consider two same axis cylinders joined end to end by an union operation.
> If they have the same diameter, the union will be a longer cylinder. But if
> the top cylinder should be 3D printed with a opaque filament and the bottom
> one with a translucent one, the longer cylinder is not a good model for
> printing it. We may want a two distinct volume with a common face. That is
> not neither the union of two cylinders nor a manifold.
>
> ?I agree with you but 3D printing is not the only goal of CAD system in
> general and of OpenSCAD in special. It would be legitimate to use
> OpenSCAD for illustration, for instance. In an illustration of a car, why
> must the motor hood have a thickness instead of being just the top hood
> surface? Another non-manifold object.
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> 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/20180226/e7a312b5/attachment-0001.html>

------------------------------

Message: 9
Date: Mon, 26 Feb 2018 21:44:02 -0300
From: Ronaldo Persiano <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

>
>
> Yes STL can't represent
> ??
> two manifolds touching but even if it could you
> ??
> can't use it for multi-materials because there is no way to associate
> properties. The simple solution is to use multiple STLs as I did nearly
> nine years ago now http://hydraraptor.blogspot.co.uk/2009/11/hacking-with-
> erik.html.
>

?You are right saying that STL can't be used for multi-materials because
there is no way to associate properties. But it can represent
?
two manifolds touching. Given the STL of a cube, add two more triangles
subdividing the rectangle joining two opposed cube edges. If you want,
duplicate each of these triangles with opposed normals.

My point is: we need a model more general  than manifolds to comprise
things like multi-material 3D printing without hacked solutions. May be 3MF
is the solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180226/b7781289/attachment-0001.html>

------------------------------

Message: 10
Date: Tue, 27 Feb 2018 09:08:08 +0100
From: [hidden email]
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=US-ASCII; format=flowed

On 2018-02-26 21:29, doug moen wrote:
> 3MF is a superior alternative to AMF.

That may be so. I agree that any proprietary nature of AMF is another
argument against it.

I had a very quick glance at the 3MF specs. The PDF is 50+ pages and
talks about many non-trivial aspects unrelated to the model itself.
Although it seems well documented, it does not quite meet my simplicity
requirement (#4). It is also XML based. I really like XML, but it means
it will not be super fast, and not compact.

There are very odd requirements in 3MF that the model must be in the
positive octant of the coordinate space. This tells me the format is not
generally intended for data exchange between application (failing my
#1), but probably intended specifically for 3d printers. So it isn't
what I had in mind.

> * It is less ambiguous, due to explicit rules on how to interpret
> certain non-manifold models that AMF leaves undefined. Specifically,
> it allows self intersection and overlapping triangles.

Ok, I will be blunt and say this is likely to kill it as a useful format
for exchange. It will cause problems. Consider implementing a 3MF
importer in OpenSCAD.

> Here's one
> reason why this is important. The union operation is not closed with
> respect to manifold meshes. If you union two manifold meshes, the
> result may not be manifold.

union() {
    cube(100);
    translate([100,100,0])cube(100);
}

The above example will typically result in a model which is explicitly
not allowed in 3MF, unless you duplicate the common edge.

https://3mf.io/wp-content/uploads/2017/10/3MF_Core_Spec_v1.2_28129.pdf
page 28

> * 3MF is an open standard, and AMF is not (you have to pay money for a
> copy of the AMF standard, and you can't redistribute your copy of this
> secret, proprietary information.)

Good point.

> OpenSCAD has a 3MF implementation underway:
> https://github.com/openscad/openscad/pull/1802.

That's interesting.

> I feel it is not productive or useful at this point to design yet
> another mesh file format.

My feeling is that if 3MF is the alternative, then STL will continue to
dominate due to its inertia. I may draft an alternative if nobody else
is interested. It will be either successful or ignored, so no harm done
:-) I guess 3MF will be useful for its purpose, but in my opinion there
should be a simpler and more compact alternative, and it isn't today's
STL.


Carsten Arnholm



------------------------------

Message: 11
Date: Tue, 27 Feb 2018 08:30:18 +0000
From: Gadgetmind <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>, nop head
<[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 26/02/18 22:59, nop head wrote:
> The simple solution is to use multiple STLs

I was musing on this recently.

I wanted to print a triangular prism on its side (toblerone!) with the
top flattened and a V notch then cut in this to let me stand a thin
object in it.

It wouldn't need any infill other than where the flat/notch on the top
was. I can design an object that's all the outside faces (with
thickness) and a support designed in, but would it actually work? Would
OpenSCAD cope/barf and would a slicer be happy with an object with
interior voids?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180227/fdeaad16/attachment-0001.html>

------------------------------

Message: 12
Date: Tue, 27 Feb 2018 08:58:55 +0000
From: nop head <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

> I really like XML, but it means it will not be super fast, and not
compact.

IIRC 3ML has a zip wrapper to make the XML compact. It won't be supper fast
though but compared to OpenSCAD rendering and slicer execution time, not to
mention 3D printing time, I doubt speed will be an issue.

On 27 February 2018 at 08:08, <[hidden email]> wrote:

> On 2018-02-26 21:29, doug moen wrote:
>
>> 3MF is a superior alternative to AMF.
>>
>
> That may be so. I agree that any proprietary nature of AMF is another
> argument against it.
>
> I had a very quick glance at the 3MF specs. The PDF is 50+ pages and talks
> about many non-trivial aspects unrelated to the model itself. Although it
> seems well documented, it does not quite meet my simplicity requirement
> (#4). It is also XML based. I really like XML, but it means it will not be
> super fast, and not compact.
>
> There are very odd requirements in 3MF that the model must be in the
> positive octant of the coordinate space. This tells me the format is not
> generally intended for data exchange between application (failing my #1),
> but probably intended specifically for 3d printers. So it isn't what I had
> in mind.
>
> * It is less ambiguous, due to explicit rules on how to interpret
>> certain non-manifold models that AMF leaves undefined. Specifically,
>> it allows self intersection and overlapping triangles.
>>
>
> Ok, I will be blunt and say this is likely to kill it as a useful format
> for exchange. It will cause problems. Consider implementing a 3MF importer
> in OpenSCAD.
>
> Here's one
>> reason why this is important. The union operation is not closed with
>> respect to manifold meshes. If you union two manifold meshes, the
>> result may not be manifold.
>>
>
> union() {
>    cube(100);
>    translate([100,100,0])cube(100);
> }
>
> The above example will typically result in a model which is explicitly not
> allowed in 3MF, unless you duplicate the common edge.
>
> https://3mf.io/wp-content/uploads/2017/10/3MF_Core_Spec_v1.2_28129.pdf
> page 28
>
> * 3MF is an open standard, and AMF is not (you have to pay money for a
>> copy of the AMF standard, and you can't redistribute your copy of this
>> secret, proprietary information.)
>>
>
> Good point.
>
> OpenSCAD has a 3MF implementation underway:
>> https://github.com/openscad/openscad/pull/1802.
>>
>
> That's interesting.
>
> I feel it is not productive or useful at this point to design yet
>> another mesh file format.
>>
>
> My feeling is that if 3MF is the alternative, then STL will continue to
> dominate due to its inertia. I may draft an alternative if nobody else is
> interested. It will be either successful or ignored, so no harm done :-) I
> guess 3MF will be useful for its purpose, but in my opinion there should be
> a simpler and more compact alternative, and it isn't today's STL.
>
>
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> 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/20180227/ca80ce47/attachment-0001.html>

------------------------------

Message: 13
Date: Tue, 27 Feb 2018 22:44:58 +1300
From: Mark Schafer <[hidden email]>
To: [hidden email]
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="us-ascii"

An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180227/95eb53a9/attachment-0001.html>

------------------------------

Message: 14
Date: Tue, 27 Feb 2018 13:43:19 +0100
From: Rogier Wolff <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID: <20180227124319.GO4755@BitWizard.nl>
Content-Type: text/plain; charset=us-ascii

On Tue, Feb 27, 2018 at 08:30:18AM +0000, Gadgetmind wrote:

> On 26/02/18 22:59, nop head wrote:
> >The simple solution is to use multiple STLs
>
> I was musing on this recently.
>
> I wanted to print a triangular prism on its side (toblerone!) with
> the top flattened and a V notch then cut in this to let me stand a
> thin object in it.
>
> It wouldn't need any infill other than where the flat/notch on the
> top was. I can design an object that's all the outside faces (with
> thickness) and a support designed in, but would it actually work?
> Would OpenSCAD cope/barf and would a slicer be happy with an object
> with interior voids?

I tried doing what you proposed in a few minutes, but hte version with
"support designed in" was too difficult for me in a few minutes. But I'm
pretty sure it would work.

The "standard" way to quickly get such supports is to make it a wall
instead.


v=0; // use v=1 to be able to see the cutout stick out.


module tob1()
{
  difference () {
    translate ([100,0,0]) rotate ([0,-90,0]) cylinder (d=20,h=100,$fn=3);
    // toblerone, on it side, where I want it.
 
    translate ([-1,-5,7]) cube ([110,10,10]);
    // flattened

    scale ([1,.1,1]) translate ([-1,0,5]) rotate ([0,90,0]) cylinder (d=10,h=102,$fn=3);
    // with a V-notch.
  }
}

module tob2()
{
  difference () {
    tob1 ();
   
#    translate ([1-2*v,-0.050,-4.5]) cube ([98+4*v,.10,5.4]) ;
  }
}

tob2();


--
** [hidden email] ** http://www.BitWizard.nl/ ** <a href="tel:+31%2015%20260%200998" value="+31152600998" target="_blank">+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.



------------------------------

Message: 15
Date: Tue, 27 Feb 2018 06:45:45 -0800
From: Jordan Brown <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: [OpenSCAD] Why are manifolds important?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

One of the things that has puzzled me is the requirement that objects
for 3D printing be manifold.

First, I should note that I'm not strong on the math involved and so I'm
not *absolutely* sure what "manifold" means.

I understand that it's bad for objects to be self-intersecting.? A
self-intersecting object ... isn't exactly an object at all, and has no
translation to physical reality.? Well, except maybe through implicitly
unioning.? And, absent "polyhedra" and "polygons" that aren't polyhedra
or polygons, is there any way to get self-intersecting objects in OpenSCAD?

But I don't understand the requirement to avoid shared edges.

    cube(1);
    translate([1,1,0]) cube(1);

Why is this a problem?? Yeah, it's got a piece that's zero thickness
right along where the two cubes touch, but that doesn't seem any harder
than having it be infinitesimal.? It's more or less obvious what I mean,
so why should I have to worry about it?? Why should I have to keep
nudging objects around so that they don't touch, when in the physical
reality that I'm trying to model they *do* touch?

(And if you ask "should the slicer put a filament between the two
cubes", my answer is "I don't care".? If I wanted them to be separate
objects I would have kept them separate, and if I wanted them to be
solidly joined I would have made them solidly joined.? Again, this seems
like an extreme case of a piece of an object that is much smaller than
the extrusion width or thickness, or two objects that mathematically
don't touch but are separated by less than the printer resolution.)

Is it all about making unambiguous sense out of polygon soup?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180227/417922ec/attachment-0001.html>

------------------------------

Message: 16
Date: Tue, 27 Feb 2018 10:40:37 -0500
From: doug moen <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] damaged STL file?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

Carsten:

A 3MF file can contain multiple objects. Each object has a mesh and a
material ID. This is how multi-extruder, multi-material 3D prints are
supported. You define one object for each material or colour. There is no
problem if two objects share faces. That's normal for a multi-material
print.

Within an object, a mesh is defined as an array of vertices (each vertex
has an integer index) and an array of triangles (each triangle has 3 vertex
indices).

It is legal to have two vertices with the same (x,y,z) coordinates, but
different indices.

In section 4.1, the standard says:
  "Manifold Edges: Every triangle edge in the mesh shares common vertex
endpoints with the edge of exactly 1 other triangle."

But, in this sentence, the meaning of two vertices being the same is that
they have the same index, not that they have the same (x,y,z) coordinates.
So 3MF is not a triangle soup format like STL, and a manifold mesh in 3MF
can represent a larger set of shapes than a manifold mesh in STL.

In section 4.1.3, the standard says:
  "The vertices element contains all the <vertex> elements for this object.
The vertices represent the corners of each triangle in the mesh. The order
of these elements defines an implicit 0-based index that is referenced by
other elements, such as the <triangle> element. The producer SHOULD NOT
include duplicate vertices unless coalescing duplicates would create
non-manifold edges."

On 27 February 2018 at 03:08, <[hidden email]> wrote:

> On 2018-02-26 21:29, doug moen wrote:
>
>> 3MF is a superior alternative to AMF.
>>
>
> That may be so. I agree that any proprietary nature of AMF is another
> argument against it.
>
> I had a very quick glance at the 3MF specs. The PDF is 50+ pages and talks
> about many non-trivial aspects unrelated to the model itself. Although it
> seems well documented, it does not quite meet my simplicity requirement
> (#4). It is also XML based. I really like XML, but it means it will not be
> super fast, and not compact.
>
> There are very odd requirements in 3MF that the model must be in the
> positive octant of the coordinate space. This tells me the format is not
> generally intended for data exchange between application (failing my #1),
> but probably intended specifically for 3d printers. So it isn't what I had
> in mind.
>
> * It is less ambiguous, due to explicit rules on how to interpret
>> certain non-manifold models that AMF leaves undefined. Specifically,
>> it allows self intersection and overlapping triangles.
>>
>
> Ok, I will be blunt and say this is likely to kill it as a useful format
> for exchange. It will cause problems. Consider implementing a 3MF importer
> in OpenSCAD.
>
> Here's one
>> reason why this is important. The union operation is not closed with
>> respect to manifold meshes. If you union two manifold meshes, the
>> result may not be manifold.
>>
>
> union() {
>    cube(100);
>    translate([100,100,0])cube(100);
> }
>
> The above example will typically result in a model which is explicitly not
> allowed in 3MF, unless you duplicate the common edge.
>
> https://3mf.io/wp-content/uploads/2017/10/3MF_Core_Spec_v1.2_28129.pdf
> page 28
>
> * 3MF is an open standard, and AMF is not (you have to pay money for a
>> copy of the AMF standard, and you can't redistribute your copy of this
>> secret, proprietary information.)
>>
>
> Good point.
>
> OpenSCAD has a 3MF implementation underway:
>> https://github.com/openscad/openscad/pull/1802.
>>
>
> That's interesting.
>
> I feel it is not productive or useful at this point to design yet
>> another mesh file format.
>>
>
> My feeling is that if 3MF is the alternative, then STL will continue to
> dominate due to its inertia. I may draft an alternative if nobody else is
> interested. It will be either successful or ignored, so no harm done :-) I
> guess 3MF will be useful for its purpose, but in my opinion there should be
> a simpler and more compact alternative, and it isn't today's STL.
>
>
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> 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/20180227/1cafb99d/attachment-0001.html>

------------------------------

Message: 17
Date: Tue, 27 Feb 2018 16:28:45 +0000
From: nop head <[hidden email]>
To: OpenSCAD general discussion <[hidden email]>
Subject: Re: [OpenSCAD] Why are manifolds important?
Message-ID:
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

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 <[hidden email]>
wrote:

> One of the things that has puzzled me is the requirement that objects for
> 3D printing be manifold.
>
> First, I should note that I'm not strong on the math involved and so I'm
> not *absolutely* sure what "manifold" means.
>
> I understand that it's bad for objects to be self-intersecting.  A
> self-intersecting object ... isn't exactly an object at all, and has no
> translation to physical reality.  Well, except maybe through implicitly
> unioning.  And, absent "polyhedra" and "polygons" that aren't polyhedra or
> polygons, is there any way to get self-intersecting objects in OpenSCAD?
>
> But I don't understand the requirement to avoid shared edges.
>
> cube(1);
> translate([1,1,0]) cube(1);
>
> Why is this a problem?  Yeah, it's got a piece that's zero thickness right
> along where the two cubes touch, but that doesn't seem any harder than
> having it be infinitesimal.  It's more or less obvious what I mean, so why
> should I have to worry about it?  Why should I have to keep nudging objects
> around so that they don't touch, when in the physical reality that I'm
> trying to model they *do* touch?
>
> (And if you ask "should the slicer put a filament between the two cubes",
> my answer is "I don't care".  If I wanted them to be separate objects I
> would have kept them separate, and if I wanted them to be solidly joined I
> would have made them solidly joined.  Again, this seems like an extreme
> case of a piece of an object that is much smaller than the extrusion width
> or thickness, or two objects that mathematically don't touch but are
> separated by less than the printer resolution.)
>
> Is it all about making unambiguous sense out of polygon soup?
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> 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/20180227/3672d2ca/attachment-0001.html>

------------------------------

Subject: Digest Footer

_______________________________________________
Discuss mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


------------------------------

End of Discuss Digest, Vol 39, Issue 27
***************************************

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Manifolds and sharing edges/faces

cacb
On 27. feb. 2018 19:12, doug moen wrote:
> I think it is useful to note that this restriction that "two cubes can't
> share a single edge or single vertex" exists in the 2-manifold STL
> representation of a mesh. However, 3MF meshes don't have this
> restriction.

Huh? It is exactly the other way around. STL files don't contain any
common vertices and no common edges so there is no possibility of
sharing anything. Don't confuse the interpretation in OpenSCAD or other
programs with the data representation in the STL file.

3MF has the issue unless the cubes are separated in different meshes.

> WARNING: Object may not be a valid 2-manifold and may need repair!
>
>
> Actually, this warning is needed for STL export, but not for 3MF export.

This is not correct.

Carsten Arnholm

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Manifolds and sharing edges/faces

doug.moen
STL is just triangle soup, but if you restrict that triangle soup to being 2-manifold, then the restricted format that I called "2-manifold STL" cannot represent "two cubes sharing a single edge". This restricted form of STL is extremely relevant to this discussion, since OpenSCAD prints a warning if you create a mesh that is not "2-manifold STL". I am not confusing the OpenSCAD interpretation of STL with the file format itself, this is an OpenSCAD forum where we are discussing STL with respect to OpenSCAD.

The 3MF format *is* capable of representing "two cubes sharing a single edge". You can do this in a single 3MF "object", without violating any rules of the 3MF format. You can't represent this same model in AMF without violating the rules of the AMF format.

A single 3MF object can contain more than one disjoint surface. This is necessary to represent internal voids, which they discuss.

To convert the two cubes sharing an edge mesh to a valid 3MF mesh, you need to split the two vertices that have 4 edges. There's two ways to do that. One way results in two disjoint surfaces (2 cubes), like you said, but still contained in a single object. The other way results in a single surface.

I think that you don't like the complexity of 3MF, and the complexity of the algorithm required to split vertices in order to create what the 3MF standard calls "a mesh with manifold edges". You want a mesh interchange format that doesn't have this complexity. That's fine.

I have a rather different set of goals. I want a standard mesh interchange format that everybody supports, and that supports unions and intersections of meshes, without me being told that "Object may not be a valid 2-manifold and may need repair!". As far as I can tell, 3MF is the only candidate that meets my criteria, or will meet it in the near future. Meshmixer just got 3MF support last month, it's still quite new in Cura, and the OpenSCAD implementation is still under construction. A brand new mesh format that meets your needs won't help me, because popular tools won't support it.

On 27 February 2018 at 14:24, Carsten Arnholm <[hidden email]> wrote:
On 27. feb. 2018 19:12, doug moen wrote:
I think it is useful to note that this restriction that "two cubes can't share a single edge or single vertex" exists in the 2-manifold STL representation of a mesh. However, 3MF meshes don't have this restriction.

Huh? It is exactly the other way around. STL files don't contain any common vertices and no common edges so there is no possibility of sharing anything. Don't confuse the interpretation in OpenSCAD or other programs with the data representation in the STL file.

3MF has the issue unless the cubes are separated in different meshes.

WARNING: Object may not be a valid 2-manifold and may need repair!


Actually, this warning is needed for STL export, but not for 3MF export.

This is not correct.


Carsten Arnholm

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
rew
Reply | Threaded
Open this post in threaded view
|

Re: Manifolds and sharing edges/faces

rew
In reply to this post by nophead
On Tue, Feb 27, 2018 at 05:33:13PM +0000, nop head wrote:
> If two cubes share a face then the can be unioned and the result is
> manifold. What they can't do is share a single edge or a single vertex.

For slicers the problem is very similar.

You have an object, you intersect that object with a plane (the slice!)
and for each delineated part of the plane, you determine if it is inside or
outside the object.

So with
  cube (10);
  translate ([10,0,0]) cube  (10);

when you slice at Z=5, you will encounter the common face at
X=10. When you cross that face, do you pass from inside to outside the
object or not? (Is it an edge of de object? If the walls are 1mm and
the infill 0%, do you fill the X= 9-11 mm area? Things are difficult. )

In practise, this case seems to work out.

I've had a case similar to:
  module mycylinder (r,h, wt)
  {
    difference () {
        cylinder (r=r, h=h);
        //translate ([0,0,-1]) cylinder (r=r-wt, h=h+2);
        cylinder (r=r-wt, h=h);
    }
  }

  mycylinder (r=10, h=10, wt=1);
  translate ([0,0,10])  mycylinder (r=10, h=10, wt=1);

Here when slicing at z=10mm, the slicer got confused with the number
of edges it encountered, and thought it had seen an odd number of
edges (i.e. passing from outside to inside) when in fact the number of
edges passed was even.

The result was that it tried to build one solid layer at that one
specific height.

Those are the kinds of corner cases that you can expect from almost
manifold objects.

        Roger.

--
** [hidden email] ** 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.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org