rendering problem

classic Classic list List threaded Threaded
31 messages Options
12
dpa
Reply | Threaded
Open this post in threaded view
|

rendering problem

dpa
Hey,
I was using OpenSCAD because it's so reliable, but yesterday I was very disappointed. I researched the frequing same problem for almost exactly one day now and just couldn't get any further. There are probably several in one.

For this question mail I didn't use my own polygons, just circle, rotate_extrude and minkowski with a sphere.
The preview is fine, the rendering doesn't say enything but stays empty. Thats my first question: why is there no error AND no output?
It brings an error when you change the "add_rotate" in cutomizer. What brings me to the 2nd question: why does a rotation bring different errors?
And last but not least: how can I bring this object to render with a "add_rotate"=7 at all? Where is the error / what I'm doing wrong?

best
Dietrich

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

Re: rendering problem

dpa
here is the file...


Am Mo., 25. Mai 2020 um 23:08 Uhr schrieb dpa <[hidden email]>:
Hey,
I was using OpenSCAD because it's so reliable, but yesterday I was very disappointed. I researched the frequing same problem for almost exactly one day now and just couldn't get any further. There are probably several in one.

For this question mail I didn't use my own polygons, just circle, rotate_extrude and minkowski with a sphere.
The preview is fine, the rendering doesn't say enything but stays empty. Thats my first question: why is there no error AND no output?
It brings an error when you change the "add_rotate" in cutomizer. What brings me to the 2nd question: why does a rotation bring different errors?
And last but not least: how can I bring this object to render with a "add_rotate"=7 at all? Where is the error / what I'm doing wrong?

best
Dietrich

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

USB-Winkeler_bug.scad (788 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rendering problem

Ronaldo
Congratulations! You have found a bug in the minkowski operator. That is what I get with Thrown Together:

image.png

Yes, there is some reversed face in the minkowski! Just the minkowsky renders fine but CGAL finds an error when it is boolean operated with the connector. That face seems to be the cause.

I have never seen that bug before. The bug seems to be related to the number of faces in the sphere and edges in the extrusion circle. Something odd happens when both $fn are equal to 6.

Em seg., 25 de mai. de 2020 às 22:10, dpa <[hidden email]> escreveu:
here is the file...


Am Mo., 25. Mai 2020 um 23:08 Uhr schrieb dpa <[hidden email]>:
Hey,
I was using OpenSCAD because it's so reliable, but yesterday I was very disappointed. I researched the frequing same problem for almost exactly one day now and just couldn't get any further. There are probably several in one.

For this question mail I didn't use my own polygons, just circle, rotate_extrude and minkowski with a sphere.
The preview is fine, the rendering doesn't say enything but stays empty. Thats my first question: why is there no error AND no output?
It brings an error when you change the "add_rotate" in cutomizer. What brings me to the 2nd question: why does a rotation bring different errors?
And last but not least: how can I bring this object to render with a "add_rotate"=7 at all? Where is the error / what I'm doing wrong?

best
Dietrich
_______________________________________________
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: rendering problem

MichaelAtOz
Administrator
In reply to this post by dpa

> The preview is fine, the rendering doesn't say enything but stays empty. Thats my first question: why is there no error AND no output?

I get a CGAL error,

 

Rendering Polygon Mesh using CGAL...

ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion violation! Expr: e->incident_sface() != SFace_const_handle() File: /mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_S2/SM_const_decorator.h Line: 329

Geometries in cache: 8

Geometry cache size in bytes: 80896

CGAL Polyhedrons in cache: 1

CGAL cache size in bytes: 0

Total rendering time: 0 hours, 0 minutes, 0 seconds

Rendering finished.

 

If you missed that and tried F6 again, you don't get the error as the geometry is cached.

Whenever you have strange things like that it is good to try Design/Flush-cache.

 

Thank you, you have found a simple example of a bug I have seen hiding, where F5 then F6 has a CGAL error, but F6 alone (fresh run or flush cache) does not, but the exported STL is bad.

 

> What brings me to the 2nd question: why does a rotation bring different errors?

 

A change in rotation will produce different angles where faces meet, sometimes they meet in a way that is non-manifold, like an edge or point meeting exactly in the middle of a face.

But in this case I suspect a bug.

 

Interesting what I found inside (with add_rotate=7):

 

 

 


From: Discuss [mailto:[hidden email]] On Behalf Of dpa
Sent: Tue, 26 May 2020 07:09
To: [hidden email]
Subject: [OpenSCAD] rendering problem

 

Hey,

I was using OpenSCAD because it's so reliable, but yesterday I was very disappointed. I researched the frequing same problem for almost exactly one day now and just couldn't get any further. There are probably several in one.

 

For this question mail I didn't use my own polygons, just circle, rotate_extrude and minkowski with a sphere.
The preview is fine, the rendering doesn't say enything but stays empty. Thats my first question: why is there no error AND no output?
It brings an error when you change the "add_rotate" in cutomizer. What brings me to the 2nd question: why does a rotation bring different errors?
And last but not least: how can I bring this object to render with a "add_rotate"=7 at all? Where is the error / what I'm doing wrong?

 

best

Dietrich


Virus-free. www.avg.com

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD Admin - email* me if you need anything, or if I've done something stupid...
* on the Forum, click on my MichaelAtOz label, there is a link to email me.

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

Re: rendering problem

MichaelAtOz
Administrator

BTW those inverted triangle z-fight when it is moved. I presume that means it is duplicated, one correct, the other inverse.

 


From: Discuss [mailto:[hidden email]] On Behalf Of OzAtMichael
Sent: Tue, 26 May 2020 12:31
To: 'OpenSCAD general discussion'
Subject: Re: [OpenSCAD] rendering problem

 

> The preview is fine, the rendering doesn't say enything but stays empty. Thats my first question: why is there no error AND no output?

I get a CGAL error,

 

Rendering Polygon Mesh using CGAL...

ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion violation! Expr: e->incident_sface() != SFace_const_handle() File: /mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_S2/SM_const_decorator.h Line: 329

Geometries in cache: 8

Geometry cache size in bytes: 80896

CGAL Polyhedrons in cache: 1

CGAL cache size in bytes: 0

Total rendering time: 0 hours, 0 minutes, 0 seconds

Rendering finished.

 

If you missed that and tried F6 again, you don't get the error as the geometry is cached.

Whenever you have strange things like that it is good to try Design/Flush-cache.

 

Thank you, you have found a simple example of a bug I have seen hiding, where F5 then F6 has a CGAL error, but F6 alone (fresh run or flush cache) does not, but the exported STL is bad.

 

> What brings me to the 2nd question: why does a rotation bring different errors?

 

A change in rotation will produce different angles where faces meet, sometimes they meet in a way that is non-manifold, like an edge or point meeting exactly in the middle of a face.

But in this case I suspect a bug.

 

Interesting what I found inside (with add_rotate=7):

 

 

 


From: Discuss [mailto:[hidden email]] On Behalf Of dpa
Sent: Tue, 26 May 2020 07:09
To: [hidden email]
Subject: [OpenSCAD] rendering problem

 

Hey,

I was using OpenSCAD because it's so reliable, but yesterday I was very disappointed. I researched the frequing same problem for almost exactly one day now and just couldn't get any further. There are probably several in one.

 

For this question mail I didn't use my own polygons, just circle, rotate_extrude and minkowski with a sphere.
The preview is fine, the rendering doesn't say enything but stays empty. Thats my first question: why is there no error AND no output?
It brings an error when you change the "add_rotate" in cutomizer. What brings me to the 2nd question: why does a rotation bring different errors?
And last but not least: how can I bring this object to render with a "add_rotate"=7 at all? Where is the error / what I'm doing wrong?

 

best

Dietrich

 

Virus-free. www.avg.com


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD Admin - email* me if you need anything, or if I've done something stupid...
* on the Forum, click on my MichaelAtOz label, there is a link to email me.

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

Re: rendering problem

nophead
It works fine for me if I flush the cache before F6 but not if I do F5, F6. So it is not a bug in Minkowski, it is just the normal PolySet grid snap bug that breaks topology and caches it.

On Tue, 26 May 2020 at 04:15, OzAtMichael <[hidden email]> wrote:

BTW those inverted triangle z-fight when it is moved. I presume that means it is duplicated, one correct, the other inverse.

 


From: Discuss [mailto:[hidden email]] On Behalf Of OzAtMichael
Sent: Tue, 26 May 2020 12:31
To: 'OpenSCAD general discussion'
Subject: Re: [OpenSCAD] rendering problem

 

> The preview is fine, the rendering doesn't say enything but stays empty. Thats my first question: why is there no error AND no output?

I get a CGAL error,

 

Rendering Polygon Mesh using CGAL...

ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion violation! Expr: e->incident_sface() != SFace_const_handle() File: /mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_S2/SM_const_decorator.h Line: 329

Geometries in cache: 8

Geometry cache size in bytes: 80896

CGAL Polyhedrons in cache: 1

CGAL cache size in bytes: 0

Total rendering time: 0 hours, 0 minutes, 0 seconds

Rendering finished.

 

If you missed that and tried F6 again, you don't get the error as the geometry is cached.

Whenever you have strange things like that it is good to try Design/Flush-cache.

 

Thank you, you have found a simple example of a bug I have seen hiding, where F5 then F6 has a CGAL error, but F6 alone (fresh run or flush cache) does not, but the exported STL is bad.

 

> What brings me to the 2nd question: why does a rotation bring different errors?

 

A change in rotation will produce different angles where faces meet, sometimes they meet in a way that is non-manifold, like an edge or point meeting exactly in the middle of a face.

But in this case I suspect a bug.

 

Interesting what I found inside (with add_rotate=7):

 

 

 


From: Discuss [mailto:[hidden email]] On Behalf Of dpa
Sent: Tue, 26 May 2020 07:09
To: [hidden email]
Subject: [OpenSCAD] rendering problem

 

Hey,

I was using OpenSCAD because it's so reliable, but yesterday I was very disappointed. I researched the frequing same problem for almost exactly one day now and just couldn't get any further. There are probably several in one.

 

For this question mail I didn't use my own polygons, just circle, rotate_extrude and minkowski with a sphere.
The preview is fine, the rendering doesn't say enything but stays empty. Thats my first question: why is there no error AND no output?
It brings an error when you change the "add_rotate" in cutomizer. What brings me to the 2nd question: why does a rotation bring different errors?
And last but not least: how can I bring this object to render with a "add_rotate"=7 at all? Where is the error / what I'm doing wrong?

 

best

Dietrich

 

Virus-free. www.avg.com

_______________________________________________
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: rendering problem

MichaelAtOz
Administrator
nophead wrote
> It works fine for me if I flush the cache before F6 but not if I do F5,
> F6.
> So it is not a bug in Minkowski, it is just the normal PolySet grid snap
> bug that breaks topology and caches it.

I'm not so sure.
As I said, z-fighting outside-face & inside-face.
In Netfabb I was able to delete the wrong face, and the right one was then
exposed.
I'm still looking, but it does look like duplicated faces.



-----
Admin - email* me if you need anything,  or if I've done something stupid...

* click on my MichaelAtOz label, there is a link to email me.

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.

--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD Admin - email* me if you need anything, or if I've done something stupid...
* on the Forum, click on my MichaelAtOz label, there is a link to email me.

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

Re: rendering problem

nophead
As long as I flush the cache and do F6 it all looks fine to me and I can export the STL to Netfabb and that says it's fine as well.

On Tue, 26 May 2020 at 11:41, MichaelAtOz <[hidden email]> wrote:
nophead wrote
> It works fine for me if I flush the cache before F6 but not if I do F5,
> F6.
> So it is not a bug in Minkowski, it is just the normal PolySet grid snap
> bug that breaks topology and caches it.

I'm not so sure.
As I said, z-fighting outside-face & inside-face.
In Netfabb I was able to delete the wrong face, and the right one was then
exposed.
I'm still looking, but it does look like duplicated faces.



-----
Admin - email* me if you need anything,  or if I've done something stupid...

* click on my MichaelAtOz label, there is a link to email me.

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.

--
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: rendering problem

cacb
In reply to this post by Ronaldo
On 2020-05-26 00:06, Ronaldo Persiano wrote:
> Congratulations! You have found a bug in the minkowski operator. That
> is what I get with Thrown Together:

Could be an intermittent problem, or behaviour depends on version of
OpenSCAD and/or operating system. It is not necessarily minkowski that
fails, since difference is the final operation.

I tried with OpenSCAD 2017.01.20 under Win10 and it shows no obvious
problems (but see below), it is reported as

Total rendering time: 0 hours, 0 minutes, 10 seconds
    Top level object is a 3D object:
    Simple:        yes
    Vertices:      369
    Halfedges:    1556
    Edges:         778
    Halffacets:    826
    Facets:        413
    Volumes:         3
Rendering finished.
STL export finished.

However, testing the exported STL in polyfix reveals a higher number of
faces (628) compared to what OpenSCAD reports (413), which is kind of
strange.

polyhedron 0 ================= volume=1469.81, dtol=0.01, atol=1e-06,
maxiter=10
iteration 0: vertices=1884 faces=628
              warning: 4 zero area faces.
              warning: nonmanifold edges: uc(1)=1884
              merged 1574 vertices
              removed 16 collapsed or zero area faces
              removed 2 duplicate faces
              removed 2 nonmanifold faces
              total changes=1594
              no warnings

iteration 1: vertices=310 faces=608
              removed 2 unused vertices
              total changes=2
              no warnings

iteration 2: vertices=308 faces=608
              total changes=0
              no warnings

Summary:
              polyhedron 0: vertices=308 faces=608 : no warnings

When instead exporting the same model from OpenSCAD to OFF format, it
showed an even higher number of faces (710):

polyhedron 0 ================= volume=1469.81, dtol=0.01, atol=1e-06,
maxiter=10
iteration 0: vertices=359 faces=710
              warning: 86 zero area faces.
              merged 49 vertices
              removed 98 collapsed or zero area faces
              removed 2 duplicate faces
              removed 2 nonmanifold faces
              total changes=151
              no warnings

iteration 1: vertices=310 faces=608
              removed 2 unused vertices
              total changes=2
              no warnings

iteration 2: vertices=308 faces=608
              total changes=0
              no warnings

Summary:
              polyhedron 0: vertices=308 faces=608 : no warnings

As you can see, polyfix resolved both of the above to vertices=308
faces=608, even if the starting points were different. I think this
shows that at least part of the problems lie in file export code.

It does not make sense that the number of faces exported depends on the
file format chosen. Clearly, there is no check for zero area faces on
file export in OpenSCAD.


I also tried this, which seemed to work
https://gist.github.com/arnholm/de50168cd1a477be1de116e100a8066a

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: rendering problem

MichaelAtOz'
In reply to this post by nophead

All well & good, but F5+F6 should work.

It needs to be fixed.

Your render() based designs are probably prone to this issue.

 

In this specific case, Flush Cache & F6 & Export STL, produced a broken STL, that one on the Netfabb images above.

 


From: Discuss [mailto:[hidden email]] On Behalf Of nop head
Sent: Tue, 26 May 2020 21:03
To: OpenSCAD general discussion
Subject: Re: [OpenSCAD] rendering problem

 

As long as I flush the cache and do F6 it all looks fine to me and I can export the STL to Netfabb and that says it's fine as well.

 

On Tue, 26 May 2020 at 11:41, MichaelAtOz <[hidden email]> wrote:

nophead wrote
> It works fine for me if I flush the cache before F6 but not if I do F5,
> F6.
> So it is not a bug in Minkowski, it is just the normal PolySet grid snap
> bug that breaks topology and caches it.

I'm not so sure.
As I said, z-fighting outside-face & inside-face.
In Netfabb I was able to delete the wrong face, and the right one was then
exposed.
I'm still looking, but it does look like duplicated faces.



-----
Admin - email* me if you need anything,  or if I've done something stupid...

* click on my MichaelAtOz label, there is a link to email me.

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.

--
Sent from: http://forum.openscad.org/

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


Virus-free. www.avg.com

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

Re: rendering problem

nophead
Yes the PolySet grid snap bug should be fixed but it is hard. It is exactly the same issue that STL files have. OpenSCAD needs a mesh fixer to make it robust whenever vertex resolution is reduced. If it had one then it could also fix broken STL imports and bad polyhedron data and stop this endless list of why does my model not render.

On Tue, 26 May 2020 at 12:53, Michael Marx <[hidden email]> wrote:

All well & good, but F5+F6 should work.

It needs to be fixed.

Your render() based designs are probably prone to this issue.

 

In this specific case, Flush Cache & F6 & Export STL, produced a broken STL, that one on the Netfabb images above.

 


From: Discuss [mailto:[hidden email]] On Behalf Of nop head
Sent: Tue, 26 May 2020 21:03
To: OpenSCAD general discussion
Subject: Re: [OpenSCAD] rendering problem

 

As long as I flush the cache and do F6 it all looks fine to me and I can export the STL to Netfabb and that says it's fine as well.

 

On Tue, 26 May 2020 at 11:41, MichaelAtOz <[hidden email]> wrote:

nophead wrote
> It works fine for me if I flush the cache before F6 but not if I do F5,
> F6.
> So it is not a bug in Minkowski, it is just the normal PolySet grid snap
> bug that breaks topology and caches it.

I'm not so sure.
As I said, z-fighting outside-face & inside-face.
In Netfabb I was able to delete the wrong face, and the right one was then
exposed.
I'm still looking, but it does look like duplicated faces.



-----
Admin - email* me if you need anything,  or if I've done something stupid...

* click on my MichaelAtOz label, there is a link to email me.

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.

--
Sent from: http://forum.openscad.org/

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


Virus-free. www.avg.com
_______________________________________________
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: rendering problem

Ronaldo
In reply to this post by nophead
It works fine for me if I flush the cache before F6 but not if I do F5, F6. So it is not a bug in Minkowski, it is just the normal PolySet grid snap bug that breaks topology and caches it.

Help me to understand that.  It seems that CGAL is not called for doing minkowski. What library does the minkowski operations? What data structures are used for that?


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

Re: rendering problem

nophead
In reply to this post by cacb
I am sure CGAL is used to do 3D Minkowski, that is why it is monumentally slow.

I get

Total rendering time: 0 hours, 0 minutes, 9 seconds

Top level object is a 3D object:

Simple: yes

Vertices: 359

Halfedges: 1498

Edges: 749

Halffacets: 790

Facets: 395

Volumes: 3

Rendering finished.


NetFabb says there are 906 edges and 604 triangles in the STL. Presumably that is because CGAL outputs polygons and they have to be broken into triangles for STL.

image.png

On Tue, 26 May 2020 at 14:17, <[hidden email]> wrote:
On 2020-05-26 00:06, Ronaldo Persiano wrote:
> Congratulations! You have found a bug in the minkowski operator. That
> is what I get with Thrown Together:

Could be an intermittent problem, or behaviour depends on version of
OpenSCAD and/or operating system. It is not necessarily minkowski that
fails, since difference is the final operation.

I tried with OpenSCAD 2017.01.20 under Win10 and it shows no obvious
problems (but see below), it is reported as

Total rendering time: 0 hours, 0 minutes, 10 seconds
    Top level object is a 3D object:
    Simple:        yes
    Vertices:      369
    Halfedges:    1556
    Edges:         778
    Halffacets:    826
    Facets:        413
    Volumes:         3
Rendering finished.
STL export finished.

However, testing the exported STL in polyfix reveals a higher number of
faces (628) compared to what OpenSCAD reports (413), which is kind of
strange.

polyhedron 0 ================= volume=1469.81, dtol=0.01, atol=1e-06,
maxiter=10
iteration 0: vertices=1884 faces=628
              warning: 4 zero area faces.
              warning: nonmanifold edges: uc(1)=1884
              merged 1574 vertices
              removed 16 collapsed or zero area faces
              removed 2 duplicate faces
              removed 2 nonmanifold faces
              total changes=1594
              no warnings

iteration 1: vertices=310 faces=608
              removed 2 unused vertices
              total changes=2
              no warnings

iteration 2: vertices=308 faces=608
              total changes=0
              no warnings

Summary:
              polyhedron 0: vertices=308 faces=608 : no warnings

When instead exporting the same model from OpenSCAD to OFF format, it
showed an even higher number of faces (710):

polyhedron 0 ================= volume=1469.81, dtol=0.01, atol=1e-06,
maxiter=10
iteration 0: vertices=359 faces=710
              warning: 86 zero area faces.
              merged 49 vertices
              removed 98 collapsed or zero area faces
              removed 2 duplicate faces
              removed 2 nonmanifold faces
              total changes=151
              no warnings

iteration 1: vertices=310 faces=608
              removed 2 unused vertices
              total changes=2
              no warnings

iteration 2: vertices=308 faces=608
              total changes=0
              no warnings

Summary:
              polyhedron 0: vertices=308 faces=608 : no warnings

As you can see, polyfix resolved both of the above to vertices=308
faces=608, even if the starting points were different. I think this
shows that at least part of the problems lie in file export code.

It does not make sense that the number of faces exported depends on the
file format chosen. Clearly, there is no check for zero area faces on
file export in OpenSCAD.


I also tried this, which seemed to work
https://gist.github.com/arnholm/de50168cd1a477be1de116e100a8066a

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: rendering problem

cacb
In reply to this post by Ronaldo
On 2020-05-26 14:42, Ronaldo Persiano wrote:
> <[hidden email]> wrote:
>
>> It works fine for me if I flush the cache before F6 but not if I do
>> F5, F6. So it is not a bug in Minkowski, it is just the normal
>> PolySet grid snap bug that breaks topology and caches it.
>
> Help me to understand that.  It seems that CGAL is not called for
> doing minkowski. What library does the minkowski operations? What data
> structures are used for that?

I believe OpenSCADs implementation of 3D Minkowski sums rely on CGAL
https://doc.cgal.org/latest/Minkowski_sum_3

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: rendering problem

MichaelAtOz'
In reply to this post by nophead

For consistency please use add_rotate=7, it seems to be worse.

 


From: Discuss [mailto:[hidden email]] On Behalf Of nop head
Sent: Tue, 26 May 2020 23:28
To: OpenSCAD general discussion
Subject: Re: [OpenSCAD] rendering problem

 

I am sure CGAL is used to do 3D Minkowski, that is why it is monumentally slow.

 

I get

 

Total rendering time: 0 hours, 0 minutes, 9 seconds

Top level object is a 3D object:

Simple: yes

Vertices: 359

Halfedges: 1498

Edges: 749

Halffacets: 790

Facets: 395

Volumes: 3

Rendering finished.

 

NetFabb says there are 906 edges and 604 triangles in the STL. Presumably that is because CGAL outputs polygons and they have to be broken into triangles for STL.

 

image.png

 

On Tue, 26 May 2020 at 14:17, <[hidden email]> wrote:

On 2020-05-26 00:06, Ronaldo Persiano wrote:
> Congratulations! You have found a bug in the minkowski operator. That
> is what I get with Thrown Together:

Could be an intermittent problem, or behaviour depends on version of
OpenSCAD and/or operating system. It is not necessarily minkowski that
fails, since difference is the final operation.

I tried with OpenSCAD 2017.01.20 under Win10 and it shows no obvious
problems (but see below), it is reported as

Total rendering time: 0 hours, 0 minutes, 10 seconds
    Top level object is a 3D object:
    Simple:        yes
    Vertices:      369
    Halfedges:    1556
    Edges:         778
    Halffacets:    826
    Facets:        413
    Volumes:         3
Rendering finished.
STL export finished.

However, testing the exported STL in polyfix reveals a higher number of
faces (628) compared to what OpenSCAD reports (413), which is kind of
strange.

polyhedron 0 ================= volume=1469.81, dtol=0.01, atol=1e-06,
maxiter=10
iteration 0: vertices=1884 faces=628
              warning: 4 zero area faces.
              warning: nonmanifold edges: uc(1)=1884
              merged 1574 vertices
              removed 16 collapsed or zero area faces
              removed 2 duplicate faces
              removed 2 nonmanifold faces
              total changes=1594
              no warnings

iteration 1: vertices=310 faces=608
              removed 2 unused vertices
              total changes=2
              no warnings

iteration 2: vertices=308 faces=608
              total changes=0
              no warnings

Summary:
              polyhedron 0: vertices=308 faces=608 : no warnings

When instead exporting the same model from OpenSCAD to OFF format, it
showed an even higher number of faces (710):

polyhedron 0 ================= volume=1469.81, dtol=0.01, atol=1e-06,
maxiter=10
iteration 0: vertices=359 faces=710
              warning: 86 zero area faces.
              merged 49 vertices
              removed 98 collapsed or zero area faces
              removed 2 duplicate faces
              removed 2 nonmanifold faces
              total changes=151
              no warnings

iteration 1: vertices=310 faces=608
              removed 2 unused vertices
              total changes=2
              no warnings

iteration 2: vertices=308 faces=608
              total changes=0
              no warnings

Summary:
              polyhedron 0: vertices=308 faces=608 : no warnings

As you can see, polyfix resolved both of the above to vertices=308
faces=608, even if the starting points were different. I think this
shows that at least part of the problems lie in file export code.

It does not make sense that the number of faces exported depends on the
file format chosen. Clearly, there is no check for zero area faces on
file export in OpenSCAD.


I also tried this, which seemed to work
https://gist.github.com/arnholm/de50168cd1a477be1de116e100a8066a

Carsten Arnholm







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


Virus-free. www.avg.com

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

Re: rendering problem

nophead
That does produce a broken STL where the lines are on the sides.

image.png

I expect CGAL produces vertices that are very close together and they collapse during export to STL.

On Tue, 26 May 2020 at 14:39, Michael Marx <[hidden email]> wrote:

For consistency please use add_rotate=7, it seems to be worse.

 


From: Discuss [mailto:[hidden email]] On Behalf Of nop head
Sent: Tue, 26 May 2020 23:28
To: OpenSCAD general discussion
Subject: Re: [OpenSCAD] rendering problem

 

I am sure CGAL is used to do 3D Minkowski, that is why it is monumentally slow.

 

I get

 

Total rendering time: 0 hours, 0 minutes, 9 seconds

Top level object is a 3D object:

Simple: yes

Vertices: 359

Halfedges: 1498

Edges: 749

Halffacets: 790

Facets: 395

Volumes: 3

Rendering finished.

 

NetFabb says there are 906 edges and 604 triangles in the STL. Presumably that is because CGAL outputs polygons and they have to be broken into triangles for STL.

 

image.png

 

On Tue, 26 May 2020 at 14:17, <[hidden email]> wrote:

On 2020-05-26 00:06, Ronaldo Persiano wrote:
> Congratulations! You have found a bug in the minkowski operator. That
> is what I get with Thrown Together:

Could be an intermittent problem, or behaviour depends on version of
OpenSCAD and/or operating system. It is not necessarily minkowski that
fails, since difference is the final operation.

I tried with OpenSCAD 2017.01.20 under Win10 and it shows no obvious
problems (but see below), it is reported as

Total rendering time: 0 hours, 0 minutes, 10 seconds
    Top level object is a 3D object:
    Simple:        yes
    Vertices:      369
    Halfedges:    1556
    Edges:         778
    Halffacets:    826
    Facets:        413
    Volumes:         3
Rendering finished.
STL export finished.

However, testing the exported STL in polyfix reveals a higher number of
faces (628) compared to what OpenSCAD reports (413), which is kind of
strange.

polyhedron 0 ================= volume=1469.81, dtol=0.01, atol=1e-06,
maxiter=10
iteration 0: vertices=1884 faces=628
              warning: 4 zero area faces.
              warning: nonmanifold edges: uc(1)=1884
              merged 1574 vertices
              removed 16 collapsed or zero area faces
              removed 2 duplicate faces
              removed 2 nonmanifold faces
              total changes=1594
              no warnings

iteration 1: vertices=310 faces=608
              removed 2 unused vertices
              total changes=2
              no warnings

iteration 2: vertices=308 faces=608
              total changes=0
              no warnings

Summary:
              polyhedron 0: vertices=308 faces=608 : no warnings

When instead exporting the same model from OpenSCAD to OFF format, it
showed an even higher number of faces (710):

polyhedron 0 ================= volume=1469.81, dtol=0.01, atol=1e-06,
maxiter=10
iteration 0: vertices=359 faces=710
              warning: 86 zero area faces.
              merged 49 vertices
              removed 98 collapsed or zero area faces
              removed 2 duplicate faces
              removed 2 nonmanifold faces
              total changes=151
              no warnings

iteration 1: vertices=310 faces=608
              removed 2 unused vertices
              total changes=2
              no warnings

iteration 2: vertices=308 faces=608
              total changes=0
              no warnings

Summary:
              polyhedron 0: vertices=308 faces=608 : no warnings

As you can see, polyfix resolved both of the above to vertices=308
faces=608, even if the starting points were different. I think this
shows that at least part of the problems lie in file export code.

It does not make sense that the number of faces exported depends on the
file format chosen. Clearly, there is no check for zero area faces on
file export in OpenSCAD.


I also tried this, which seemed to work
https://gist.github.com/arnholm/de50168cd1a477be1de116e100a8066a

Carsten Arnholm







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


Virus-free. www.avg.com
_______________________________________________
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
tp3
Reply | Threaded
Open this post in threaded view
|

Re: rendering problem

tp3
In reply to this post by nophead
On 26.05.20 15:28, nop head wrote:
> I am sure CGAL is used to do 3D Minkowski, that is
> why it is monumentally slow.

Yes, CGAL is quite involved, but not the actual
minkowski implementation.

OpenSCAD normally uses CGAL to (optionally)
deconstruct the object into convex parts and
generates a point cloud based on positioning the
second object on all vertices of the convex parts
and afterwards does a convex hull on those.

Afterwards the separate convex minkowski parts
are unioned together -> this is where the slowness
can come in big time depending on how much parts
were generated.

This can be observed in more detail via

  openscad --debug=cgalutils-applyops

Pretty much worst case scenario as this very low
resolution object decomposes into 124 parts.

minkowski(){
    difference() {
        cube(20, center = true);
        sphere(13, $fn = 16);
    }
    sphere(2);
}

Minkowski: child 0 is nonconvex Nef, decomposing...
Minkowski: decomposed into 124 convex parts
Minkowski: decomposition took 1.029088 s
Minkowski: child 1 is convex and PolySet
Minkowski: Point cloud creation (8 ⨉ 28 -> 224) took 1029.115000 ms
Minkowski: Computing convex hull took 0.000985 s
Minkowski: Point cloud creation (8 ⨉ 28 -> 224) took 0.015000 ms
Minkowski: Computing convex hull took 0.001173 s
[snip...]
Minkowski: Point cloud creation (6 ⨉ 28 -> 168) took 0.057000 ms
Minkowski: Computing convex hull took 0.001939 s
Minkowski: Computing union of 124 parts
Minkowski: Union done: 26.550561 s
Minkowski: Total execution time 28.331127 s

ciao,
  Torsten.

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

Re: rendering problem

Ronaldo


Yes, CGAL is quite involved, but not the actual
minkowski implementation.

OpenSCAD normally uses CGAL to (optionally)
deconstruct the object into convex parts and
generates a point cloud based on positioning the
second object on all vertices of the convex parts
and afterwards does a convex hull on those.

Afterwards the separate convex minkowski parts
are unioned together -> this is where the slowness
can come in big time depending on how much parts
were generated.

This quite clarify my understanding. But how preview deals with minkowski? I imagine that the flow above is pretty much the same except the union in last step. Preview might just throw the convex parts to the z-buffer avoiding the union. And this last process seems to be creating a flipped face.

That is what I get after a fresh F6 followed by a F5:

FlushF6F5.PNG

and that is what comes out from a fresh F5:

FlushF5.PNG

and that last one with Throw Together:

FlushF5TT.PNG

So, it seems there is a bug in the F5 process of minkowski,



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

Re: rendering problem

tp3
On 26.05.20 16:55, Ronaldo Persiano wrote:
> This quite clarify my understanding. But how preview deals
> with minkowski? I imagine that the flow above is pretty
> much the same except the union in last step. Preview might
> just throw the convex parts to the z-buffer avoiding the
> union. And this last process seems to be creating a flipped
> face.

Hmm, I don't think it's using different path, I believe it
actually does the full processing in preview already. But
that's a good point, in theory it should be possible to skip
the union part for preview.

ciao,
  Torsten.

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

Re: rendering problem

cacb
In reply to this post by tp3
On 2020-05-26 15:55, Torsten Paul wrote:

> Yes, CGAL is quite involved, but not the actual
> minkowski implementation.
>
> OpenSCAD normally uses CGAL to (optionally)
> deconstruct the object into convex parts and
> generates a point cloud based on positioning the
> second object on all vertices of the convex parts
> and afterwards does a convex hull on those.
>
> Afterwards the separate convex minkowski parts
> are unioned together -> this is where the slowness
> can come in big time depending on how much parts
> were generated.

Yes. This illustrates however that the only real problem is the slow
execution of boolean operations in CGAL, not the Minkowski subdivision
as such. The Minkowski subdivision into convex components seems like a
daunting and complicated task, but that is largely an illusion. The
convex subdivision problem is complicated only if you require to
optimize (=minimize) the number of convex components in Minkowski
subdivision on the assumption that booleans are slow.

If you have fast booleans it is possible to implement Minkowski sum
using a much simpler approach with many more, but much simpler convex
components. This is exactly what xcsg ( https://github.com/arnholm/xcsg 
) does, and it is at least an order of magnitude faster because carve
booleans are intrinsically quite fast and because one can compute
booleans in multiple threads.

Carsten Arnholm



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