damaged STL file?
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-2v,-0.050,-4.5]) cube ([98+4v,.10,5.4]) ;
}
}
tob2();
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
-- BitWizard writes Linux device drivers for any device you may have! --
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
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, 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
On 27. feb. 2018 16:40, doug moen wrote:
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.
Please see what I wrote. You are talking about something else.
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).
No need to explain to me what i wrote before... this is basic in all
formats except STL...
It is legal to have two vertices with the same (x,y,z) coordinates, but
different indices.
No need to explain...
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,
No need to explain... I know 3MF is not a triangle soup. I am not here
to defend things I never said.
Please see what I wrote. I have not claimed anything about common
coordinates, and certainly not that it isn't allowed. Of course it is
allowed. I am talking about topology.
Each topological edge in a mesh has a unique identifier, it can be
explicitly or implicitly defined, but it is unique. In this case the
identifier may be defined implicitly using the vertex indices. What they
are saying in a roundabout way is that any edge identified in this way
must not be referenced from more that 2 triangles (i.e. 2-manifold
requirement).
I pointed out that the example I gave will in OpenSCAD generate an edge
shared by more than 2 triangles, in conflict with the 2-manifold
requirement, and OpenSCAD agrees:
"WARNING: Object may not be a valid 2-manifold and may need repair! "
This is the issue discussed, and 3MF does not allow such issues. If you
want to export that model from OpenSCAD to 3MF in a compliant way, you
have to eliminate the common edge, like I said before. Since edges
identifies are implicit, it means vertices must be duplicated for that edge.
Now, I really don't mind if you ignore it and generate a 3MF with such a
non-compliant issue, my point is ONLY that it seems to me that 3MF is
not likely to succeed in defining away common issues that happen in real
models, and the result will still be problematic data exchange. The
exchange issue is really the only thing I am concerned with.
I think this illustrates the point that it is in my opinion preferable
to have a format that does not try to police in the same way, but is
still well defined. The important thing is that what is stored is
unambiguous and easy to understand and not overly restrictive or
complex. So therefore the "STL done right" idea.
Again, I am not against 3MF at all, but there are some scenarios it does
not seem to handle well.
Carsten Arnholm
Okay, I understand your point now. Sorry about the aggravation.
On 27 February 2018 at 14:14, Carsten Arnholm arnholm@arnholm.org wrote:
On 27. feb. 2018 16:40, doug moen wrote:
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.
Please see what I wrote. You are talking about something else.
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).
No need to explain to me what i wrote before... this is basic in all
formats except STL...
It is legal to have two vertices with the same (x,y,z) coordinates, but
different indices.
No need to explain...
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,
No need to explain... I know 3MF is not a triangle soup. I am not here to
defend things I never said.
Please see what I wrote. I have not claimed anything about common
coordinates, and certainly not that it isn't allowed. Of course it is
allowed. I am talking about topology.
Each topological edge in a mesh has a unique identifier, it can be
explicitly or implicitly defined, but it is unique. In this case the
identifier may be defined implicitly using the vertex indices. What they
are saying in a roundabout way is that any edge identified in this way must
not be referenced from more that 2 triangles (i.e. 2-manifold requirement).
I pointed out that the example I gave will in OpenSCAD generate an edge
shared by more than 2 triangles, in conflict with the 2-manifold
requirement, and OpenSCAD agrees:
"WARNING: Object may not be a valid 2-manifold and may need repair! "
This is the issue discussed, and 3MF does not allow such issues. If you
want to export that model from OpenSCAD to 3MF in a compliant way, you have
to eliminate the common edge, like I said before. Since edges identifies
are implicit, it means vertices must be duplicated for that edge.
Now, I really don't mind if you ignore it and generate a 3MF with such a
non-compliant issue, my point is ONLY that it seems to me that 3MF is not
likely to succeed in defining away common issues that happen in real
models, and the result will still be problematic data exchange. The
exchange issue is really the only thing I am concerned with.
I think this illustrates the point that it is in my opinion preferable to
have a format that does not try to police in the same way, but is still
well defined. The important thing is that what is stored is unambiguous and
easy to understand and not overly restrictive or complex. So therefore the
"STL done right" idea.
Again, I am not against 3MF at all, but there are some scenarios it does
not seem to handle well.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Just for the fun of it, I'd like to suggest a different approach to a good
file format. I know that I cannot change the 3D printer and the CAD
community, but here's the idea.
What would be very handy in a file format is support for all programming
languages and the possibility to load different pieces of it as you need
them, rather than loading the entire set of data into memory before parsing
it.
From these considerations, I would suggest an SQLite database. It is widely
supported, enough tools exist to see and use the contents (somewhat
cancelling the need for an ascii version), and every programming language
can read and write them. The format may not be simple, but the wide support
sort of makes up for it.
A slicer could read the data sorted "from the ground up", while CAD programs
could use different strategies, but all systems would be able to use it.
--
Sent from: http://forum.openscad.org/
Isn't sqlite super heavy compared to basically anything? Would the
format use indexing and sql queries?
Anyway I don't think that it's a good idea to make a new 3D format.
IMHO the best course is to figure out a good existing one that already
has some support and start pushing it, if STL is not good enough. 3MF
looks pretty decent (although XML is a bit meh for me).
... but .... as a thought experiment, if we decided to make a new one,
I'd go for file structure of PNG. Minimal version is very easy to
read if there's no compression involved and has enough flexibility for
anything you might need now and in the future.
On Wed, 28 Feb 2018 02:27:19 -0700 (MST)
MathLover mathlover@w-p.dds.nl wrote:
Just for the fun of it, I'd like to suggest a different approach to a good
file format. I know that I cannot change the 3D printer and the CAD
community, but here's the idea.
What would be very handy in a file format is support for all programming
languages and the possibility to load different pieces of it as you need
them, rather than loading the entire set of data into memory before parsing
it.
From these considerations, I would suggest an SQLite database. It is widely
supported, enough tools exist to see and use the contents (somewhat
cancelling the need for an ascii version), and every programming language
can read and write them. The format may not be simple, but the wide support
sort of makes up for it.
A slicer could read the data sorted "from the ground up", while CAD programs
could use different strategies, but all systems would be able to use it.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 2018-02-28 10:27, MathLover wrote:
From these considerations, I would suggest an SQLite database.
This is a decent idea, SQLite is super lightweight. I have used it for
implementing a quasi OO-database
https://github.com/arnholm/op_lite and SQLite is very fast and
efficient. I have such files with many gigabytes without issues.
BUT, the main thing for data sharing is is not really the physical
representation on disk, but the logical structure of the data contained.
Once you have that sorted, you can define/implement various file
representations, like flat ascii, flat binary, SQLite or whatever. Once
you have that, tt is true that SQLite would provide access from multiple
languages, and be binary portable across platform and support very large
datasets.
But if you put a polygon soup into SQLite it would still be a polygon
soup.
Carsten Arnholm
MathLover wrote
From these considerations, I would suggest an SQLite database.
I'm sorry, but I think that's a really lousy idea.
For the sort of data found in an object definition SQLite would provide no
additional advantages over any other file format. The SQL tables would just
be wrappers around the data.
The last thing I'd want to have to do when writing a file parser is use an
API that does the equivalent of "SELECT x, y, z FROM vertices"
See also https://xkcd.com/927/
Ray
--
Sent from: http://forum.openscad.org/
If the problem you are trying to solve is the ability to process meshes
that are too big to fit into memory, then sqlite is the wrong solution. You
need a spatial database that supports geometric range queries. The
Wikipedia page is a nice overview.
But if you do that, clients will need to use a special library for reading
and writing the database. File formats like STL and 3MF are easy enough to
generate and parse that they don't require a file format specific library.
On Wednesday, 28 February 2018, MathLover mathlover@w-p.dds.nl wrote:
Just for the fun of it, I'd like to suggest a different approach to a good
file format. I know that I cannot change the 3D printer and the CAD
community, but here's the idea.
What would be very handy in a file format is support for all programming
languages and the possibility to load different pieces of it as you need
them, rather than loading the entire set of data into memory before parsing
it.
From these considerations, I would suggest an SQLite database. It is widely
supported, enough tools exist to see and use the contents (somewhat
cancelling the need for an ascii version), and every programming language
can read and write them. The format may not be simple, but the wide support
sort of makes up for it.
A slicer could read the data sorted "from the ground up", while CAD
programs
could use different strategies, but all systems would be able to use it.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org