Replacement control knob for gas hob
Can anyone help me understand why the thread I started, which had two replies,
appears to have absorbed many more posts headed 'path_sweep problem'?
I thought it might be down to some setting I've configured incorrectly in my PC
Email app, 'Agent', but Empathy appears to have done the same thing.
Screenshot attached or here:
https://www.dropbox.com/sh/2yris8vshzhzxqo/AABa9jfTtNsWuh3062KA18sla?raw=1
P.S. I'm not the 'TP' in the Empathy site.
No idea. It looks normal in Gmail. I.e. Six messages in this thread, two
from David and the rest from you.
[image: image.png]
On Tue, 8 Feb 2022 at 17:44, Terry terrypingm@gmail.com wrote:
Can anyone help me understand why the thread I started, which had two
replies,
appears to have absorbed many more posts headed 'path_sweep problem'?
I thought it might be down to some setting I've configured incorrectly in
my PC
Email app, 'Agent', but Empathy appears to have done the same thing.
Screenshot attached or here:
https://www.dropbox.com/sh/2yris8vshzhzxqo/AABa9jfTtNsWuh3062KA18sla?raw=1
P.S. I'm not the 'TP' in the Empathy site.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Correcting that link to the Empathy screenshot:
https://www.dropbox.com/s/ietj6mmux88j870/ThreadPuzzle.jpg?raw=1
On Tue, 8 Feb 2022 at 17:43, Terry terrypingm@gmail.com wrote:
Can anyone help me understand why the thread I started, which had two
replies,
appears to have absorbed many more posts headed 'path_sweep problem'?
I thought it might be down to some setting I've configured incorrectly in
my PC
Email app, 'Agent', but Empathy appears to have done the same thing.
Screenshot attached or here:
https://www.dropbox.com/sh/2yris8vshzhzxqo/AABa9jfTtNsWuh3062KA18sla?raw=1
P.S. I'm not the 'TP' in the Empathy site.
--
LargePrefPlaceholder-XKUz1MEJBwkOM
On 08.02.22 18:43, Terry wrote:
Can anyone help me understand why the thread I started,
which had two replies, appears to have absorbed many more
posts headed 'path_sweep problem'?
That is because the mail headers say so:
Message-Id: CCD315DA-55DD-4AE6-A506-1C97AFB35EDE@gmail.com
Subject: [OpenSCAD] Re: Replacement control knob for gas hob
and
In-Reply-To: CCD315DA-55DD-4AE6-A506-1C97AFB35EDE@gmail.com
Subject: [OpenSCAD] path_sweep problem
The "In-Reply-To" directly references the previous mail, so
the correct way to display that is what your mail program
shows.
Looks like Google decided to ignore that when the title of
the mail changes.
ciao,
Torsten.
On Tue, 8 Feb 2022 19:50:10 +0100, you wrote:
On 08.02.22 18:43, Terry wrote:
Can anyone help me understand why the thread I started,
which had two replies, appears to have absorbed many more
posts headed 'path_sweep problem'?
That is because the mail headers say so:
Message-Id: CCD315DA-55DD-4AE6-A506-1C97AFB35EDE@gmail.com
Subject: [OpenSCAD] Re: Replacement control knob for gas hob
and
In-Reply-To: CCD315DA-55DD-4AE6-A506-1C97AFB35EDE@gmail.com
Subject: [OpenSCAD] path_sweep problem
The "In-Reply-To" directly references the previous mail, so
the correct way to display that is what your mail program
shows.
Looks like Google decided to ignore that when the title of
the mail changes.
ciao,
Torsten.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Thanks Torsten, understood.
Terry
On 08.02.2022 04:48, Ronaldo Persiano wrote:
The union of the model with itself works but F6 will take a lot longer.
A better solution might be:
A simplified version
module model() {
points = [ [0,0,0], [0,1,0], [1,0,0] ];
faces = [ [0,1,2] ];
polyhedron(points=points, faces=faces);
}
model();
The code above is designed to be wrong, but OpenSCAD does not complain
unless you try the boolean operation. However, it is possible to warn
about such cases without involving CGAL, because a polyhedron with fewer
than 4 points is anyway invalid.
If you run this exact code in AngelCAD/xcsg, you get the following error:
xcsg finished with exception: .csg file line 2: polyhedron with too few
points: (points=[[0,0,0],[0,1,0],[1,0,0]],faces=[[0,1,2]],convexity=1)
This type of problem is typical for polyhedron because it can be built
"manually". A built-in test function for polyhedron would be useful. It
could be automatic for all polyhedrons, or maybe an explicit test
function could be used (requiring the user to call it).
Such a test should check that the polyhedron had
-
sufficient number of points (minimum 4)
-
sufficient number of faces (minimum 4)
-
no holes
-
neighbouring faces have normals pointing the same way
-
volume is positive (indicating that normals point outwards)
The above would catch most user errors. Other mistakes such as
self-intersections are more complicated to test for, but the above tests
are not very complicated
Carsten Arnholm
On 2/9/2022 10:51 AM, Carsten Arnholm wrote:
A simplified version
module model() {
points = [ [0,0,0], [0,1,0], [1,0,0] ];
faces = [ [0,1,2] ];
polyhedron(points=points, faces=faces);
}
model();
The code above is designed to be wrong, but OpenSCAD does not
complain unless you try the boolean operation.
Right. The puzzle was in getting OpenSCAD to involve CGAL and get the
testing, without actually making any changes to the resulting shape.
However, it is possible to warn about such cases without involving
CGAL, because a polyhedron with fewer than 4 points is anyway invalid.
Yeah, but that's a boring test. A triangle is just the minimum
"polyhedron"; there are plenty of invalid polyhedra with four or more
points.
This type of problem is typical for polyhedron because it can be built
"manually". A built-in test function for polyhedron would be useful.
It could be automatic for all polyhedrons, or maybe an explicit test
function could be used (requiring the user to call it).
Yes. I've been thinking about adding an automatic test for polyhedra
and for 3D imports. But I'm not entirely sure about it: I want
OpenSCAD to continue and preview the invalid polyhedron, because I build
up polyhedra a couple of faces at a time, fixing errors as I go along,
and so until I'm done the polyhedron is invalid. It could just be a
warning, but that doesn't play nice with the "stop on warnings" setting.
Such a test should check that the polyhedron had
- sufficient number of points (minimum 4)
This falls out of other tests automatically. A "polyhedron" with three
points necessarily has holes, by any definition.
- sufficient number of faces (minimum 4)
Hmm. This one detects degenerate "polyhedra", e.g. two face-to-face
triangles. (No holes! Consistent winding order!)
-
no holes
-
neighbouring faces have normals pointing the same way
I think these two are more or less easy: each edge must be visited
exactly twice, once in each direction.
- volume is positive (indicating that normals point outwards)
I don't know how to do that. (But also there are hints that it's not
required;
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Primitive_Solids#polyhedron
only says that clockwise when viewed from the outside is preferred.)
I know the manual suggests that clockwise is "preferred" but if you
make shapes counterclockwise you run into problems. They disappear
mysteriously, or display other unexpected behaviors. So really you
just need everything clockwise. This is a pretty easy test:
The input is a vertices n faces structure of the form [vertex_list,
face_list] and the result is the signed volume, positive if clockwise,
negative if counterclockwise. And sum is a function that sums up
entries on a list.
function vnf_volume(vnf) =
let(verts = vnf[0])
sum([
for(face=vnf[1], j=[1:1:len(face)-2])
cross(verts[face[j+1]], verts[face[j]]) * verts[face[0]]
])/6;
On Wed, Feb 9, 2022 at 6:20 PM Jordan Brown
openscad@jordan.maileater.net wrote:
On 2/9/2022 10:51 AM, Carsten Arnholm wrote:
A simplified version
module model() {
points = [ [0,0,0], [0,1,0], [1,0,0] ];
faces = [ [0,1,2] ];
polyhedron(points=points, faces=faces);
}
model();
The code above is designed to be wrong, but OpenSCAD does not complain unless you try the boolean operation.
Right. The puzzle was in getting OpenSCAD to involve CGAL and get the testing, without actually making any changes to the resulting shape.
However, it is possible to warn about such cases without involving CGAL, because a polyhedron with fewer than 4 points is anyway invalid.
Yeah, but that's a boring test. A triangle is just the minimum "polyhedron"; there are plenty of invalid polyhedra with four or more points.
This type of problem is typical for polyhedron because it can be built "manually". A built-in test function for polyhedron would be useful. It could be automatic for all polyhedrons, or maybe an explicit test function could be used (requiring the user to call it).
Yes. I've been thinking about adding an automatic test for polyhedra and for 3D imports. But I'm not entirely sure about it: I want OpenSCAD to continue and preview the invalid polyhedron, because I build up polyhedra a couple of faces at a time, fixing errors as I go along, and so until I'm done the polyhedron is invalid. It could just be a warning, but that doesn't play nice with the "stop on warnings" setting.
Such a test should check that the polyhedron had
- sufficient number of points (minimum 4)
This falls out of other tests automatically. A "polyhedron" with three points necessarily has holes, by any definition.
- sufficient number of faces (minimum 4)
Hmm. This one detects degenerate "polyhedra", e.g. two face-to-face triangles. (No holes! Consistent winding order!)
-
no holes
-
neighbouring faces have normals pointing the same way
I think these two are more or less easy: each edge must be visited exactly twice, once in each direction.
- volume is positive (indicating that normals point outwards)
I don't know how to do that. (But also there are hints that it's not required; https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Primitive_Solids#polyhedron only says that clockwise when viewed from the outside is preferred.)
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 2/9/2022 4:26 PM, Adrian Mariano wrote:
I know the manual suggests that clockwise is "preferred" but if you
make shapes counterclockwise you run into problems. They disappear
mysteriously, or display other unexpected behaviors. So really you
just need everything clockwise.
Could somebody more familiar with the guts comment? Perhaps we need to
fix the documentation.
I think polygons can be either winding order but polyhedrons definitely
need to be clockwise, so the documentation is wrong.
On Thu, 10 Feb 2022 at 16:29, Jordan Brown openscad@jordan.maileater.net
wrote:
On 2/9/2022 4:26 PM, Adrian Mariano wrote:
I know the manual suggests that clockwise is "preferred" but if you
make shapes counterclockwise you run into problems. They disappear
mysteriously, or display other unexpected behaviors. So really you
just need everything clockwise.
Could somebody more familiar with the guts comment? Perhaps we need to
fix the documentation.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org