P
Parkinbot
Wed, Jul 17, 2019 12:16 PM
In some sense this is a bug of rotate_extrude(). OpenScad complains when
some edge of the polygon crosses the Y Axis because that would generate a
self-intersection 3D object. The current case is a limit case of the
forbiden crossing and OpenScad should issue an error as well.
It would be a progress to have a procrusting rotate_extrude() which performs
an (internal) intersection with the positive y-half of the XY plane on its
operands. This would eliminate at least some of the strange rotate_extrude()
issues.
Another (natural) semantics would be to cut the operand into two halfs,
rotate them separately, and union the results.
Here an implementation which I meanwhile use in my shortcuts.scad library:
Re() polygon([ [0,2], [-10,1.3],[2.5,0],[3,3], [2,4]]);
// Re2() polygon([ [0,2], [-10,1.3],[2.5,0],[3,3], [2,4]]);
cube();
module Re(angle = 360) // procrust operand to half XY-plane
{
rotate_extrude(angle = angle)
intersection()
{
translate([0, -1e5])square([1e5, 2e5]);
children();
}
}
module Re2(angle = 360) // allow for all operands
{
rotate_extrude(angle = angle)
intersection()
{
translate([1e10, 0])square([2e10, 1e10], center = true);
children();
}
rotate_extrude(angle = angle)
intersection()
{
translate([-1e10, 0])square([2e10, 1e10], center = true);
children();
}
}
--
Sent from: http://forum.openscad.org/
Ronaldo wrote
> In some sense this is a bug of rotate_extrude(). OpenScad complains when
> some edge of the polygon crosses the Y Axis because that would generate a
> self-intersection 3D object. The current case is a limit case of the
> forbiden crossing and OpenScad should issue an error as well.
It would be a progress to have a procrusting rotate_extrude() which performs
an (internal) intersection with the positive y-half of the XY plane on its
operands. This would eliminate at least some of the strange rotate_extrude()
issues.
Another (natural) semantics would be to cut the operand into two halfs,
rotate them separately, and union the results.
Here an implementation which I meanwhile use in my shortcuts.scad library:
Re() polygon([ [0,2], [-10,1.3],[2.5,0],[3,3], [2,4]]);
// Re2() polygon([ [0,2], [-10,1.3],[2.5,0],[3,3], [2,4]]);
cube();
module Re(angle = 360) // procrust operand to half XY-plane
{
rotate_extrude(angle = angle)
intersection()
{
translate([0, -1e5])square([1e5, 2e5]);
children();
}
}
module Re2(angle = 360) // allow for all operands
{
rotate_extrude(angle = angle)
intersection()
{
translate([1e10, 0])square([2e10, 1e10], center = true);
children();
}
rotate_extrude(angle = angle)
intersection()
{
translate([-1e10, 0])square([2e10, 1e10], center = true);
children();
}
}
--
Sent from: http://forum.openscad.org/
NH
nop head
Wed, Jul 17, 2019 12:43 PM
This isn't about crossing the Y axis, it is about touching it at a single
point.
On Wed, 17 Jul 2019 at 13:16, Parkinbot rudolf@digitaldocument.de wrote:
In some sense this is a bug of rotate_extrude(). OpenScad complains when
some edge of the polygon crosses the Y Axis because that would generate a
self-intersection 3D object. The current case is a limit case of the
forbiden crossing and OpenScad should issue an error as well.
It would be a progress to have a procrusting rotate_extrude() which
performs
an (internal) intersection with the positive y-half of the XY plane on its
operands. This would eliminate at least some of the strange
rotate_extrude()
issues.
Another (natural) semantics would be to cut the operand into two halfs,
rotate them separately, and union the results.
Here an implementation which I meanwhile use in my shortcuts.scad library:
Re() polygon([ [0,2], [-10,1.3],[2.5,0],[3,3], [2,4]]);
// Re2() polygon([ [0,2], [-10,1.3],[2.5,0],[3,3], [2,4]]);
cube();
module Re(angle = 360) // procrust operand to half XY-plane
{
rotate_extrude(angle = angle)
intersection()
{
translate([0, -1e5])square([1e5, 2e5]);
children();
}
}
module Re2(angle = 360) // allow for all operands
{
rotate_extrude(angle = angle)
intersection()
{
translate([1e10, 0])square([2e10, 1e10], center = true);
children();
}
rotate_extrude(angle = angle)
intersection()
{
translate([-1e10, 0])square([2e10, 1e10], center = true);
children();
}
}
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
This isn't about crossing the Y axis, it is about touching it at a single
point.
On Wed, 17 Jul 2019 at 13:16, Parkinbot <rudolf@digitaldocument.de> wrote:
> Ronaldo wrote
> > In some sense this is a bug of rotate_extrude(). OpenScad complains when
> > some edge of the polygon crosses the Y Axis because that would generate a
> > self-intersection 3D object. The current case is a limit case of the
> > forbiden crossing and OpenScad should issue an error as well.
>
> It would be a progress to have a procrusting rotate_extrude() which
> performs
> an (internal) intersection with the positive y-half of the XY plane on its
> operands. This would eliminate at least some of the strange
> rotate_extrude()
> issues.
> Another (natural) semantics would be to cut the operand into two halfs,
> rotate them separately, and union the results.
>
> Here an implementation which I meanwhile use in my shortcuts.scad library:
>
> Re() polygon([ [0,2], [-10,1.3],[2.5,0],[3,3], [2,4]]);
> // Re2() polygon([ [0,2], [-10,1.3],[2.5,0],[3,3], [2,4]]);
> cube();
>
>
> module Re(angle = 360) // procrust operand to half XY-plane
> {
> rotate_extrude(angle = angle)
> intersection()
> {
> translate([0, -1e5])square([1e5, 2e5]);
> children();
> }
> }
>
> module Re2(angle = 360) // allow for all operands
> {
> rotate_extrude(angle = angle)
> intersection()
> {
> translate([1e10, 0])square([2e10, 1e10], center = true);
> children();
> }
> rotate_extrude(angle = angle)
> intersection()
> {
> translate([-1e10, 0])square([2e10, 1e10], center = true);
> children();
> }
> }
>
>
>
> --
> Sent from: http://forum.openscad.org/
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
A
arnholm@arnholm.org
Wed, Jul 17, 2019 12:52 PM
On 2019-07-17 14:04, nop head wrote:
I think rotate extrude does its work in PolySets which, just like STL,
is a polygon soup and cannot represent a 2 manifold with self
intersections.
If so, that is a truism. In a polygon soup by definition you have only
1-manifold edges.
Then when that is given to CGAL it barfs.
It didn't in the case I showed.
Carsten Arnholm
On 2019-07-17 14:04, nop head wrote:
> I think rotate extrude does its work in PolySets which, just like STL,
> is a polygon soup and cannot represent a 2 manifold with self
> intersections.
If so, that is a truism. In a polygon soup by definition you have only
1-manifold edges.
> Then when that is given to CGAL it barfs.
It didn't in the case I showed.
Carsten Arnholm
NH
nop head
Wed, Jul 17, 2019 1:23 PM
On 2019-07-17 14:04, nop head wrote:
I think rotate extrude does its work in PolySets which, just like STL,
is a polygon soup and cannot represent a 2 manifold with self
intersections.
If so, that is a truism. In a polygon soup by definition you have only
1-manifold edges.
Then when that is given to CGAL it barfs.
How does it differ from the OP's?
On Wed, 17 Jul 2019 at 13:53, <arnholm@arnholm.org> wrote:
> On 2019-07-17 14:04, nop head wrote:
> > I think rotate extrude does its work in PolySets which, just like STL,
> > is a polygon soup and cannot represent a 2 manifold with self
> > intersections.
>
> If so, that is a truism. In a polygon soup by definition you have only
> 1-manifold edges.
>
> > Then when that is given to CGAL it barfs.
>
> It didn't in the case I showed.
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
CA
Carsten Arnholm
Wed, Jul 17, 2019 1:59 PM
On 17.07.2019 15:23, nop head wrote:
How does it differ from the OP's?
We might perhaps know if the source is posted.
The claim that touching the Y-axis in a single point is causing
assertion when used in rotate_extrude can be tested:
rotate_extrude(){
polygon([ [0,0],[2,-2], [2,2] ]);
}
This works fine in OpenSCAD 2019.03.31 and it can be exported
successfully to various formats, including OFF (sing1.off, vertices=15
faces=28) and STL (sing1.stl, vertices=84 faces=28).
The assertion occurs in OpenSCAD if you try to union with a cube:
rotate_extrude(){
polygon([ [0,0],[2,-2], [2,2] ]);
}
cube(1);
Or this way, it also gives an assertion
import("./sing1.stl");
cube(1);
Now, if you import the OpenSCAD-generated model into AngelCAD
(OFF-version) and union it with a cube as above and save it as test2.off:
// AngelCAD code.
shape@ main_shape()
{
polyhedron p("./sing1.off");
return p + cube(1);
}
In this case there is no problem, it works fine as shown in enclosed PNG
image, and
===
$ polyfix test2.off
Parameters:
input_file = test2.off
polyhedron 0 ================= volume=29.4181, dtol=0.01, atol=1e-06,
maxiter=10
iteration 0: vertices=20 faces=38
total changes=0
no warnings
Summary:
polyhedron 0: vertices=20 faces=38 : no warnings
====
Therefore, the problem seen in OpenSCAD is not really in rotate_extrude,
but how the model is interpreted when subject to union using CGAL. The
same union using Carve works fine as should be expected.
Carsten Arnholm
On 17.07.2019 15:23, nop head wrote:
> How does it differ from the OP's?
We might perhaps know if the source is posted.
The claim that touching the Y-axis in a single point is causing
assertion when used in rotate_extrude can be tested:
rotate_extrude(){
polygon([ [0,0],[2,-2], [2,2] ]);
}
This works fine in OpenSCAD 2019.03.31 and it can be exported
successfully to various formats, including OFF (sing1.off, vertices=15
faces=28) and STL (sing1.stl, vertices=84 faces=28).
The assertion occurs in OpenSCAD if you try to union with a cube:
rotate_extrude(){
polygon([ [0,0],[2,-2], [2,2] ]);
}
cube(1);
Or this way, it also gives an assertion
import("./sing1.stl");
cube(1);
Now, if you import the OpenSCAD-generated model into AngelCAD
(OFF-version) and union it with a cube as above and save it as test2.off:
// AngelCAD code.
shape@ main_shape()
{
polyhedron p("./sing1.off");
return p + cube(1);
}
In this case there is no problem, it works fine as shown in enclosed PNG
image, and
===
$ polyfix test2.off
Parameters:
input_file = test2.off
polyhedron 0 ================= volume=29.4181, dtol=0.01, atol=1e-06,
maxiter=10
iteration 0: vertices=20 faces=38
total changes=0
no warnings
Summary:
polyhedron 0: vertices=20 faces=38 : no warnings
====
Therefore, the problem seen in OpenSCAD is not really in rotate_extrude,
but how the model is interpreted when subject to union using CGAL. The
same union using Carve works fine as should be expected.
Carsten Arnholm
NH
nop head
Wed, Jul 17, 2019 2:19 PM
Rotate extrude and linear extrude, polygon, etc, all work outside CGAL with
PolySets. Only when you need a CSG op is it converted to a Nef_Polyhedron
and fed to CGAL, which then barfs as I stated. It doesn't accept self
intersecting geometry.
On Wed, 17 Jul 2019 at 15:00, Carsten Arnholm arnholm@arnholm.org wrote:
On 17.07.2019 15:23, nop head wrote:
How does it differ from the OP's?
We might perhaps know if the source is posted.
The claim that touching the Y-axis in a single point is causing
assertion when used in rotate_extrude can be tested:
rotate_extrude(){
polygon([ [0,0],[2,-2], [2,2] ]);
}
This works fine in OpenSCAD 2019.03.31 and it can be exported
successfully to various formats, including OFF (sing1.off, vertices=15
faces=28) and STL (sing1.stl, vertices=84 faces=28).
The assertion occurs in OpenSCAD if you try to union with a cube:
rotate_extrude(){
polygon([ [0,0],[2,-2], [2,2] ]);
}
cube(1);
Or this way, it also gives an assertion
import("./sing1.stl");
cube(1);
Now, if you import the OpenSCAD-generated model into AngelCAD
(OFF-version) and union it with a cube as above and save it as test2.off:
// AngelCAD code.
shape@ main_shape()
{
polyhedron p("./sing1.off");
return p + cube(1);
}
In this case there is no problem, it works fine as shown in enclosed PNG
image, and
===
$ polyfix test2.off
Parameters:
input_file = test2.off
polyhedron 0 ================= volume=29.4181, dtol=0.01, atol=1e-06,
maxiter=10
iteration 0: vertices=20 faces=38
total changes=0
no warnings
Summary:
polyhedron 0: vertices=20 faces=38 : no warnings
====
Therefore, the problem seen in OpenSCAD is not really in rotate_extrude,
but how the model is interpreted when subject to union using CGAL. The
same union using Carve works fine as should be expected.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Rotate extrude and linear extrude, polygon, etc, all work outside CGAL with
PolySets. Only when you need a CSG op is it converted to a Nef_Polyhedron
and fed to CGAL, which then barfs as I stated. It doesn't accept self
intersecting geometry.
On Wed, 17 Jul 2019 at 15:00, Carsten Arnholm <arnholm@arnholm.org> wrote:
> On 17.07.2019 15:23, nop head wrote:
> > How does it differ from the OP's?
>
> We might perhaps know if the source is posted.
>
> The claim that touching the Y-axis in a single point is causing
> assertion when used in rotate_extrude can be tested:
>
> rotate_extrude(){
> polygon([ [0,0],[2,-2], [2,2] ]);
> }
>
> This works fine in OpenSCAD 2019.03.31 and it can be exported
> successfully to various formats, including OFF (sing1.off, vertices=15
> faces=28) and STL (sing1.stl, vertices=84 faces=28).
>
> The assertion occurs in OpenSCAD if you try to union with a cube:
>
> rotate_extrude(){
> polygon([ [0,0],[2,-2], [2,2] ]);
> }
> cube(1);
>
> Or this way, it also gives an assertion
>
> import("./sing1.stl");
> cube(1);
>
>
> Now, if you import the OpenSCAD-generated model into AngelCAD
> (OFF-version) and union it with a cube as above and save it as test2.off:
>
> // AngelCAD code.
> shape@ main_shape()
> {
> polyhedron p("./sing1.off");
> return p + cube(1);
> }
>
> In this case there is no problem, it works fine as shown in enclosed PNG
> image, and
>
> ===
>
> $ polyfix test2.off
>
> Parameters:
> input_file = test2.off
>
>
> polyhedron 0 ================= volume=29.4181, dtol=0.01, atol=1e-06,
> maxiter=10
> iteration 0: vertices=20 faces=38
> total changes=0
> no warnings
>
> Summary:
> polyhedron 0: vertices=20 faces=38 : no warnings
>
> ====
>
>
> Therefore, the problem seen in OpenSCAD is not really in rotate_extrude,
> but how the model is interpreted when subject to union using CGAL. The
> same union using Carve works fine as should be expected.
>
>
> Carsten Arnholm
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
DS
Dan Shriver
Wed, Jul 17, 2019 2:33 PM
If you're asking me to post my source here it is:
Notes:
- coshPolygon is corrected to start at 0.0001 not 0 as it was originally
- If you use coshPolygon2 OpenSCAD helpfully spits out a message saying
not to have points on both sides of the Y axis. I was suggesting that
maybe instead of the cryptic exception I got a message saying "Do not have
any points X=0" would be nice. I am seeing that people are saying if you
have two points X = 0 with different Y values that would work, but that
seems like a weird case (as people mention zero thickness)
- if you make one hypDome things are fine (with coshPolygon starting at
x=0 as it did originally). However, multiple overlapping, or overlapping
another object causes the cryptic exception
function echoit5(y,x) = echo(y,x) x; //debug
function cosh(x) = (exp(x) + exp(-x))/2;
function coshPolygon(multiplier, power, domain, flip, steps) =
let (flipValue = flip ? cosh( ( multiplier *(pow(domain,power))) ) : 0)
[ for(i = [0.0001: (domain / steps) : domain]) [i, flipValue - cosh( (
multiplier *(pow(i,power))) )] ];
function coshPolygon2(multiplier, power, domain, flip, steps) =
[ for(i = [-domain: (2 * domain / steps) : domain]) [i, cosh( (
multiplier *(pow(i,power))) )] ];
module hypDome(multiplier = 1, power = 1, domain = 2, flip = true, steps =
10, facets = 20) {
rotate_extrude($fn = facets) {
polygon(echoit5("raw polygon",coshPolygon(multiplier, power,
domain, flip, steps)));
}
}
scale([8,8,1]) {
hypDome(1,1,5,true,10, 20);
}
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon
Virus-free.
www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Wed, Jul 17, 2019 at 10:00 AM Carsten Arnholm arnholm@arnholm.org
wrote:
On 17.07.2019 15:23, nop head wrote:
How does it differ from the OP's?
We might perhaps know if the source is posted.
The claim that touching the Y-axis in a single point is causing
assertion when used in rotate_extrude can be tested:
rotate_extrude(){
polygon([ [0,0],[2,-2], [2,2] ]);
}
This works fine in OpenSCAD 2019.03.31 and it can be exported
successfully to various formats, including OFF (sing1.off, vertices=15
faces=28) and STL (sing1.stl, vertices=84 faces=28).
The assertion occurs in OpenSCAD if you try to union with a cube:
rotate_extrude(){
polygon([ [0,0],[2,-2], [2,2] ]);
}
cube(1);
Or this way, it also gives an assertion
import("./sing1.stl");
cube(1);
Now, if you import the OpenSCAD-generated model into AngelCAD
(OFF-version) and union it with a cube as above and save it as test2.off:
// AngelCAD code.
shape@ main_shape()
{
polyhedron p("./sing1.off");
return p + cube(1);
}
In this case there is no problem, it works fine as shown in enclosed PNG
image, and
===
$ polyfix test2.off
Parameters:
input_file = test2.off
polyhedron 0 ================= volume=29.4181, dtol=0.01, atol=1e-06,
maxiter=10
iteration 0: vertices=20 faces=38
total changes=0
no warnings
Summary:
polyhedron 0: vertices=20 faces=38 : no warnings
====
Therefore, the problem seen in OpenSCAD is not really in rotate_extrude,
but how the model is interpreted when subject to union using CGAL. The
same union using Carve works fine as should be expected.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
If you're asking me to post my source here it is:
Notes:
1) coshPolygon is corrected to start at 0.0001 not 0 as it was originally
2) If you use coshPolygon2 OpenSCAD helpfully spits out a message saying
not to have points on both sides of the Y axis. I was suggesting that
maybe instead of the cryptic exception I got a message saying "Do not have
any points X=0" would be nice. I am seeing that people are saying if you
have two points X = 0 with different Y values that would work, but that
seems like a weird case (as people mention zero thickness)
3) if you make one hypDome things are fine (with coshPolygon starting at
x=0 as it did originally). However, multiple overlapping, or overlapping
another object causes the cryptic exception
---------------------------------------------
function echoit5(y,x) = echo(y,x) x; //debug
function cosh(x) = (exp(x) + exp(-x))/2;
function coshPolygon(multiplier, power, domain, flip, steps) =
let (flipValue = flip ? cosh( ( multiplier *(pow(domain,power))) ) : 0)
[ for(i = [0.0001: (domain / steps) : domain]) [i, flipValue - cosh( (
multiplier *(pow(i,power))) )] ];
function coshPolygon2(multiplier, power, domain, flip, steps) =
[ for(i = [-domain: (2 * domain / steps) : domain]) [i, cosh( (
multiplier *(pow(i,power))) )] ];
module hypDome(multiplier = 1, power = 1, domain = 2, flip = true, steps =
10, facets = 20) {
rotate_extrude($fn = facets) {
polygon(echoit5("raw polygon",coshPolygon(multiplier, power,
domain, flip, steps)));
}
}
scale([8,8,1]) {
hypDome(1,1,5,true,10, 20);
}
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Wed, Jul 17, 2019 at 10:00 AM Carsten Arnholm <arnholm@arnholm.org>
wrote:
> On 17.07.2019 15:23, nop head wrote:
> > How does it differ from the OP's?
>
> We might perhaps know if the source is posted.
>
> The claim that touching the Y-axis in a single point is causing
> assertion when used in rotate_extrude can be tested:
>
> rotate_extrude(){
> polygon([ [0,0],[2,-2], [2,2] ]);
> }
>
> This works fine in OpenSCAD 2019.03.31 and it can be exported
> successfully to various formats, including OFF (sing1.off, vertices=15
> faces=28) and STL (sing1.stl, vertices=84 faces=28).
>
> The assertion occurs in OpenSCAD if you try to union with a cube:
>
> rotate_extrude(){
> polygon([ [0,0],[2,-2], [2,2] ]);
> }
> cube(1);
>
> Or this way, it also gives an assertion
>
> import("./sing1.stl");
> cube(1);
>
>
> Now, if you import the OpenSCAD-generated model into AngelCAD
> (OFF-version) and union it with a cube as above and save it as test2.off:
>
> // AngelCAD code.
> shape@ main_shape()
> {
> polyhedron p("./sing1.off");
> return p + cube(1);
> }
>
> In this case there is no problem, it works fine as shown in enclosed PNG
> image, and
>
> ===
>
> $ polyfix test2.off
>
> Parameters:
> input_file = test2.off
>
>
> polyhedron 0 ================= volume=29.4181, dtol=0.01, atol=1e-06,
> maxiter=10
> iteration 0: vertices=20 faces=38
> total changes=0
> no warnings
>
> Summary:
> polyhedron 0: vertices=20 faces=38 : no warnings
>
> ====
>
>
> Therefore, the problem seen in OpenSCAD is not really in rotate_extrude,
> but how the model is interpreted when subject to union using CGAL. The
> same union using Carve works fine as should be expected.
>
>
> Carsten Arnholm
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
NH
nop head
Wed, Jul 17, 2019 2:44 PM
I am seeing that people are saying if you have two points X = 0 with
different Y values that would work, but that seems like a weird case (as
people mention zero thickness)
No it is not a weird case, it is the normal case to make something without
a hole through the middle.
When you have a single point meeting the Y axis then you end up with a
object with a zero thickness point where its top and bottom surfaces meet.
If you have pairs of adjacent points on the Y axis then you end of with a
normal solid with a non-zero thickness.
On Wed, 17 Jul 2019 at 15:34, Dan Shriver tabbydan@gmail.com wrote:
If you're asking me to post my source here it is:
Notes:
- coshPolygon is corrected to start at 0.0001 not 0 as it was originally
- If you use coshPolygon2 OpenSCAD helpfully spits out a message saying
not to have points on both sides of the Y axis. I was suggesting that
maybe instead of the cryptic exception I got a message saying "Do not have
any points X=0" would be nice. I am seeing that people are saying if you
have two points X = 0 with different Y values that would work, but that
seems like a weird case (as people mention zero thickness)
- if you make one hypDome things are fine (with coshPolygon starting at
x=0 as it did originally). However, multiple overlapping, or overlapping
another object causes the cryptic exception
function echoit5(y,x) = echo(y,x) x; //debug
function cosh(x) = (exp(x) + exp(-x))/2;
function coshPolygon(multiplier, power, domain, flip, steps) =
let (flipValue = flip ? cosh( ( multiplier *(pow(domain,power))) ) : 0)
[ for(i = [0.0001: (domain / steps) : domain]) [i, flipValue - cosh(
( multiplier *(pow(i,power))) )] ];
function coshPolygon2(multiplier, power, domain, flip, steps) =
[ for(i = [-domain: (2 * domain / steps) : domain]) [i, cosh( (
multiplier *(pow(i,power))) )] ];
module hypDome(multiplier = 1, power = 1, domain = 2, flip = true, steps =
10, facets = 20) {
rotate_extrude($fn = facets) {
polygon(echoit5("raw polygon",coshPolygon(multiplier, power,
domain, flip, steps)));
}
}
scale([8,8,1]) {
hypDome(1,1,5,true,10, 20);
}
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon Virus-free.
www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link
<#m_-8618667265926880856_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Wed, Jul 17, 2019 at 10:00 AM Carsten Arnholm arnholm@arnholm.org
wrote:
On 17.07.2019 15:23, nop head wrote:
How does it differ from the OP's?
We might perhaps know if the source is posted.
The claim that touching the Y-axis in a single point is causing
assertion when used in rotate_extrude can be tested:
rotate_extrude(){
polygon([ [0,0],[2,-2], [2,2] ]);
}
This works fine in OpenSCAD 2019.03.31 and it can be exported
successfully to various formats, including OFF (sing1.off, vertices=15
faces=28) and STL (sing1.stl, vertices=84 faces=28).
The assertion occurs in OpenSCAD if you try to union with a cube:
rotate_extrude(){
polygon([ [0,0],[2,-2], [2,2] ]);
}
cube(1);
Or this way, it also gives an assertion
import("./sing1.stl");
cube(1);
Now, if you import the OpenSCAD-generated model into AngelCAD
(OFF-version) and union it with a cube as above and save it as test2.off:
// AngelCAD code.
shape@ main_shape()
{
polyhedron p("./sing1.off");
return p + cube(1);
}
In this case there is no problem, it works fine as shown in enclosed PNG
image, and
===
$ polyfix test2.off
Parameters:
input_file = test2.off
polyhedron 0 ================= volume=29.4181, dtol=0.01, atol=1e-06,
maxiter=10
iteration 0: vertices=20 faces=38
total changes=0
no warnings
Summary:
polyhedron 0: vertices=20 faces=38 : no warnings
====
Therefore, the problem seen in OpenSCAD is not really in rotate_extrude,
but how the model is interpreted when subject to union using CGAL. The
same union using Carve works fine as should be expected.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
> I am seeing that people are saying if you have two points X = 0 with
> different Y values that would work, but that seems like a weird case (as
> people mention zero thickness)
No it is not a weird case, it is the normal case to make something without
a hole through the middle.
When you have a single point meeting the Y axis then you end up with a
object with a zero thickness point where its top and bottom surfaces meet.
If you have pairs of adjacent points on the Y axis then you end of with a
normal solid with a non-zero thickness.
On Wed, 17 Jul 2019 at 15:34, Dan Shriver <tabbydan@gmail.com> wrote:
> If you're asking me to post my source here it is:
>
> Notes:
> 1) coshPolygon is corrected to start at 0.0001 not 0 as it was originally
> 2) If you use coshPolygon2 OpenSCAD helpfully spits out a message saying
> not to have points on both sides of the Y axis. I was suggesting that
> maybe instead of the cryptic exception I got a message saying "Do not have
> any points X=0" would be nice. I am seeing that people are saying if you
> have two points X = 0 with different Y values that would work, but that
> seems like a weird case (as people mention zero thickness)
> 3) if you make one hypDome things are fine (with coshPolygon starting at
> x=0 as it did originally). However, multiple overlapping, or overlapping
> another object causes the cryptic exception
>
> ---------------------------------------------
>
> function echoit5(y,x) = echo(y,x) x; //debug
>
> function cosh(x) = (exp(x) + exp(-x))/2;
>
> function coshPolygon(multiplier, power, domain, flip, steps) =
> let (flipValue = flip ? cosh( ( multiplier *(pow(domain,power))) ) : 0)
> [ for(i = [0.0001: (domain / steps) : domain]) [i, flipValue - cosh(
> ( multiplier *(pow(i,power))) )] ];
>
> function coshPolygon2(multiplier, power, domain, flip, steps) =
> [ for(i = [-domain: (2 * domain / steps) : domain]) [i, cosh( (
> multiplier *(pow(i,power))) )] ];
>
> module hypDome(multiplier = 1, power = 1, domain = 2, flip = true, steps =
> 10, facets = 20) {
> rotate_extrude($fn = facets) {
> polygon(echoit5("raw polygon",coshPolygon(multiplier, power,
> domain, flip, steps)));
> }
> }
>
> scale([8,8,1]) {
> hypDome(1,1,5,true,10, 20);
> }
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
> <#m_-8618667265926880856_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Wed, Jul 17, 2019 at 10:00 AM Carsten Arnholm <arnholm@arnholm.org>
> wrote:
>
>> On 17.07.2019 15:23, nop head wrote:
>> > How does it differ from the OP's?
>>
>> We might perhaps know if the source is posted.
>>
>> The claim that touching the Y-axis in a single point is causing
>> assertion when used in rotate_extrude can be tested:
>>
>> rotate_extrude(){
>> polygon([ [0,0],[2,-2], [2,2] ]);
>> }
>>
>> This works fine in OpenSCAD 2019.03.31 and it can be exported
>> successfully to various formats, including OFF (sing1.off, vertices=15
>> faces=28) and STL (sing1.stl, vertices=84 faces=28).
>>
>> The assertion occurs in OpenSCAD if you try to union with a cube:
>>
>> rotate_extrude(){
>> polygon([ [0,0],[2,-2], [2,2] ]);
>> }
>> cube(1);
>>
>> Or this way, it also gives an assertion
>>
>> import("./sing1.stl");
>> cube(1);
>>
>>
>> Now, if you import the OpenSCAD-generated model into AngelCAD
>> (OFF-version) and union it with a cube as above and save it as test2.off:
>>
>> // AngelCAD code.
>> shape@ main_shape()
>> {
>> polyhedron p("./sing1.off");
>> return p + cube(1);
>> }
>>
>> In this case there is no problem, it works fine as shown in enclosed PNG
>> image, and
>>
>> ===
>>
>> $ polyfix test2.off
>>
>> Parameters:
>> input_file = test2.off
>>
>>
>> polyhedron 0 ================= volume=29.4181, dtol=0.01, atol=1e-06,
>> maxiter=10
>> iteration 0: vertices=20 faces=38
>> total changes=0
>> no warnings
>>
>> Summary:
>> polyhedron 0: vertices=20 faces=38 : no warnings
>>
>> ====
>>
>>
>> Therefore, the problem seen in OpenSCAD is not really in rotate_extrude,
>> but how the model is interpreted when subject to union using CGAL. The
>> same union using Carve works fine as should be expected.
>>
>>
>> Carsten Arnholm
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss@lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
P
Parkinbot
Wed, Jul 17, 2019 3:18 PM
So your problem is clear. You try to rotate around a single vertex and get a
singularity.
The following modification avoids this problem by introducing another point
on the y axis and creating an edge on the y axis.
function coshPolygon(multiplier, power, domain, flip, steps) =
let (flipValue = flip ? cosh( ( multiplier *(pow(domain,power))) ) : 0)
let (result = [for(i = [0.0001: (domain / steps) : domain]) [i,
flipValue - cosh( ( multiplier *(pow(i,power))) )] ])
concat(result, [[0, result[len(result)-1][1]]]);
--
Sent from: http://forum.openscad.org/
So your problem is clear. You try to rotate around a single vertex and get a
singularity.
The following modification avoids this problem by introducing another point
on the y axis and creating an edge on the y axis.
function coshPolygon(multiplier, power, domain, flip, steps) =
let (flipValue = flip ? cosh( ( multiplier *(pow(domain,power))) ) : 0)
let (result = [for(i = [0.0001: (domain / steps) : domain]) [i,
flipValue - cosh( ( multiplier *(pow(i,power))) )] ])
concat(result, [[0, result[len(result)-1][1]]]);
--
Sent from: http://forum.openscad.org/
BB
Bruno Boettcher
Wed, Jul 17, 2019 3:32 PM
heh happily swimming in my ignorance and incompetence......
still..... you mention a tool polyfix that repairs the stl??
some pointer please?
thanks!
Bruno
Am Mi., 17. Juli 2019 um 13:31 Uhr schrieb Carsten Arnholm <
arnholm@arnholm.org>:
On 17.07.2019 08:16, Ronaldo Persiano wrote:
Em qua, 17 de jul de 2019 às 03:07, MichaelAtOz <oz.at.michael@gmail.com
mailto:oz.at.michael@gmail.com> escreveu:
What Ronaldo says is if there is a bug it would be that OpenSCAD
might be
able to detect such attempts and produce a better error message.
The only situation the rotate_extrude() of a simple polygon is clearly a
manifold is when the polygon does not have any intersection with the Y
axis and it rests entirely at left or at right of the Y axis. Then the
rotate_extrude() will be a torus like object.
When the intersection of a simple polygon and the Y axis is a full
polygon edge, I would expect a non-manifold result because that
particular edge would be in the interior of the object. But CGAL does
produce a valid polyhedron
I don't know how rotate_extrude is implemented in OpenSCAD, but I am
guessing CGAL does not provide such a feature, and instead
rotate_extrude is done by OpenSCAD directly to compute the coordinates
of a polyhedron. Implemented this way, there are no boolean operations
involved.
This is certainly the case in AngelCAD where rotate_extrude is not a
feature at all in Carve (Carve is the equivalent to CGAL), it is
computed directly by the application, not the library.
The implication is that the issue is not about manifoldness, but rather
about self intersection and collapsed faces. Manifoldness is about
topology (connectivity), self-intersection and collapsed faces is about
geometry (coordinates in this case). You can have a self-intersecting
polyhedron with collapsed faces which is 2 manifold, as in the below
example
When you say "I would expect a non-manifold result because that
particular edge would be in the interior of the object. But CGAL does
produce a valid polyhedron". I would say CGAL that is correct, and the
expectation is incorrect.
Consider the example
rotate_extrude(){
polygon([ [0,-2],[2,0], [0,2] ]);
}
This produces no error by OpenSCAD, and you could argue it is ok at this
stage.
Top level object is a 3D object:
Facets: 42
The visible external faces are only 14. If you export to OFF format and
then analyze it with polyfix...
OFF export finished: O:/STL/rotate1.off
...you will find that OpenSCAD appears to have merged overlapping
vertices, thus creating a non-manifold model and containing collapsed
faces. After repair, the collapsed faces are removed and thus the model
is again 2-manifold.
===
$ polyfix rotate1.off
Parameters:
input_file = rotate1.off
polyhedron 0 ================= volume=14.5942, dtol=0.01, atol=1e-06,
maxiter=10
iteration 0: vertices=9 faces=42
warning: 28 zero area faces.
warning: nonmanifold edges: uc(4)=14 uc(14)=2 uc(28)=1
removed 28 collapsed or zero area faces
total changes=28
no warnings
iteration 1: vertices=9 faces=14
total changes=0
no warnings
Summary:
polyhedron 0: vertices=9 faces=14 : no warnings
Writing: rotate1_1.off
We can repeat the same exercise in AngelCAD (coordinates are a bit
different, because AngelCAD rotates around global Y).
// AngelCAD code.
shape@ main_shape()
{
array<pos2d@> p = { {0,-2},{2,0},{0,2} };
return rotate_extrude(polygon(p),deg:360);
}
void main()
{
shape@ obj = main_shape();
obj.write_xcsg(GetInputFullPath(),secant_tolerance:0.2);
}
This creates the output
xcsg processing: /media/nas_openbzr/STL/xcsg/test1.xcsg
processing solid: rotate_extrude
...completed CSG tree: 0 boolean operations to process.
...Info: rotate_extrude angle>=2*PI implies a torus
...completed boolean operations in 0 [sec]
...result model contains 1 lump.
...lump 1: 21 vertices, 15 polygon faces.
...Polyhedron is water-tight (edge use-count check OK)
Warning: Polyhedron has 1 zero area faces.
...Polyhedron has 15 non-triangular faces
...Triangulating lump ...
...Triangulation completed with 28 triangle faces in 0 [sec]
...Exporting results
Created STL file : /media/nas_openbzr/STL/xcsg/test1.stl
xcsg finished using 0h 0m 0.01s
i.e. 28 faces makes sense = 7x3, of which one third will be collapsed,
due to the way rotate_extrude is implemented.
=====
$ polyfix xcsg/test1.off
Parameters:
input_file = xcsg/test1.off
polyhedron 0 ================= volume=14.5942, dtol=0.01, atol=1e-06,
maxiter=10
iteration 0: vertices=21 faces=28
warning: 14 zero area faces.
warning: nonmanifold edges: uc(1)=14
merged 12 vertices
removed 14 collapsed or zero area faces
total changes=26
no warnings
iteration 1: vertices=9 faces=14
total changes=0
no warnings
Summary:
polyhedron 0: vertices=9 faces=14 : no warnings
Writing: xcsg/test1_1.off
=====
Here, polyfix assumes overlapping vertices is undesired and merges them,
the end result is the same as via OpenSCAD, 14 faces and 9 vertices.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
heh happily swimming in my ignorance and incompetence......
still..... you mention a tool polyfix that repairs the stl??
some pointer please?
thanks!
Bruno
Am Mi., 17. Juli 2019 um 13:31 Uhr schrieb Carsten Arnholm <
arnholm@arnholm.org>:
> On 17.07.2019 08:16, Ronaldo Persiano wrote:
> > Em qua, 17 de jul de 2019 às 03:07, MichaelAtOz <oz.at.michael@gmail.com
> > <mailto:oz.at.michael@gmail.com>> escreveu:
> >
> > What Ronaldo says is if there is a bug it would be that OpenSCAD
> > might be
> > able to detect such attempts and produce a better error message.
> >
> >
> > The only situation the rotate_extrude() of a simple polygon is clearly a
> > manifold is when the polygon does not have any intersection with the Y
> > axis and it rests entirely at left or at right of the Y axis. Then the
> > rotate_extrude() will be a torus like object.
> >
> > When the intersection of a simple polygon and the Y axis is a full
> > polygon edge, I would expect a non-manifold result because that
> > particular edge would be in the interior of the object. But CGAL does
> > produce a valid polyhedron
>
> I don't know how rotate_extrude is implemented in OpenSCAD, but I am
> guessing CGAL does not provide such a feature, and instead
> rotate_extrude is done by OpenSCAD directly to compute the coordinates
> of a polyhedron. Implemented this way, there are no boolean operations
> involved.
>
> This is certainly the case in AngelCAD where rotate_extrude is not a
> feature at all in Carve (Carve is the equivalent to CGAL), it is
> computed directly by the application, not the library.
>
> The implication is that the issue is not about manifoldness, but rather
> about self intersection and collapsed faces. Manifoldness is about
> topology (connectivity), self-intersection and collapsed faces is about
> geometry (coordinates in this case). You can have a self-intersecting
> polyhedron with collapsed faces which is 2 manifold, as in the below
> example
>
> When you say "I would expect a non-manifold result because that
> particular edge would be in the interior of the object. But CGAL does
> produce a valid polyhedron". I would say CGAL that is correct, and the
> expectation is incorrect.
>
> Consider the example
>
> rotate_extrude(){
> polygon([ [0,-2],[2,0], [0,2] ]);
> }
>
> This produces no error by OpenSCAD, and you could argue it is ok at this
> stage.
>
> Top level object is a 3D object:
> Facets: 42
>
> The visible external faces are only 14. If you export to OFF format and
> then analyze it with polyfix...
>
> OFF export finished: O:/STL/rotate1.off
>
> ...you will find that OpenSCAD appears to have merged overlapping
> vertices, thus creating a non-manifold model and containing collapsed
> faces. After repair, the collapsed faces are removed and thus the model
> is again 2-manifold.
>
> ===
> $ polyfix rotate1.off
>
> Parameters:
> input_file = rotate1.off
>
>
> polyhedron 0 ================= volume=14.5942, dtol=0.01, atol=1e-06,
> maxiter=10
> iteration 0: vertices=9 faces=42
> warning: 28 zero area faces.
> warning: nonmanifold edges: uc(4)=14 uc(14)=2 uc(28)=1
> removed 28 collapsed or zero area faces
> total changes=28
> no warnings
>
> iteration 1: vertices=9 faces=14
> total changes=0
> no warnings
>
> Summary:
> polyhedron 0: vertices=9 faces=14 : no warnings
>
> Writing: rotate1_1.off
> ===
>
> We can repeat the same exercise in AngelCAD (coordinates are a bit
> different, because AngelCAD rotates around global Y).
>
>
> // AngelCAD code.
> shape@ main_shape()
> {
> array<pos2d@> p = { {0,-2},{2,0},{0,2} };
> return rotate_extrude(polygon(p),deg:360);
> }
>
> void main()
> {
> shape@ obj = main_shape();
> obj.write_xcsg(GetInputFullPath(),secant_tolerance:0.2);
> }
>
>
> This creates the output
>
> xcsg processing: /media/nas_openbzr/STL/xcsg/test1.xcsg
> processing solid: rotate_extrude
> ...completed CSG tree: 0 boolean operations to process.
> ...Info: rotate_extrude angle>=2*PI implies a torus
> ...completed boolean operations in 0 [sec]
> ...result model contains 1 lump.
> ...lump 1: 21 vertices, 15 polygon faces.
> ...Polyhedron is water-tight (edge use-count check OK)
> >>> Warning: Polyhedron has 1 zero area faces.
> ...Polyhedron has 15 non-triangular faces
> ...Triangulating lump ...
> ...Triangulation completed with 28 triangle faces in 0 [sec]
> ...Exporting results
> Created STL file : /media/nas_openbzr/STL/xcsg/test1.stl
> xcsg finished using 0h 0m 0.01s
>
> i.e. 28 faces makes sense = 7x3, of which one third will be collapsed,
> due to the way rotate_extrude is implemented.
>
> =====
>
> $ polyfix xcsg/test1.off
>
> Parameters:
> input_file = xcsg/test1.off
>
>
> polyhedron 0 ================= volume=14.5942, dtol=0.01, atol=1e-06,
> maxiter=10
> iteration 0: vertices=21 faces=28
> warning: 14 zero area faces.
> warning: nonmanifold edges: uc(1)=14
> merged 12 vertices
> removed 14 collapsed or zero area faces
> total changes=26
> no warnings
>
> iteration 1: vertices=9 faces=14
> total changes=0
> no warnings
>
> Summary:
> polyhedron 0: vertices=9 faces=14 : no warnings
>
> Writing: xcsg/test1_1.off
>
> =====
>
> Here, polyfix assumes overlapping vertices is undesired and merges them,
> the end result is the same as via OpenSCAD, 14 faces and 9 vertices.
>
>
>
> Carsten Arnholm
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
--
ciao
Bruno
===========================================
http://nohkumado.eu/, <http://bboett.free.fr>http://aikido.nohkumado.eu/,
<http://bboett.free.fr>
http://aikido.zorn.free.fr
