Discuss manifoldness, co-incident faces edges etc
On the topic of, can we detect and/or fix it. I started with an edge.
Netfabb reports two 10x10x10 cubes with a shared edge, as having two holes, and also highlights the
edge as a self-intersection.
GUI repair doesn't fully fix it, the holes go away (ie the count in the repair stats = 0), but
there is still a self-intersection, on export it shows:
It splits the shared edge into three:
The blue edge (also an edge shared on one triangle on the back of that - left - cube) is no longer
the same edge as the two on the other cube (also two matching triangles behind the right cube).
That seems like cheating??
The two vertices on the ends of the blue line are identical to the outer-ends of the red/yellow
respectively, mesh lab labels them non-manifold vertices.
So I presume the repair is targeted at making it printable, rather than fully manifold.
Also, isn't a vertex effectively in the middle of the larger blue-sided triangle breaking another
topology rule?
It still leaves, basically, a zero thickness join. Indeterminate on whether that is one object or
two. I looked at the STL, it hasn't[*] changed the position of the edges they are still co-axial.
Just not the exact same segment along the axis.
Even nudging two of the four non-manifold vertices won't fix it.
[*] it actually did change them, by the tolerance in the above dialogue box, but it changed them
all, so they are effectively the same.
I imagine properly fixing it would require (assuming a mandate that 'touching' means joining)
turning the edge into a minimalist thickness solid.
e.g. using a cubic to overlap the edge:
If that thickness was something like three times the grid size, it would have little effect.
That in itself could cause other edges to become co-incident, requiring them to be 'thickened' too,
but at a grid like size it would be an extremely intricate model for that to cascade.
A similar strategy for a shared point, would be to make the point a minimal cube.
So, if there was a mode/option/parameter that said 'touch'=='join', is there a down side to
solidify an edge/point to create a solid join?
So, if there was a mode/option/parameter that said 'touch'=='join', is
there a down side to solidify an edge/point to create a solid join?
Seems like a horrible bodge to me. Much better to overlap the cubes if you
want then joined or separate them slightly if you don't. Then you are
explicitly modelling what you want printed instead of modelling something
physically impossible and relying on a strange option to add a sticking
plaster over it.
On Sat, 16 Nov 2019 at 03:00, Michael Marx michael@marx.id.au wrote:
On the topic of, can we detect and/or fix it. I started with an edge.
Netfabb reports two 10x10x10 cubes with a shared edge, as having two
holes, and also highlights the edge as a self-intersection.
GUI repair doesn't fully fix it, the holes go away (ie the count in the
repair stats = 0), but there is still a self-intersection, on export it
shows:
It splits the shared edge into three:
The blue edge (also an edge shared on one triangle on the back of that -
left - cube) is no longer the same edge as the two on the other cube (also
two matching triangles behind the right cube).
That seems like cheating??
The two vertices on the ends of the blue line are identical to the
outer-ends of the red/yellow respectively, mesh lab labels them
non-manifold vertices.
So I presume the repair is targeted at making it printable, rather than
fully manifold.
Also, isn’t a vertex effectively in the middle of the larger blue-sided
triangle breaking another topology rule?
It still leaves, basically, a zero thickness join. Indeterminate on
whether that is one object or two. I looked at the STL, it hasn't[*]
changed the position of the edges they are still co-axial.
Just not the exact same segment along the axis.
Even nudging two of the four non-manifold vertices won't fix it.
[*] it actually did change them, by the tolerance in the above dialogue
box, but it changed them all, so they are effectively the same.
I imagine properly fixing it would require (assuming a mandate that
'touching' means joining) turning the edge into a minimalist thickness
solid.
e.g. using a cubic to overlap the edge:
If that thickness was something like three times the grid size, it would
have little effect.
That in itself could cause other edges to become co-incident, requiring
them to be 'thickened' too, but at a grid like size it would be an
extremely intricate model for that to cascade.
A similar strategy for a shared point, would be to make the point a
minimal cube.
So, if there was a mode/option/parameter that said 'touch'=='join', is
there a down side to solidify an edge/point to create a solid join?
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On Fri, Nov 15, 2019, at 9:59 PM, Michael Marx wrote:
On the topic of, can we detect and/or fix it. I started with an edge.
Netfabb reports two 10x10x10 cubes with a shared edge, as having two holes, and also highlights the edge as a self-intersection.
GUI repair doesn't fully fix it, the holes go away (ie the count in the repair stats = 0), but there is still a self-intersection, on export it shows:
The Netfabb export dialog says "Some file formats do not include enough information. This may result in errors."
Translated, that means "The STL file format does not include topology information. This may result in errors.". Most (all?) of the later mesh file formats used for 3D printing include topology information. So we might expect different results if we use a different file format.
I only have Netfabb Basic, which doesn't do automatic repairs, so I used MeshLab instead for my first test.
In OpenSCAD, I exported this model:
cube(10); translate([10,10,0]) cube(10);
to STL.
When import into MeshLab, it detects corruption, and asks if I want to repair it. The dialog says "Unify duplicated vertices?".
I say yes, and MeshLab performs the repair. Then I export to an OBJ file, which includes topology information. Then, when I import that same OBJ file into MeshLab, it does not report any errors.
If use OpenSCAD to export this model as OFF (which includes topology information), then I can import the OFF file into MeshLab, and it does not report any errors.
When I import the STL file into Netfabb Basic, it reports an error. When I import the OBJ file into Netfabb, the mesh is clean, no error. (My version of Netfabb doesn't read OFF files.)
Based on these tests, it appears that the problem is with the STL file format, not with the model.
Yes because STL is only for making real things, so it never needs to be
able to represent that physically impossible shape. I still can't see why
anybody would want to or why it is a problem. Just refuse to export in to
STL in OpenSCAD.
On Sat, 16 Nov 2019 at 13:04, Doug Moen doug@moens.org wrote:
On Fri, Nov 15, 2019, at 9:59 PM, Michael Marx wrote:
On the topic of, can we detect and/or fix it. I started with an edge.
Netfabb reports two 10x10x10 cubes with a shared edge, as having two
holes, and also highlights the edge as a self-intersection.
GUI repair doesn't fully fix it, the holes go away (ie the count in the
repair stats = 0), but there is still a self-intersection, on export it
shows:
The Netfabb export dialog says "Some file formats do not include enough
information. This may result in errors."
Translated, that means "The STL file format does not include topology
information. This may result in errors.". Most (all?) of the later mesh
file formats used for 3D printing include topology information. So we might
expect different results if we use a different file format.
I only have Netfabb Basic, which doesn't do automatic repairs, so I used
MeshLab instead for my first test.
In OpenSCAD, I exported this model:
cube(10); translate([10,10,0]) cube(10);
to STL.
When import into MeshLab, it detects corruption, and asks if I want to
repair it. The dialog says "Unify duplicated vertices?".
I say yes, and MeshLab performs the repair. Then I export to an OBJ file,
which includes topology information. Then, when I import that same OBJ file
into MeshLab, it does not report any errors.
If use OpenSCAD to export this model as OFF (which includes topology
information), then I can import the OFF file into MeshLab, and it does not
report any errors.
When I import the STL file into Netfabb Basic, it reports an error. When I
import the OBJ file into Netfabb, the mesh is clean, no error. (My version
of Netfabb doesn't read OFF files.)
Based on these tests, it appears that the problem is with the STL file
format, not with the model.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On Sat, Nov 16, 2019, at 9:07 AM, nop head wrote:
Yes because STL is only for making real things, so it never needs to be able to represent that physically impossible shape. I still can't see why anybody would want to or why it is a problem.
I will explain why I want this and why it is a problem.
First, most of the models I create contain curved surfaces. I can represent these models exactly in Curv (that's a big reason why I made the software), but when I export to a mesh format, it turns into a polyhedron. STL can't represent curved surfaces, it can only represent a polyhedral approximation. That doesn't mean that curved surfaces aren't "real".
Second, STL can represent most polyhedra (although not the 2 cubes polyhedron from my previous post). But polyhedra cannot exist in the real world, and they can't be 3D printed. All that you can ever print is an approximation of a polyhedron. My printer cannot print flat surfaces. What I get instead is a washboard ripple. My printer cannot print sharp edges: they are rounded off. In this sense, polyhedra can't be 3D printed, and the problems are readily visible to the naked eye.
It is possible to create physical representations of polyhedra that look visually perfect. For example, by using a mill, and machining a shape out of metal to micrometer precision. You can even make a visually perfect representation of the two cubes model. But if you examine the object at a high enough level of magnification, the surfaces aren't really flat, the edges aren't perfectly sharp, etc, because the object is made out of atoms. In this sense, polyhedra can't exist in the real world.
What I care about is solid modelling. I create mathematical abstractions of solid objects using software, then I 3D print physical approximations of them, to within the resolution limits of my printer. A true solid modelling program can represent any mathematically valid 3D solid. CAD programs that use boundary representation, instead of directly modelling solid objects, have limitations in what solid objects they can represent. The 2 cubes model is a mathematically valid polyhedron, but the boundary is not 2-manifold. That makes it hard to represent in STL, but that's only because STL uses a boundary representation. This issue has no relevance to 3D printing hardware, because 3D printers print solid objects, not boundaries or surfaces.
3D printing hardware is somewhat crippled by the software used to drive it. Most slicers only accept mesh representations of 3D solids, and that's a problem. We've already discussed one issue, which is STL's problem with representing the 2 cubes model. Other mesh formats like OBJ and 3MF solve that problem. The bigger problem is that the difficulty of processing a mesh grows non-linearly with the number of triangles in the mesh. Roughly speaking, that's because when you slice an object, you have to look at all of the triangles in the mesh at every slice. One consequence of this is that there exist complex models, with a lot of internal structure, that the 3D printer is physically capable of printing, but that you can't represent using a mesh, because the mesh would require too many triangles. And it's all because we are using a boundary representation, rather than a direct representation of a mathematical solid.
I've seen many reports of this problem in the industry. There is a 3D printer vendor in my city who sells metal powder printers. When I visited, the engineer showed me a very fine lattice printed out of titanium. What was interesting is that you cannot print this lattice from a mesh, because too many triangles would be required. The slicer runs out of memory or runs out of CPU. Instead, they use an alternative file format that is very close to a voxel format. Each slice is represented explicitly.
Shapeways has blogged about the limitations of mesh file formats.
https://www.shapeways.com/blog/archives/17972-shapeways-launches-svx-voxel-file-format-for-3d-printing.html
https://abfab3d.com/2015/02/27/voxels-versus-triangles/
I hope this provides people with more insight into the ways that the STL file format is holding back the 3D printer industry.
This is a followup to my explanation of some of the problems with STL. The question is: what file formats exist that fix these problems?
Today, the two most popular alternatives are OBJ and 3MF.
OBJ is a very simple, human readable mesh file format that includes topology information. It is very easy to write software that reads and writes this file format. It is, in my experience, the most widely supported non-STL mesh file format. I'm a bit mystified why OpenSCAD doesn't support it, because in my experience, everything else does.
3MF is a monstrously complicated format, but it has a lot of industry momentum behind it, and it is very expressive.
- 3MF includes topology information, so it fixes the problem with the "2 cubes" model.
- 3MF is the first 3D printer file format standard that is unambiguous. There is an algorithm for determining if a 3MF file is valid, and if it is valid, then there is a documented algorithm that slicers must use for interpreting the file. Prior to 3MF, there was a problem of portability of model files between different 3D printer slicers, where different slicers would interpret the same model in different ways. The rule that STL files must be "manifold" and must be free of self-intersections is the old way that we used to deal with the model portability problem. But most STL files on Thingiverse.com violate these rules anyway, so 3MF provides a more universal and robust solution to the model portability problem.
- A 3MF file can store multiple meshes, and 3MF directly supports dual- and multi-extruder, multi-material 3D printers.
- 3MF can store slicing parameters. That, plus the industry momentum, is the reason why Cura and Prusa Slicer now use 3MF as their native file format. If you import some meshes into Prusa Slicer, edit the slicing parameters, and then "Save" your model, you will get a 3MF file.
Next, there is the "too many triangles" problem, where you have models that can be printed by the physical 3D printer hardware, but which cannot be printed if you first have to convert it to a mesh.
A few years ago, Shapeways introduced the SVX voxel file format as a solution to the "too many triangles" problem. This directly addressed a problem that some of their customers had, being unable to print their models due to limitations of mesh file formats. SVX was not widely adopted. Then, behind the scenes, Shapeways was one of the groups involved in the 3MF committee, advocating for 3MF to support voxels. This advocacy has not yet been successful. The good thing about voxels is that it directly represents a 3D model as slices, which is very helpful for driving a 3D printer. The problem with voxels is that each slice is represented as an array of pixels. There are some voxel printers, that are driven directly by a voxel representation, but they are rare. Most 3D printers need to do motion planning to move a printhead or laser around while printing a layer, and a pixel representation of each layer is not directly useful for motion planning.
In 2016, 3MF added the "3MF Slice Extension". This represents the model as a stack of layers. Each layer is represented as a set of polygons. This looks like a viable solution to the "too many triangles" problem, as long as you aren't trying to drive a full colour multi-material voxel printer. But I don't know what the impact has been of this extension, or who supports it.
Finally, there are voxel printers, which I think are the most exciting trend in 3D printing hardware. A Stratasys J750 is a voxel printer that directly controls the colour, translucency, and rigidity of each voxel that it prints. The things you can do with it are incredible, and it should be obvious why STL is not a good file format for such a printer. The J750 is very expensive ($750,000). A more affordable alternative is the HP Jet Fusion, which prints full colour nylon from powder. Each voxel is separately coloured using an inkjet process. This is relatively new (2018). You can't currently control the transparency or rigidity of voxels, but the printer only costs $50,000, and the prints are much cheaper if you use a service bureau.
I am still hoping that we get industry support for a standard voxel file format for 3D printing. I think this becomes more likely as voxel printers become cheaper and more widely available. Stratasys just made a J750 available this year, and also this year, there are now service bureaus that offer full colour Jet Fusions. I think that voxels will be the ultimate replacement for STL.
doug.moen wrote
I will explain why I want this and why it is a problem.
That seems an understandable explanation of what is (for me) a very esoteric
topic.
What's not at all clear to me is why it might be necessary to do that sort
of thing with OpenSCAD? What proportion of OpneSCAD users would benefit from
it? What proportion of OpenSCAD users are even aware that the problem
exists?
...R
--
Sent from: http://forum.openscad.org/
On 2019-11-16 18:02, Doug Moen wrote:
OBJ is a very simple, human readable mesh file format that includes
topology information. It is very easy to write software that reads and
writes this file format. It is, in my experience, the most widely
supported non-STL mesh file format. I'm a bit mystified why OpenSCAD
doesn't support it, because in my experience, everything else does.
Agreed, this is a good format, it includes topology information and
still is just as simple as STL to read and write. AngelCAD reads &
writes OBJ, it is far superior to STL as an exchange format between CAD
applications.
Carsten Arnholm
How do voxel formats cope with different target machines, who's voxels
might be different sizes?
How does a voxel format represent the two cubes problem if the junction
doesn't lie on a voxel boundary?
There is an algorithm for determining if a 3MF file is valid, and if it is
valid, then there is a documented algorithm that slicers must use for
interpreting the file.
Yes but they seem to have chosen the wrong interpretation of self
intersections. I.e. exclusive oring overlapping solids instead of unioning
them. So at least slicers will be consistent, i.e. consistently wrong, so
forcing people to fix their models if they slice it with a compliant slicer
before publishing.
Even if models on Thingiverse are valid meshes I find most of them don't
have correct size holes, so are useless to me. Only arty things come out
right but I don't have use for many of those.
STL isn't mean't to be an interchange between CAD systems, just CAD systems
and slicers. I think most slicers would accept OBJ though, so it might be
worth adding it to OpenSCAD.
On Sat, 16 Nov 2019 at 17:05, Doug Moen doug@moens.org wrote:
This is a followup to my explanation of some of the problems with STL. The
question is: what file formats exist that fix these problems?
Today, the two most popular alternatives are OBJ and 3MF.
OBJ is a very simple, human readable mesh file format that includes
topology information. It is very easy to write software that reads and
writes this file format. It is, in my experience, the most widely supported
non-STL mesh file format. I'm a bit mystified why OpenSCAD doesn't support
it, because in my experience, everything else does.
3MF is a monstrously complicated format, but it has a lot of industry
momentum behind it, and it is very expressive.
- 3MF includes topology information, so it fixes the problem with the "2
cubes" model. - 3MF is the first 3D printer file format standard that is unambiguous.
There is an algorithm for determining if a 3MF file is valid, and if it is
valid, then there is a documented algorithm that slicers must use for
interpreting the file. Prior to 3MF, there was a problem of portability of
model files between different 3D printer slicers, where different slicers
would interpret the same model in different ways. The rule that STL files
must be "manifold" and must be free of self-intersections is the old way
that we used to deal with the model portability problem. But most STL files
on Thingiverse.com violate these rules anyway, so 3MF provides a more
universal and robust solution to the model portability problem. - A 3MF file can store multiple meshes, and 3MF directly supports dual-
and multi-extruder, multi-material 3D printers. - 3MF can store slicing parameters. That, plus the industry momentum, is
the reason why Cura and Prusa Slicer now use 3MF as their native file
format. If you import some meshes into Prusa Slicer, edit the slicing
parameters, and then "Save" your model, you will get a 3MF file.
Next, there is the "too many triangles" problem, where you have models
that can be printed by the physical 3D printer hardware, but which cannot
be printed if you first have to convert it to a mesh.
A few years ago, Shapeways introduced the SVX voxel file format as a
solution to the "too many triangles" problem. This directly addressed a
problem that some of their customers had, being unable to print their
models due to limitations of mesh file formats. SVX was not widely adopted.
Then, behind the scenes, Shapeways was one of the groups involved in the
3MF committee, advocating for 3MF to support voxels. This advocacy has not
yet been successful. The good thing about voxels is that it directly
represents a 3D model as slices, which is very helpful for driving a 3D
printer. The problem with voxels is that each slice is represented as an
array of pixels. There are some voxel printers, that are driven directly by
a voxel representation, but they are rare. Most 3D printers need to do
motion planning to move a printhead or laser around while printing a layer,
and a pixel representation of each layer is not directly useful for motion
planning.
In 2016, 3MF added the "3MF Slice Extension". This represents the model as
a stack of layers. Each layer is represented as a set of polygons. This
looks like a viable solution to the "too many triangles" problem, as long
as you aren't trying to drive a full colour multi-material voxel printer.
But I don't know what the impact has been of this extension, or who
supports it.
Finally, there are voxel printers, which I think are the most exciting
trend in 3D printing hardware. A Stratasys J750 is a voxel printer that
directly controls the colour, translucency, and rigidity of each voxel that
it prints. The things you can do with it are incredible, and it should be
obvious why STL is not a good file format for such a printer. The J750 is
very expensive ($750,000). A more affordable alternative is the HP Jet
Fusion, which prints full colour nylon from powder. Each voxel is
separately coloured using an inkjet process. This is relatively new (2018).
You can't currently control the transparency or rigidity of voxels, but the
printer only costs $50,000, and the prints are much cheaper if you use a
service bureau.
I am still hoping that we get industry support for a standard voxel file
format for 3D printing. I think this becomes more likely as voxel printers
become cheaper and more widely available. Stratasys just made a J750
available this year, and also this year, there are now service bureaus that
offer full colour Jet Fusions. I think that voxels will be the ultimate
replacement for STL.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 16.11.19 19:44, nop head wrote:
STL isn't mean't to be an interchange between CAD
systems, just CAD systems and slicers. I think most
slicers would accept OBJ though, so it might be
worth adding it to OpenSCAD.
The question is not so much if it's worth it, but if
someone cares enough to actually spend the time to
DO it.
There's an old unfinished branch waiting to be picked
up and some discussion in issue #351
( see https://github.com/openscad/openscad/issues/351 )
I'm not sure it's worth it. Support for more file
formats is generally not a bad idea though.
ciao,
Torsten.