Polyhedron STL export creates bad faces (sometimes)

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

Polyhedron STL export creates bad faces (sometimes)

peetersm
For the purpose of this post a STL "bad face" has multiple overlapping
triangles. I want to 3D print these files so due to polyhedron's poor STL
export, I always have to import them into blender and re-export them which
works if there are no "bad faces". But when some "bad faces" exist it, then
even after the blender import-export, it breaks my slicer program so I can't
3D print these files. Removing the extra triangles is a lot of manual clean
up in blender, and will result in a printable STL file.

AND I say (sometimes) because I'm having trouble identifying exactly when
these extra triangles are generated, but I think it has something to do with
right angles, aligned to the origin, or square faces with at least two sides
parallel to an origin direction.??maybe??

In order to investigate this behavior I made a simple cube built from
triangles. Each face of the cube is made of two triangles. The exported STL
file should also need only two triangles per face. BUT (sometimes) a face
will render as 4 triangles overlapping. If the cube's faces are all aligned
with the origin planes then all 6 faces will be "bad faces". If the cube is
rotated by a non-multiple of 90 degrees in any direction then these faces
will be "good faces" while the other faces remain as "bad
faces"...sometimes...
Code is below as well as a photo of blender showing the "bad face" vs "good
face".

Any help is greatly appreciated, I tried finding an issue on github and
searched the forum but I think I don't know how to describe this properly to
discover if there is a documented solution or issue.

//test polyhedron
cubeTri();//all bad faces
translate([20,0,0])rotate([1,0,0])cubeTri();//good face y-z plane
translate([0,20,0])rotate([0,1,0])cubeTri();//good face x-z plane
translate([0,0,20])rotate([0,0,1])cubeTri();//good face x-y plane
translate([20,20,0])rotate([1,1,0])cubeTri();//good face ALL planes
translate([0,20,20])rotate([0,1,1])cubeTri();//good face ALL planes
translate([20,0,20])rotate([1,0,1])cubeTri();//good face x-y and y-z planes
translate([20,20,20])rotate([1,1,1])cubeTri();//good face ALL planes

// make a simple cube(10) out of triangles
module cubeTri(){
color("red")        polyhedron
(points=[[0,0,0],[0,10,0],[0,10,10]],faces=[[0,1,2]]);
color("darkred")    polyhedron
(points=[[0,0,0],[0,10,10],[0,0,10]],faces=[[0,1,2]]);
color("yellow")     polyhedron
(points=[[10,0,0],[10,10,0],[10,10,10]],faces=[[0,1,2]]);
color("lightyellow")polyhedron
(points=[[10,0,0],[10,10,10],[10,0,10]],faces=[[0,1,2]]);
color("green")      polyhedron
(points=[[0,0,10],[0,10,10],[10,10,10]],faces=[[0,1,2]]);
color("lightgreen") polyhedron
(points=[[0,0,10],[10,10,10],[10,0,10]],faces=[[0,1,2]]);
color("magenta")    polyhedron
(points=[[0,10,0],[10,10,0],[10,10,10]],faces=[[0,1,2]]);  
color("darkmagenta")polyhedron
(points=[[0,10,0],[10,10,10],[0,10,10]],faces=[[0,1,2]]);
color("pink")       polyhedron
(points=[[0,0,0],[10,0,0],[10,0,10]],faces=[[0,1,2]]);  
color("deeppink")   polyhedron
(points=[[0,0,0],[10,0,10],[0,0,10]],faces=[[0,1,2]]);
color("purple")     polyhedron
(points=[[0,0,0],[0,10,0],[10,10,0]],faces=[[0,1,2]]);
color("Indigo")     polyhedron
(points=[[0,0,0],[10,10,0],[10,0,0]],faces=[[0,1,2]]);  
}

<http://forum.openscad.org/file/t709/bad-good-face.jpg>




--
Sent from: http://forum.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: Polyhedron STL export creates bad faces (sometimes)

Parkinbot
The reason, why you get bad face STLs is simply: You create them with wrongly
oriented faces. Preview your polyhedron with F12. Every face display in
magenta has wrong orientation. To swap orientation, define the vertices in
reversed order.



--
Sent from: http://forum.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: Polyhedron STL export creates bad faces (sometimes)

thehans
In reply to this post by peetersm
Polyhedron is meant to define a self-contained solid object, I don't
think behavior is well defined if you are using it to define
individual triangles one-by-one.
Also the winding order of each triangle matters, if the order of
vertices for a triangle not in the correct order, the face will be
inside-out.

On Sat, Feb 17, 2018 at 11:12 AM, peetersm <[hidden email]> wrote:

> For the purpose of this post a STL "bad face" has multiple overlapping
> triangles. I want to 3D print these files so due to polyhedron's poor STL
> export, I always have to import them into blender and re-export them which
> works if there are no "bad faces". But when some "bad faces" exist it, then
> even after the blender import-export, it breaks my slicer program so I can't
> 3D print these files. Removing the extra triangles is a lot of manual clean
> up in blender, and will result in a printable STL file.
>
> AND I say (sometimes) because I'm having trouble identifying exactly when
> these extra triangles are generated, but I think it has something to do with
> right angles, aligned to the origin, or square faces with at least two sides
> parallel to an origin direction.??maybe??
>
> In order to investigate this behavior I made a simple cube built from
> triangles. Each face of the cube is made of two triangles. The exported STL
> file should also need only two triangles per face. BUT (sometimes) a face
> will render as 4 triangles overlapping. If the cube's faces are all aligned
> with the origin planes then all 6 faces will be "bad faces". If the cube is
> rotated by a non-multiple of 90 degrees in any direction then these faces
> will be "good faces" while the other faces remain as "bad
> faces"...sometimes...
> Code is below as well as a photo of blender showing the "bad face" vs "good
> face".
>
> Any help is greatly appreciated, I tried finding an issue on github and
> searched the forum but I think I don't know how to describe this properly to
> discover if there is a documented solution or issue.
>
> //test polyhedron
> cubeTri();//all bad faces
> translate([20,0,0])rotate([1,0,0])cubeTri();//good face y-z plane
> translate([0,20,0])rotate([0,1,0])cubeTri();//good face x-z plane
> translate([0,0,20])rotate([0,0,1])cubeTri();//good face x-y plane
> translate([20,20,0])rotate([1,1,0])cubeTri();//good face ALL planes
> translate([0,20,20])rotate([0,1,1])cubeTri();//good face ALL planes
> translate([20,0,20])rotate([1,0,1])cubeTri();//good face x-y and y-z planes
> translate([20,20,20])rotate([1,1,1])cubeTri();//good face ALL planes
>
> // make a simple cube(10) out of triangles
> module cubeTri(){
> color("red")        polyhedron
> (points=[[0,0,0],[0,10,0],[0,10,10]],faces=[[0,1,2]]);
> color("darkred")    polyhedron
> (points=[[0,0,0],[0,10,10],[0,0,10]],faces=[[0,1,2]]);
> color("yellow")     polyhedron
> (points=[[10,0,0],[10,10,0],[10,10,10]],faces=[[0,1,2]]);
> color("lightyellow")polyhedron
> (points=[[10,0,0],[10,10,10],[10,0,10]],faces=[[0,1,2]]);
> color("green")      polyhedron
> (points=[[0,0,10],[0,10,10],[10,10,10]],faces=[[0,1,2]]);
> color("lightgreen") polyhedron
> (points=[[0,0,10],[10,10,10],[10,0,10]],faces=[[0,1,2]]);
> color("magenta")    polyhedron
> (points=[[0,10,0],[10,10,0],[10,10,10]],faces=[[0,1,2]]);
> color("darkmagenta")polyhedron
> (points=[[0,10,0],[10,10,10],[0,10,10]],faces=[[0,1,2]]);
> color("pink")       polyhedron
> (points=[[0,0,0],[10,0,0],[10,0,10]],faces=[[0,1,2]]);
> color("deeppink")   polyhedron
> (points=[[0,0,0],[10,0,10],[0,0,10]],faces=[[0,1,2]]);
> color("purple")     polyhedron
> (points=[[0,0,0],[0,10,0],[10,10,0]],faces=[[0,1,2]]);
> color("Indigo")     polyhedron
> (points=[[0,0,0],[10,10,0],[10,0,0]],faces=[[0,1,2]]);
> }
>
> <http://forum.openscad.org/file/t709/bad-good-face.jpg>
>
>
>
>
> --
> Sent from: http://forum.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: Polyhedron STL export creates bad faces (sometimes)

cacb
In reply to this post by peetersm
On 17. feb. 2018 18:12, peetersm wrote:
> Any help is greatly appreciated, I tried finding an issue on github and
> searched the forum but I think I don't know how to describe this properly to
> discover if there is a documented solution or issue.

Your code illustrate 2 important issues

1) a polyhedron cannot contain a single face and be valid, it must have
at least 4 faces to define a closed volume.

Looking at your code, it will necessarily fail. This is because you
define several polyhedra with only one face in each. Clearly these are
not closed volumes. To define a single polyhedron equivalent to a cube,
you must first list 8 points (one for each corner) and then list 6
rectangular (or 12 triangular) faces, all in the same polyhedron,
referring to the point indices using the rules described below.

So, your cubeTri() module should define one polyhedron, not 12.


2) The face normals of any polyhedron must be properly oriented.

The face normal of any polyhedron face defines where the solid material
is relative to the face (inside or outside). The solid material is on
the opposite side of where the face normal is pointing. When one or more
of the face normals points inwards, the polyhedron is not describing a
closed volume.

The orientation of a face normal is defined from the winding order of
the face vertices (=points): In OpenSCAD you must list the face vertices
in clockwise order (as seen from outside) for the face normal to be
properly pointing outwards. This must be true for all the faces in a
polyhedron, or else the polyhedron does not really define a closed
volume, and will fail.


For simple shapes like cubes it is much easier to simply use the cube()
command, as it is much less work and rules 1) and 2) will be taken care
of automatically. If you use polyhedron() you have to apply rules 1) and
2) yourself.


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: Polyhedron STL export creates bad faces (sometimes)

peetersm
Thanks everyone for the quick replies. I have the following observations.

about the NORMAL or WINDING ORDER:
1. I don't agree that this is causing the "bad faces" since I can eliminate generation of "bad faces" by simply rotating the object which does not change the winding order.
2. I did correct the winding order on all the faces and the results were identical.
3. Incorrect winding order may cause other issues, but that is not related to this "bad face" issue.

about the "A SINGLE FACE DOES NOT A POLYHEDRON MAKE":
1. I rewrote the code so that I am not making faces but a closed surface and it works.
2. I was using polyhedron in a way that causes inconsistent results when rendering. :-(

Of course I was not trying to make cubes but some complicated shapes from formulas. This cube idea was just a debugging exercise to try to understand why it's behavior is not consistent. 

---updated code that works--
//test polyhedron - don't make faces

cubeTriAll();//it works

p0=[0,0,0];//bottom origin 7:30 0'clock
p1=[0,10,0];//bottom 10:30 0'clock
p2=[10,10,0];//bottom 1:30 0'clock
p3=[10,0,0];//bottom 4:30 0'clock
p4=[0,0,10];//top origin 7:30 0'clock
p5=[0,10,10];//top 10:30 0'clock
p6=[10,10,10];//top 1:30 0'clock
p7=[10,0,10];//top 4:30 0'clock 

f0=[0,2,1];//bottom1
f1=[0,3,2];//bottom2
f2=[0,1,5];//left1
f3=[0,5,4];//left2
f4=[1,6,5];//away1
f5=[1,2,6];//away2
f6=[2,3,7];//right1
f7=[2,7,6];//right2
f8=[0,4,7];//front1
f9=[0,7,3];//front2
f10=[4,5,6];//top1
f11=[4,6,7];//top2

module cubeTriAll(){
polyhedron (points=[p0,p1,p2,p3,p4,p5,p6,p7],faces=[f0,f1,f2,f3,f4,f5,f6,f7,f8,f9,f10,f11]);
}




On Sat, Feb 17, 2018 at 1:36 PM, Carsten Arnholm <[hidden email]> wrote:
On 17. feb. 2018 18:12, peetersm wrote:
Any help is greatly appreciated, I tried finding an issue on github and
searched the forum but I think I don't know how to describe this properly to
discover if there is a documented solution or issue.

Your code illustrate 2 important issues

1) a polyhedron cannot contain a single face and be valid, it must have at least 4 faces to define a closed volume.

Looking at your code, it will necessarily fail. This is because you define several polyhedra with only one face in each. Clearly these are not closed volumes. To define a single polyhedron equivalent to a cube, you must first list 8 points (one for each corner) and then list 6 rectangular (or 12 triangular) faces, all in the same polyhedron, referring to the point indices using the rules described below.

So, your cubeTri() module should define one polyhedron, not 12.


2) The face normals of any polyhedron must be properly oriented.

The face normal of any polyhedron face defines where the solid material is relative to the face (inside or outside). The solid material is on the opposite side of where the face normal is pointing. When one or more of the face normals points inwards, the polyhedron is not describing a closed volume.

The orientation of a face normal is defined from the winding order of the face vertices (=points): In OpenSCAD you must list the face vertices in clockwise order (as seen from outside) for the face normal to be properly pointing outwards. This must be true for all the faces in a polyhedron, or else the polyhedron does not really define a closed volume, and will fail.


For simple shapes like cubes it is much easier to simply use the cube() command, as it is much less work and rules 1) and 2) will be taken care of automatically. If you use polyhedron() you have to apply rules 1) and 2) yourself.


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
Reply | Threaded
Open this post in threaded view
|

Re: Polyhedron STL export creates bad faces (sometimes)

NateTG
peetersm wrote
> Thanks everyone for the quick replies. I have the following observations.
>
>
> about the NORMAL or WINDING ORDER:
> 1. I don't agree that this is causing the "bad faces" since I can
> eliminate generation of "bad faces" by simply rotating the object which
> does not change the winding order.
> ...

In a sense, I agree with you.  IMO OpenSCAD should have just had an error or
produced an empty STL from those polyhedron calls.   "Winding order" really
only makes sense as an issue if you've got a connected surface with more
than one face.




--
Sent from: http://forum.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: Polyhedron STL export creates bad faces (sometimes)

cacb
On 2018-02-18 02:46, NateTG wrote:

> peetersm wrote
>> Thanks everyone for the quick replies. I have the following
>> observations.
>>
>>
>> about the NORMAL or WINDING ORDER:
>> 1. I don't agree that this is causing the "bad faces" since I can
>> eliminate generation of "bad faces" by simply rotating the object
>> which
>> does not change the winding order.
>> ...
>
> In a sense, I agree with you.  IMO OpenSCAD should have just had an
> error or
> produced an empty STL from those polyhedron calls.   "Winding order"
> really
> only makes sense as an issue if you've got a connected surface with
> more
> than one face.

A polyhedron with less than 4 faces is not a closed surface, and
therefore cannot describe a closed volume. Since the face winding order
is relative to a viewpoint outside of the closed volume, it follows that
the winding order is undefined for a polyhedron with less than 4 faces.
The error that should have been flagged in this case is that the
polyhedron calls had less than 4 faces, it is always an error.

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: Polyhedron STL export creates bad faces (sometimes)

Parkinbot
cacb wrote
> The error that should have been flagged in this case is that the
> polyhedron calls had less than 4 faces, it is always an error.

Carsten, again, I disagree with you. We had this discussion before.
Non-manifold polyhedra make sense, even for STL export. OpenSCAD
could/should give a warning at export, because a non-manifold polyhedron
might not be 3D-printable - which in turn depends on the slicer or the post
processing tool.
I can image to export a bunch of somehow arranged faces as STL and use a
postprocessor to fab something out of this structure - e.g. to feed a laser
cutter. Would that be an error?

Peter, you can test your polyhedron for 3D-printability by writing

polyhedron(verts, faces);
cube();

CGAL will give you an error if the polyhedron is non-manifold. It is as
simple as this.




--
Sent from: http://forum.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: Polyhedron STL export creates bad faces (sometimes)

cacb
On 2018-02-18 11:08, Parkinbot wrote:
> cacb wrote
>> The error that should have been flagged in this case is that the
>> polyhedron calls had less than 4 faces, it is always an error.
>
> Carsten, again, I disagree with you. We had this discussion before.

Fair enough, we disagree. OpenSCAD is a solid modeller based around the
Constructive Solid Geometry modelling technique. For that you need
solids.

My comment relates to the often seen situation described by the original
poster in this thread.

> I can image to export a bunch of somehow arranged faces as STL and use
> a
> postprocessor to fab something out of this structure - e.g. to feed a
> laser
> cutter. Would that be an error?

It is not solid modelling. A solid modeller should warn when used in a
way inconsistent with its stated objective. In 99% of the cases what you
describe is an unintended mistake.

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: Polyhedron STL export creates bad faces (sometimes)

Parkinbot
I agree with the warning.



--
Sent from: http://forum.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: Polyhedron STL export creates bad faces (sometimes)

NateTG
OpenSCAD is a surface modeler that pretends to be a solid modeler.    The
question is really how aggressively you want it to pretend.

If stitching together volumes from surface patches is desired, then I'm not
sure it should be done with something called 'polyhedron.'  


> ... Non-manifold polyhedra make sense, even for STL export. ...

STL is also surface - rather than space - modeling.  And, although the STL
format has its merits, I don't think "it makes sense in STL" is a good
argument for (or against) having a particular behavior in the modeling
software.




--
Sent from: http://forum.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: Polyhedron STL export creates bad faces (sometimes)

peetersm
In reply to this post by Parkinbot
I'm fascinated that it breaks differently based on the position of the object
in space. Also glad it outputs anything at all, even when I am making a 2d
face with a 3d command.


Parkinbot wrote
> Peter, you can test your polyhedron for 3D-printability by writing
>
> polyhedron(verts, faces);
> cube();
>
> CGAL will give you an error if the polyhedron is non-manifold. It is as
> simple as this.

Parkinbot when I do use polyhedron to make a closed 3D object (not just
faces) it does work for 3d printing.

BUT looks like i can't do differences or intersections. (hull still works)

//this just makes the cube - difference or intersection is ignored
difference(){
polyhedron
(points=[p0,p1,p2,p3,p4,p5,p6,p7],faces=[f0,f1,f2,f3,f4,f5,f6,f7,f8,f9,f10,f11]);
translate([5,5,5])cube(10);}

p0=[0,0,0];//bottom origin 7:30 0'clock
p1=[0,10,0];//bottom 10:30 0'clock
p2=[10,10,0];//bottom 1:30 0'clock
p3=[10,0,0];//bottom 4:30 0'clock
p4=[0,0,10];//top origin 7:30 0'clock
p5=[0,10,10];//top 10:30 0'clock
p6=[10,10,10];//top 1:30 0'clock
p7=[10,0,10];//top 4:30 0'clock

f0=[0,2,1];//bottom1
f1=[0,3,2];//bottom2
f2=[0,1,5];//left1
f3=[0,5,4];//left2
f4=[1,6,5];//away1
f5=[1,2,6];//away2
f6=[2,3,7];//right1
f7=[2,7,6];//right2
f8=[0,4,7];//front1
f9=[0,7,3];//front2
f10=[4,5,6];//top1
f11=[4,6,7];//top2




--
Sent from: http://forum.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: Polyhedron STL export creates bad faces (sometimes)

Parkinbot
peetersm wrote
> BUT looks like i can't do differences or intersections. (hull still works)

Hmm, your code produces a watertight object. The Boolean operation passes
CGAL (F6) without any problems. Therefore an STL-export will be
3D-printable.
You might have been mislead by F12 (combined) view, which does not show the
result of Boolean operations as you might expect it. I use F12 only to check
for polyhedron correctness. So: use F5 for preview, F12 for orientation
checks and F6 (plus a dummy Boolean operation) for watertight check and STL
correctness of a polyhedron.  

@NateTG
I agree that polyhedron() and polygon() stand out from all other primitives
offered by OpenSCAD. This is because they are meant for user-defined stuff -
and thus they indeed provide functionality that allow more experienced users
to squeeze out a lot more from OpenSCAD not covered by the core concepts. In
my eyes they provide about 50% of the power of OpenSCAD, while the other 50%
are Boolean operations. I wouldn't need more to do my work.

In this forum regularly appear posts that demand a closure of these
primitives as they admittedly open a can of worms and bust the CSG paradigm,
which by the way also all the other 2D-primivites do. The argument is always
that a less experienced user might stumble over this or that and that some
posts could have been avoided, if OpenSCAD had a somehow more watertight
implementation.  

Clearly, one could imagine implementations of these primitives that
immediately throw errors in case a non-simple polygon or some non-watertight
or wrongly oriented polyhedron is constructed. While this would severly
break existing code it would also prevent output essential for "learning by
doing" when working with these concepts. I am convinced that such a closure
wouldn't help less experienced users, but rather lead to an even steeper
learning curve. On the other side, it would block more experienced users to
do their stuff.
OpenSCAD is not only used to produce STLs for print. A lot of people,
including me, use it to do fancy animations and other "exotic" stuff, like
visualizing Math. Why should this creative "extra" functionality be blocked?

I am always a friend of warnings, because they give valuable hints. Of
course they have to be taken serious, which is not always the case -
especially by less experienced users, who often don't know which
implications a certain warning has. To face this, a beginners/experienced
user mode switch could be introduced. But wouldn't such a switch trigger
posts from people, who don't know about its existence?

I think this forum is enough means to give help and communicate the ways and
tricks for sailing around the different cliffs of OpenSCAD. Procrusting its
scope, or even boarding it up, won't serve any needs.  






--
Sent from: http://forum.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: Polyhedron STL export creates bad faces (sometimes)

JordanBrown
On 2/20/2018 3:53 AM, Parkinbot wrote:
In this forum regularly appear posts that demand a closure of these primitives as they admittedly open a can of worms and bust the CSG paradigm, which by the way also all the other 2D-primivites do. The argument is always that a less experienced user might stumble over this or that and that some posts could have been avoided, if OpenSCAD had a somehow more watertight implementation.

[...] On the other side, it would block more experienced users to do their stuff.


By all means, have primitives that let you build exotic structures.

But "polyhedron" is an English word with a meaning and shouldn't be abused for structures that are not polyhedra.


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

Re: Polyhedron STL export creates bad faces (sometimes)

cacb
On 21. feb. 2018 18:55, Jordan Brown wrote:
> By all means, have primitives that let you build exotic structures.
>
> But "polyhedron" is an English word with a meaning and shouldn't be
> abused for structures that are not polyhedra.

Exactly my point.

Carsten Arnholm


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