Working with imported STLs
I recently tried to bring in an STL with an import command and then slice it
up using difference commands in order to get something that I could make a
multicolor part. I know I've done something like this in the past and had
it work, but even though I was able to quick render OK (F5) a full render
seemed to ignore the differencing that I had done. Is there some sort of
restriction on using difference() on imported objects?
Using: 2018.03.17 (git 3e7fbfff)
--
Sent from: http://forum.openscad.org/
Not as such.
Most issues with imported STLs is they are bad, not your day for 'bad'...
Bad can be many things, self-intersecting faces, non-manifold (holes in the
mesh) are the two most common problems.
If you can share the STL files I can have a look.
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Sent from: http://forum.openscad.org/
On 16/04/18 02:11, MichaelAtOz wrote:
Bad can be many things, self-intersecting faces, non-manifold (holes in the
mesh) are the two most common problems.
I have about a 25% success rate of being able to "edit" imported STLs
with OpenSCAD.
I now know to slice them with some simple planes and hit F6 before
trying anything fancy.
My success rate at repairing with online tools and/or meshmixer is zero.
Ian
Gadgetmind wrote
I now know to slice them with some simple planes and hit F6 before
trying anything fancy.
Just adding a cube() to cause an implicit union() then F6 rendering, is
enough to get a CGAL error, if the STL is not good.
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Sent from: http://forum.openscad.org/
On 16 April 2018 at 10:58, kerog kerog777@gmail.com wrote:
I recently tried to bring in an STL with an import command and then slice it
up using difference commands in order to get something that I could make a
multicolor part. I know I've done something like this in the past and had
it work, but even though I was able to quick render OK (F5) a full render
seemed to ignore the differencing that I had done. Is there some sort of
restriction on using difference() on imported objects?
The way I understand it, OpenSCAD doesn't work this way.
When you design parts with code using CSG then export them to a
manifold mesh, the triangles which make up the mesh are generated at
export time. Everything is (hopefully) a valid manifold shape.
However, when you import an STL you're bringing in a manifold mesh
which is a fixed object. OpenSCAD doesn't see the STL as a CSG object
which it can modify.
Then you erase parts of the STL or tack bits on. When the mesh is
generated at export time, your CSG objects have their triangles
created plus the STL (or what's left of it) is defined as a separate
shape to the SCAD CSG objects.
For example, if you a hole in an STL file, you've essentially just
erased a bunch of vertices and faces, so the part is not a manifold
mesh anymore, plus OpenSCAD has added the "shell" of the hole as a
separate mesh. It looks okay to the eye but as far as the software is
concerned it's not okay at all.
You can run STLs made this way through NetFabb Online Service with a
reasonable degree of success: https://service.netfabb.com/
However, I find it better to use Riham's STL-to-SCAD converter:
http://jsfiddle.net/Riham/yzvGD/
This converts the triangles of an STL mesh into an OpenSCAD polyhedron
which IS then seen as a CSG object just like any other cube() or
cylinder() or sphere().
Now you can cut parts out of that polyhedron or add parts to it and,
providing you code your difference()s and union()s correctly, OpenSCAD
can generate a valid manifold mesh on export.
STLs with high triangle counts will result in complex polyhedrons
which will make your PC chug. Consider reducing the triangle count
(known as "decimating") if it doesn't affect your part quality or
dimensions too much. You can do this with MeshLab which is also Free
Software: https://www.shapeways.com/tutorials/polygon_reduction_with_meshlab
Jamie
This isn't true at all. An imported STL file that was manifold and had no
degenerate triangles produces just the same data structure as a polyhedron
or cylinder. OpenSCAD doesn't store objects as CSG objects, except in the
source code. I stores them using a boundary representation that is just a
fancy mesh. That is why cylinders are always faceted. They are only true
cylinders in the source code or the csg tree. To render them they are
converted to polyhedra. The only difference when exporting to STL is any
facets with more than three vertices are triangulated and the vertices
truncated to floats.
On 16 April 2018 at 11:50, Jamie Bainbridge jamie.bainbridge@gmail.com
wrote:
On 16 April 2018 at 10:58, kerog kerog777@gmail.com wrote:
I recently tried to bring in an STL with an import command and then
slice it
up using difference commands in order to get something that I could make
a
multicolor part. I know I've done something like this in the past and
had
it work, but even though I was able to quick render OK (F5) a full render
seemed to ignore the differencing that I had done. Is there some sort of
restriction on using difference() on imported objects?
The way I understand it, OpenSCAD doesn't work this way.
When you design parts with code using CSG then export them to a
manifold mesh, the triangles which make up the mesh are generated at
export time. Everything is (hopefully) a valid manifold shape.
However, when you import an STL you're bringing in a manifold mesh
which is a fixed object. OpenSCAD doesn't see the STL as a CSG object
which it can modify.
Then you erase parts of the STL or tack bits on. When the mesh is
generated at export time, your CSG objects have their triangles
created plus the STL (or what's left of it) is defined as a separate
shape to the SCAD CSG objects.
For example, if you a hole in an STL file, you've essentially just
erased a bunch of vertices and faces, so the part is not a manifold
mesh anymore, plus OpenSCAD has added the "shell" of the hole as a
separate mesh. It looks okay to the eye but as far as the software is
concerned it's not okay at all.
You can run STLs made this way through NetFabb Online Service with a
reasonable degree of success: https://service.netfabb.com/
However, I find it better to use Riham's STL-to-SCAD converter:
http://jsfiddle.net/Riham/yzvGD/
This converts the triangles of an STL mesh into an OpenSCAD polyhedron
which IS then seen as a CSG object just like any other cube() or
cylinder() or sphere().
Now you can cut parts out of that polyhedron or add parts to it and,
providing you code your difference()s and union()s correctly, OpenSCAD
can generate a valid manifold mesh on export.
STLs with high triangle counts will result in complex polyhedrons
which will make your PC chug. Consider reducing the triangle count
(known as "decimating") if it doesn't affect your part quality or
dimensions too much. You can do this with MeshLab which is also Free
Software: https://www.shapeways.com/tutorials/polygon_reduction_
with_meshlab
Jamie
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
NewDomeCity1.stl http://forum.openscad.org/file/t873/NewDomeCity1.stl
The idea was to turn this into a dual extrusion piece by adding in the panes
of the dome to print in a second color (transparent).
city-tile_v4.stl http://forum.openscad.org/file/t873/city-tile_v4.stl
Also, with this one I was looking at making the base one color and then the
three buildings different colors. I'm playing with a Mosaic Palette+ and
trying to see what I can do with the 4-color capabilities.
I believe both of these models had problems when I tried to cut them up
after importing.
--
Sent from: http://forum.openscad.org/
On 16 April 2018 at 21:48, nop head nop.head@gmail.com wrote:
This isn't true at all. An imported STL file that was manifold and had no
degenerate triangles produces just the same data structure as a polyhedron
or cylinder.
Cool, thanks for the correction, that's good to know.
I guess I've just been using dodgy STLs in the past then.
Jamie
Yes OpenSCAD needs perfect STL files, including no degenerate triangles,
which it even produces itself if vertices are very close together such that
they collapse when truncated to floats. Other programs can cope with them.
On 16 April 2018 at 22:46, Jamie Bainbridge jamie.bainbridge@gmail.com
wrote:
On 16 April 2018 at 21:48, nop head nop.head@gmail.com wrote:
This isn't true at all. An imported STL file that was manifold and had no
degenerate triangles produces just the same data structure as a
polyhedron
or cylinder.
Cool, thanks for the correction, that's good to know.
I guess I've just been using dodgy STLs in the past then.
Jamie
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
kerog wrote
NewDomeCity1.stl
city-tile_v4.stl
I believe both of these models had problems when I tried to cut them up
after importing.
Yep, both are problematic.
You should get netfabb Studio Basic, it can help see problems, and fix many,
but not all.
It fixed city-tile_v4.stl.
city-tile_v4_fixed.stl
http://forum.openscad.org/file/t359/city-tile_v4_fixed.stl
NewDomeCity1.stl has lots of problems, not easily fixed:
http://forum.openscad.org/file/t359/NewDomeCity1.jpg
Anything not blue or black is bad.
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Sent from: http://forum.openscad.org/