test msg - pls ignore

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

test msg - pls ignore

MichaelAtOz
Administrator
I sent an email, never got thru.



-----
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.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/   time is running out!
--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: test msg - pls ignore

MichaelAtOz
Administrator
Test image, not copied from Debian:
</file/t359/Capture-key-oem-netfabb.jpg>
Shows in preview.



-----
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.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/   time is running out!
--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: test msg - pls ignore

MichaelAtOz
Administrator
Capture post  for Nabble support.



-----
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.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/   time is running out!
--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: test msg - pls ignore

MichaelAtOz
Administrator
In reply to this post by MichaelAtOz
Is it fixed?
</file/t359/avatar_6755_emu.jpg>



-----
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.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/   time is running out!
--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: test msg - pls ignore

MichaelAtOz
Administrator
Is it fixed?
</file/t359/1284801paper_fighting.gif>



-----
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.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/   time is running out!
--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

CGAL error depends on order of unioning

Shaporev, Timur

While working on https://www.thingiverse.com/thing:3762730 I faced strange effect: script produce

ERROR: CGAL error in CGALUtils::applyBinaryOperator union: CGAL ERROR: assertion violation! Expr: itl != it->second.end() File: /mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_external_structure.h Line: 1152

on F6 but some change in order of unioning yields expected result.

I am attaching an archive with both faulty and good versions of scripts.

(The scripts render long enough: more than 20 minutes to preview the first script on my PC and 6 more minutes to render, yet more for the second script.)


If this is new issue I'd appreciate advice on how to (get a ticket number) register it.


Thank you,

Tim



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

20190722.zip (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CGAL error depends on order of unioning

nophead
It probably isn't a bug. It is quite possible to have three objects such that unioning two of them gives a non-manifold result but unioning them in another order doesn't. For example consider two cubes sharing one edge and a third that overlaps that edge. If you do the union one, two, three you will get an error but one, three, two will work and so will any other order because the intermediate results are all manifold.

On Tue, 23 Jul 2019 at 10:08, Shaporev, Timur <[hidden email]> wrote:

While working on https://www.thingiverse.com/thing:3762730 I faced strange effect: script produce

ERROR: CGAL error in CGALUtils::applyBinaryOperator union: CGAL ERROR: assertion violation! Expr: itl != it->second.end() File: /mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_external_structure.h Line: 1152

on F6 but some change in order of unioning yields expected result.

I am attaching an archive with both faulty and good versions of scripts.

(The scripts render long enough: more than 20 minutes to preview the first script on my PC and 6 more minutes to render, yet more for the second script.)


If this is new issue I'd appreciate advice on how to (get a ticket number) register it.


Thank you,

Tim


_______________________________________________
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: test msg - pls ignore

MichaelAtOz
Administrator
In reply to this post by MichaelAtOz
Fixed?
<http://forum.openscad.org/file/t359/avatar_20305_cylon_kitty.gif>



-----
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.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/   time is running out!
--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: test msg - pls ignore

MichaelAtOz
Administrator
Test links ie 'Link' button on forum.
As per  problem reported
<http://support.nabble.com/Inserting-images-and-links-not-inline-or-formatted-in-final-post-td7603030.html>  
to Nabble.



-----
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.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/   time is running out!
--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: CGAL error depends on order of unioning

MichaelAtOz
Administrator
In reply to this post by Shaporev, Timur
Shaporev, Timur wrote

> While working on https://www.thingiverse.com/thing:3762730 I faced strange
> effect: script produce
>
> ERROR: CGAL error in CGALUtils::applyBinaryOperator union: CGAL ERROR:
> assertion violation! Expr: itl != it->second.end() File:
> /mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_external_structure.h
> Line: 1152
>
> on F6 but some change in order of unioning yields expected result.
>
> I am attaching an archive with both faulty and good versions of scripts.
>
> (The scripts render long enough: more than 20 minutes to preview the first
> script on my PC and 6 more minutes to render, yet more for the second
> script.)
>
>
> If this is new issue I'd appreciate advice on how to (get a ticket number)
> register it.
>
>
> Thank you,
>
> Tim
>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> 20190722.zip (8K)
> &lt;http://forum.openscad.org/attachment/27016/0/20190722.zip&gt;

I had a look at the code.
With the combination of operations, mostly lined-up at the same boundaries
you are prone to getting edges of two objects aligning, which creates
non-manifold geometry.
At such high resolution you increase the chances of such common edges
aligning.


Firstly, the preview artefacts you have can be fixed by using convexity=10
in linear_extrude (in two places), it makes looking at the detail easier.

At first I suspected the four quarters probably had the symmetry to cause
this.
But not this time.
It is an art you learn, but I look for points of convergence.

Second try was here:
<http://forum.openscad.org/file/t359/Capture_ring_centre.jpg>
The middle edge of the inside of the central ring hole, that aligns with the
surface of the back of the face.

Try this as an example

#cube([40,40,10]);
translate([5,20,20])
  rotate([0,90,0])
    cylinder(h=30,r=10,$fn=12);

F6 gets "UI-WARNING: Object may not be a valid 2-manifold and may need
repair!"

So in fail1.scad the easy way to fix it is to rotate that cylinder around
z-axis a small amount, so the line is not co-incident with that face.

difference() {
    union() {
        // assemble them back again
        quarter(); mirror([0,1,0]) quarter();
        mirror([0,0,1]) {
            quarter(); mirror([0,1,0]) quarter();
        }
        rotate([0,0,1])    //    
<--------------------------------------------
        rotate_extrude()
            hull() {
                translate([Rmid,ring_min_width/2-Rth]) circle(Rth);
                translate([Rmid,Rth-ring_min_width/2]) circle(Rth);
            }
        hull() {
            translate([Rmid, yl,zl-Rm]) sphere(Rth);

With that F6 completes without error.





-----
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.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/   time is running out!
--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: CGAL error depends on order of unioning

Shaporev, Timur

Hi Michael,

thank you for the answer but what I was asking is not preview artifact or a way to tweak my design to get around a trap in OpenSCAD. (Preview is not an issue and as I wrote I have found a way to get the result).


The final geometry is valid but OpenSCAD failed to output it, so I see this as a bug, no matter how difficult it is to fix.


Well, anyway, now it is off my hands.

Thank you,
Tim


From: Discuss <[hidden email]> on behalf of MichaelAtOz <[hidden email]>
Sent: 24 July 2019 07:43
To: [hidden email]
Subject: Re: [OpenSCAD] CGAL error depends on order of unioning
 
Shaporev, Timur wrote
> While working on https://www.thingiverse.com/thing:3762730 I faced strange
> effect: script produce
>
> ERROR: CGAL error in CGALUtils::applyBinaryOperator union: CGAL ERROR:
> assertion violation! Expr: itl != it->second.end() File:
> /mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_external_structure.h
> Line: 1152
>
> on F6 but some change in order of unioning yields expected result.
>
> I am attaching an archive with both faulty and good versions of scripts.
>
> (The scripts render long enough: more than 20 minutes to preview the first
> script on my PC and 6 more minutes to render, yet more for the second
> script.)
>
>
> If this is new issue I'd appreciate advice on how to (get a ticket number)
> register it.
>
>
> Thank you,
>
> Tim
>
>
> _______________________________________________
> OpenSCAD mailing list

> Discuss@.openscad

> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> 20190722.zip (8K)
> &lt;http://forum.openscad.org/attachment/27016/0/20190722.zip&gt;

I had a look at the code.
With the combination of operations, mostly lined-up at the same boundaries
you are prone to getting edges of two objects aligning, which creates
non-manifold geometry.
At such high resolution you increase the chances of such common edges
aligning.


Firstly, the preview artefacts you have can be fixed by using convexity=10
in linear_extrude (in two places), it makes looking at the detail easier.

At first I suspected the four quarters probably had the symmetry to cause
this.
But not this time.
It is an art you learn, but I look for points of convergence.

Second try was here:
<http://forum.openscad.org/file/t359/Capture_ring_centre.jpg>
The middle edge of the inside of the central ring hole, that aligns with the
surface of the back of the face.

Try this as an example

#cube([40,40,10]);
translate([5,20,20])
  rotate([0,90,0])
    cylinder(h=30,r=10,$fn=12);

F6 gets "UI-WARNING: Object may not be a valid 2-manifold and may need
repair!"

So in fail1.scad the easy way to fix it is to rotate that cylinder around
z-axis a small amount, so the line is not co-incident with that face.

difference() {
    union() {
        // assemble them back again
        quarter(); mirror([0,1,0]) quarter();
        mirror([0,0,1]) {
            quarter(); mirror([0,1,0]) quarter();
        }
        rotate([0,0,1])    //    
<--------------------------------------------
        rotate_extrude()
            hull() {
                translate([Rmid,ring_min_width/2-Rth]) circle(Rth);
                translate([Rmid,Rth-ring_min_width/2]) circle(Rth);
            }
        hull() {
            translate([Rmid, yl,zl-Rm]) sphere(Rth);

With that F6 completes without error.





-----
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.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/   time is running out!
--
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: CGAL error depends on order of unioning

Tim V. Shaporev
In reply to this post by nophead
Let me put it different way: is it documented anywhere
1) that all intermediate results should be manifold and
2) exact order of operations (note that enclosing quarters in additional
explicit - or implicit - union like in 'good1' resolves the issue).
If these are documented then it is my fault that I did not read it
(though I'd like to have the issue fixed as an enhancement).

But as far as the final geometry is correct I see this as a bug
(though I do understand that it could be too hard to fix).

And, finally, thank you for the explanation - it is helpful.

:-)
Tim

On 7/23/2019 12:36 PM, nop head wrote:

> It probably isn't a bug. It is quite possible to have three objects such
> that unioning two of them gives a non-manifold result but unioning them
> in another order doesn't. For example consider two cubes sharing one
> edge and a third that overlaps that edge. If you do the union one, two,
> three you will get an error but one, three, two will work and so will
> any other order because the intermediate results are all manifold.
>
> On Tue, 23 Jul 2019 at 10:08, Shaporev, Timur <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     While working on https://www.thingiverse.com/thing:3762730 I faced
>     strange effect: script produce
>
>     ERROR: CGAL error in CGALUtils::applyBinaryOperator union: CGAL
>     ERROR: assertion violation! Expr: itl != it->second.end() File:
>     /mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_external_structure.h
>     Line: 1152
>
>     on F6 but some change in order of unioning yields expected result.
>
>     I am attaching an archive with both faulty and good versions of scripts.
>
>     (The scripts render long enough: more than 20 minutes to preview the
>     first script on my PC and 6 more minutes to render, yet more for the
>     second script.)
>
>
>     If this is new issue I'd appreciate advice on how to (get a ticket
>     number) register it.
>
>
>     Thank you,
>
>     Tim
>
>
>     _______________________________________________
>     OpenSCAD mailing list
>     [hidden email] <mailto:[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
>


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

Re: CGAL error depends on order of unioning

nophead
Basically everything that needs to be rendered to a solid has to be manifold, including all the intermediate steps, because the library used, CGAL, only handles manifold objects. It isn't a bug, it is designed that way.

It won't change unless OpenSCAD stops using CGAL for its CSG operations. Note that CSG operations over manifold geometry is not closed, so no matter what library is used you can make non-manifold geometry with union, difference and intersection. STL files can not represent non-manifold geometry and 3D printers can not print it. These things will never change.

On Wed, 24 Jul 2019 at 14:00, Tim V. Shaporev <[hidden email]> wrote:
Let me put it different way: is it documented anywhere
1) that all intermediate results should be manifold and
2) exact order of operations (note that enclosing quarters in additional
explicit - or implicit - union like in 'good1' resolves the issue).
If these are documented then it is my fault that I did not read it
(though I'd like to have the issue fixed as an enhancement).

But as far as the final geometry is correct I see this as a bug
(though I do understand that it could be too hard to fix).

And, finally, thank you for the explanation - it is helpful.

:-)
Tim

On 7/23/2019 12:36 PM, nop head wrote:
> It probably isn't a bug. It is quite possible to have three objects such
> that unioning two of them gives a non-manifold result but unioning them
> in another order doesn't. For example consider two cubes sharing one
> edge and a third that overlaps that edge. If you do the union one, two,
> three you will get an error but one, three, two will work and so will
> any other order because the intermediate results are all manifold.
>
> On Tue, 23 Jul 2019 at 10:08, Shaporev, Timur <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     While working on https://www.thingiverse.com/thing:3762730 I faced
>     strange effect: script produce
>
>     ERROR: CGAL error in CGALUtils::applyBinaryOperator union: CGAL
>     ERROR: assertion violation! Expr: itl != it->second.end() File:
>     /mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_external_structure.h
>     Line: 1152
>
>     on F6 but some change in order of unioning yields expected result.
>
>     I am attaching an archive with both faulty and good versions of scripts.
>
>     (The scripts render long enough: more than 20 minutes to preview the
>     first script on my PC and 6 more minutes to render, yet more for the
>     second script.)
>
>
>     If this is new issue I'd appreciate advice on how to (get a ticket
>     number) register it.
>
>
>     Thank you,
>
>     Tim
>
>
>     _______________________________________________
>     OpenSCAD mailing list
>     [hidden email] <mailto:[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
>


_______________________________________________
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: CGAL error depends on order of unioning

Tim V. Shaporev
Sigh.
The final geometry is valid, so no issue with either STL or 3D printer.

And I know the way to fix this particular issue using CGAL
(though it seems to be too slow for practical usage).

On 7/24/2019 4:22 PM, nop head wrote:

> Basically everything that needs to be rendered to a solid has to be
> manifold, including all the intermediate steps, because the library
> used, CGAL, only handles manifold objects. It isn't a bug, it is
> designed that way.
>
> It won't change unless OpenSCAD stops using CGAL for its CSG operations.
> Note that CSG operations over manifold geometry is not closed, so no
> matter what library is used you can make non-manifold geometry with
> union, difference and intersection. STL files can not represent
> non-manifold geometry and 3D printers can not print it. These things
> will never change.
>
> On Wed, 24 Jul 2019 at 14:00, Tim V. Shaporev <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Let me put it different way: is it documented anywhere
>     1) that all intermediate results should be manifold and
>     2) exact order of operations (note that enclosing quarters in
>     additional
>     explicit - or implicit - union like in 'good1' resolves the issue).
>     If these are documented then it is my fault that I did not read it
>     (though I'd like to have the issue fixed as an enhancement).
>
>     But as far as the final geometry is correct I see this as a bug
>     (though I do understand that it could be too hard to fix).
>
>     And, finally, thank you for the explanation - it is helpful.
>
>     :-)
>     Tim
>
>     On 7/23/2019 12:36 PM, nop head wrote:
>      > It probably isn't a bug. It is quite possible to have three
>     objects such
>      > that unioning two of them gives a non-manifold result but
>     unioning them
>      > in another order doesn't. For example consider two cubes sharing one
>      > edge and a third that overlaps that edge. If you do the union
>     one, two,
>      > three you will get an error but one, three, two will work and so
>     will
>      > any other order because the intermediate results are all manifold.
>      >
>      > On Tue, 23 Jul 2019 at 10:08, Shaporev, Timur <[hidden email]
>     <mailto:[hidden email]>
>      > <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>      >
>      >     While working on https://www.thingiverse.com/thing:3762730 I
>     faced
>      >     strange effect: script produce
>      >
>      >     ERROR: CGAL error in CGALUtils::applyBinaryOperator union: CGAL
>      >     ERROR: assertion violation! Expr: itl != it->second.end() File:
>      >  
>       /mxe/usr/x86_64-w64-mingw32.static.posix/include/CGAL/Nef_3/SNC_external_structure.h
>      >     Line: 1152
>      >
>      >     on F6 but some change in order of unioning yields expected
>     result.
>      >
>      >     I am attaching an archive with both faulty and good versions
>     of scripts.
>      >
>      >     (The scripts render long enough: more than 20 minutes to
>     preview the
>      >     first script on my PC and 6 more minutes to render, yet more
>     for the
>      >     second script.)
>      >
>      >
>      >     If this is new issue I'd appreciate advice on how to (get a
>     ticket
>      >     number) register it.
>      >
>      >
>      >     Thank you,
>      >
>      >     Tim
>      >
>      >
>      >     _______________________________________________
>      >     OpenSCAD mailing list
>      > [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>      > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>      >
>      >
>      > _______________________________________________
>      > OpenSCAD mailing list
>      > [hidden email] <mailto:[hidden email]>
>      > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>      >
>
>
>     _______________________________________________
>     OpenSCAD mailing list
>     [hidden email] <mailto:[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
>


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

Re: CGAL error depends on order of unioning

Ronaldo
In reply to this post by nophead
nop head <[hidden email]> written:
Basically everything that needs to be rendered to a solid has to be manifold, including all the intermediate steps, because the library used, CGAL, only handles manifold objects. It isn't a bug, it is designed that way.

That is not precisely true. When we have just one polyhedron() primitive, it can generate a STL file even if the polyhedron is not a manyfold.
For instance:

polyhedron([[0,0,0], [1,0,0],[0,1,0]],[[0,1,2]]);

is just a triangle and it renders fine and generate a STL file. Even polyhedron() with self-intersection are accepted by CGAL when are alone.

 STL files can not represent non-manifold geometry and 3D printers can not print it. These things will never change.

That is not also true. The above example shows that OpenSCAD is able to generate non-manifold STL files. After all, STL files are just a soup of triangles.

I don't agree either that non-manifold can't be 3D printed. The object bellow is printable:

union()
{
  cube(1);
  translate([1,1,0]) cube(1);
  translate([0,0,0.9]) cube(2);
  translate([0,0,-1.9]) cube(2);
}
and it will be solid in the sense that it will not fall apart easily. It can't be rendered by OpenSCAD (CGAL) as is but it could be represented in a unique polyhedron and then a STL file could be generated by OpenSCAD.



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

Re: CGAL error depends on order of unioning

nophead
Unless you do a CSG operation CGAL isn't involved. So yes you can create any old polyhedron and make an STL but only manifold STLs allow the topology to be reconstructed unambiguously.

When I said you can print a non-mainlined object I mean they cannot exist in reality so can't be printed. Yes you can send a non-manifold STL to a 3D printer and something may come out, depending on the slicer, but it will always be a manifold object and not what the file represents.

On Wed, 24 Jul 2019 at 19:31, Ronaldo Persiano <[hidden email]> wrote:
nop head <[hidden email]> written:
Basically everything that needs to be rendered to a solid has to be manifold, including all the intermediate steps, because the library used, CGAL, only handles manifold objects. It isn't a bug, it is designed that way.

That is not precisely true. When we have just one polyhedron() primitive, it can generate a STL file even if the polyhedron is not a manyfold.
For instance:

polyhedron([[0,0,0], [1,0,0],[0,1,0]],[[0,1,2]]);

is just a triangle and it renders fine and generate a STL file. Even polyhedron() with self-intersection are accepted by CGAL when are alone.

 STL files can not represent non-manifold geometry and 3D printers can not print it. These things will never change.

That is not also true. The above example shows that OpenSCAD is able to generate non-manifold STL files. After all, STL files are just a soup of triangles.

I don't agree either that non-manifold can't be 3D printed. The object bellow is printable:

union()
{
  cube(1);
  translate([1,1,0]) cube(1);
  translate([0,0,0.9]) cube(2);
  translate([0,0,-1.9]) cube(2);
}
and it will be solid in the sense that it will not fall apart easily. It can't be rendered by OpenSCAD (CGAL) as is but it could be represented in a unique polyhedron and then a STL file could be generated by OpenSCAD.


_______________________________________________
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