damaged STL file?
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 arnholm@arnholm.org 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
-
Suited for polyhedron exchange between CAD applications, not just CAD
to slicers. -
Unambiguous format, with explicit topology
-
Efficient binary storage, plus equivalent ascii text version with same
info. Binary/Ascii should be transparent to users. -
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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.
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 rcmpersiano@gmail.com
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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.
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 rcmpersiano@gmail.com
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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.
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
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 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, arnholm@arnholm.org 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:
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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I wrote a simple amf to openscad polyhedron format converter here:
- https://github.com/Neon22/amf-to-openscad-polyhedron
The xml is annoying but if you only need some of the format represented then this is a start...?
On 2/27/2018 9:30 PM, 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?
<pre wrap="">_______________________________________________ OpenSCAD mailing list <a class="moz-txt-link-abbreviated" href="mailto:Discuss@lists.openscad.org">Discuss@lists.openscad.org</a> <a class="moz-txt-link-freetext" href="http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org">http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org</a>