NH
nop head
Tue, May 26, 2020 4:47 PM
I think the flipped triangle with F5 is because it converts it back to a
PolySet. When there are very close vertices the grid snap and tessellation
can cause inverted triangles. With the F6 version the CGAL faces are not
all triangles but with F5 they are.
On Tue, 26 May 2020 at 17:26, arnholm@arnholm.org wrote:
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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I think the flipped triangle with F5 is because it converts it back to a
PolySet. When there are very close vertices the grid snap and tessellation
can cause inverted triangles. With the F6 version the CGAL faces are not
all triangles but with F5 they are.
On Tue, 26 May 2020 at 17:26, <arnholm@arnholm.org> wrote:
> 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
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
D
dpa
Wed, May 27, 2020 5:00 PM
I am very grateful that you are taking this issue seriously.
I took circles in the example but actually I was using something similar.
And I thought for some hours researching this was the problem.
I attached the .scad file, showing (see customizer) the structure in kind
of 'step by step'.
The setting show="the bug" simply crashes when rendering (F6). Or if some
changes it "only" shows an error. I couldn't get it rendered..
What can I do? Makes it sense to wait for an Development Snapshot? Or do I
need a different approach (if so, then: what)?
best
Dietrich
Am Di., 26. Mai 2020 um 18:49 Uhr schrieb nop head nop.head@gmail.com:
I think the flipped triangle with F5 is because it converts it back to a
PolySet. When there are very close vertices the grid snap and tessellation
can cause inverted triangles. With the F6 version the CGAL faces are not
all triangles but with F5 they are.
On Tue, 26 May 2020 at 17:26, arnholm@arnholm.org wrote:
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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I am very grateful that you are taking this issue seriously.
I took circles in the example but actually I was using something similar.
And I thought for some hours researching this was the problem.
I attached the .scad file, showing (see customizer) the structure in kind
of 'step by step'.
The setting show="the bug" simply crashes when rendering (F6). Or if some
changes it "only" shows an error. I couldn't get it rendered..
What can I do? Makes it sense to wait for an Development Snapshot? Or do I
need a different approach (if so, then: what)?
best
Dietrich
Am Di., 26. Mai 2020 um 18:49 Uhr schrieb nop head <nop.head@gmail.com>:
> I think the flipped triangle with F5 is because it converts it back to a
> PolySet. When there are very close vertices the grid snap and tessellation
> can cause inverted triangles. With the F6 version the CGAL faces are not
> all triangles but with F5 they are.
>
> On Tue, 26 May 2020 at 17:26, <arnholm@arnholm.org> wrote:
>
>> 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
>> 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
>
NH
nop head
Wed, May 27, 2020 5:20 PM
I think you will be waiting a long time for a fix because OpenSCAD has had
this problem for many years and it has been reported many times.
The workaround is to make sure there are no very close but not exactly
coincident vertices. Also flush the cache before doing F6.
On Wed, 27 May 2020 at 18:01, dpa sc@pankd.de wrote:
I am very grateful that you are taking this issue seriously.
I took circles in the example but actually I was using something similar.
And I thought for some hours researching this was the problem.
I attached the .scad file, showing (see customizer) the structure in kind
of 'step by step'.
The setting show="the bug" simply crashes when rendering (F6). Or if some
changes it "only" shows an error. I couldn't get it rendered..
What can I do? Makes it sense to wait for an Development Snapshot? Or do I
need a different approach (if so, then: what)?
best
Dietrich
Am Di., 26. Mai 2020 um 18:49 Uhr schrieb nop head nop.head@gmail.com:
I think the flipped triangle with F5 is because it converts it back to a
PolySet. When there are very close vertices the grid snap and tessellation
can cause inverted triangles. With the F6 version the CGAL faces are not
all triangles but with F5 they are.
On Tue, 26 May 2020 at 17:26, arnholm@arnholm.org wrote:
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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I think you will be waiting a long time for a fix because OpenSCAD has had
this problem for many years and it has been reported many times.
The workaround is to make sure there are no very close but not exactly
coincident vertices. Also flush the cache before doing F6.
On Wed, 27 May 2020 at 18:01, dpa <sc@pankd.de> wrote:
> I am very grateful that you are taking this issue seriously.
>
> I took circles in the example but actually I was using something similar.
> And I thought for some hours researching this was the problem.
> I attached the .scad file, showing (see customizer) the structure in kind
> of 'step by step'.
> The setting show="the bug" simply crashes when rendering (F6). Or if some
> changes it "only" shows an error. I couldn't get it rendered..
>
> What can I do? Makes it sense to wait for an Development Snapshot? Or do I
> need a different approach (if so, then: what)?
>
> best
> Dietrich
>
> Am Di., 26. Mai 2020 um 18:49 Uhr schrieb nop head <nop.head@gmail.com>:
>
>> I think the flipped triangle with F5 is because it converts it back to a
>> PolySet. When there are very close vertices the grid snap and tessellation
>> can cause inverted triangles. With the F6 version the CGAL faces are not
>> all triangles but with F5 they are.
>>
>> On Tue, 26 May 2020 at 17:26, <arnholm@arnholm.org> wrote:
>>
>>> 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
>>> 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
>>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
JW
Jan Wieck
Wed, May 27, 2020 8:54 PM
I am new to OpenSCAD, I am new to this mailing list ...
but I am not new to Free and Open Source. I have been "actively"
contributing to Open Source since the mid-90s. Different domain (mostly
databases) but no less complex.
With that said, a few comments.
On Wed, May 27, 2020 at 6:22 PM dpa sc@pankd.de wrote:
I think you will be waiting a long time for a fix because OpenSCAD has
had this problem for many years and it has been reported many times.
what? Is this thread all for your fun? Or a repetition of a many years
known problem??
Nobody says "we know about this for years" or "you'll be waiting a long
time" for their own fun. It is the simple truth.
I understand your frustration, but just because a problem is well known
doesn't mean that a solution is ready at hand.
Some development communities tend to adopt quick fixes only to create more
complicated mess down the road. Some communities (like the DB community I
grew old with) are extremely conservative and rather say "unless we find
the right fix with minimal side effects, we aren't ready to fix it, so a
workaround must do for now." And that can take years. I know of problems in
my favorite database that haven't been tackled for two decades.
I didn't understand your "CGAL language" but Ronaldo wrote:
I have never seen that bug before.
and this gave me a hope that it could give a developer a hint where to fix
it. Or if not: how to avoid this..
"Where to fix it" is a very vague description of how this actually works.
Sometimes a bug is just adding a +1 to an expression. Sometimes it is
rearranging a critical section so that it becomes thread safe. Sometimes
the "fix" would require changes to thousands of lines of code in dozens of
source files spread over a code base of several hundreds of thousands of
lines. And especially that last case has a tremendous chance of introducing
new bugs that affect not only the current development code, but backwards
compatibility.
The workaround is to make sure there are no very close but not exactly
ok. You mean this old problem. Can you tell me what in the scad file makes
this "exactly coincident vertices"? With what angle should I detect
what vertices?? Or is it just "something with minkowski" and this a "known,
old bug" and I should stop using minkowski because it's broken,
sometimes..? This problem drives me crazy. I have been stuck for 2 days.
Now I should avoid coincident vertices where there are none..
The problem of coincident vertices has been in this type of software since
I used/hacked rayshade. It is the tradeoff we pay for fast float operations
instead of arbitrary precision math.
Best regards, Jan
--
Jan Wieck
Principal Database Engineer
I am new to OpenSCAD, I am new to this mailing list ...
but I am not new to Free and Open Source. I have been "actively"
contributing to Open Source since the mid-90s. Different domain (mostly
databases) but no less complex.
With that said, a few comments.
On Wed, May 27, 2020 at 6:22 PM dpa <sc@pankd.de> wrote:
> Hi
>
> Am Mi., 27. Mai 2020 um 19:23 Uhr schrieb nop head <nop.head@gmail.com>:
>
>> I think you will be waiting a long time for a fix because OpenSCAD has
>> had this problem for many years and it has been reported many times.
>>
>
> what? Is this thread all for your fun? Or a repetition of a many years
> known problem??
>
Nobody says "we know about this for years" or "you'll be waiting a long
time" for their own fun. It is the simple truth.
I understand your frustration, but just because a problem is well known
doesn't mean that a solution is ready at hand.
Some development communities tend to adopt quick fixes only to create more
complicated mess down the road. Some communities (like the DB community I
grew old with) are extremely conservative and rather say "unless we find
the right fix with minimal side effects, we aren't ready to fix it, so a
workaround must do for now." And that can take years. I know of problems in
my favorite database that haven't been tackled for two decades.
> I didn't understand your "CGAL language" but Ronaldo wrote:
>
>> I have never seen that bug before.
>>
> and this gave me a hope that it could give a developer a hint where to fix
> it. Or if not: how to avoid this..
>
"Where to fix it" is a very vague description of how this actually works.
Sometimes a bug is just adding a +1 to an expression. Sometimes it is
rearranging a critical section so that it becomes thread safe. Sometimes
the "fix" would require changes to thousands of lines of code in dozens of
source files spread over a code base of several hundreds of thousands of
lines. And especially that last case has a tremendous chance of introducing
new bugs that affect not only the current development code, but backwards
compatibility.
>
> The workaround is to make sure there are no very close but not exactly
>> coincident vertices
>
> ok. You mean this old problem. Can you tell me what in the scad file makes
> this "exactly coincident vertices"? With what angle should I detect
> what vertices?? Or is it just "something with minkowski" and this a "known,
> old bug" and I should stop using minkowski because it's broken,
> sometimes..? This problem drives me crazy. I have been stuck for 2 days.
> Now I should avoid coincident vertices where there are none..
>
The problem of coincident vertices has been in this type of software since
I used/hacked rayshade. It is the tradeoff we pay for fast float operations
instead of arbitrary precision math.
Best regards, Jan
--
Jan Wieck
Principal Database Engineer
D
dpa
Wed, May 27, 2020 10:21 PM
I think you will be waiting a long time for a fix because OpenSCAD has had
this problem for many years and it has been reported many times.
what? Is this thread all for your fun? Or a repetition of a many years
known problem??
I didn't understand your "CGAL language" but Ronaldo wrote:
I have never seen that bug before.
and this gave me a hope that it could give a developer a hint where to fix
it. Or if not: how to avoid this..
The workaround is to make sure there are no very close but not exactly
ok. You mean this old problem. Can you tell me what in the scad file makes
this "exactly coincident vertices"? With what angle should I detect
what vertices?? Or is it just "something with minkowski" and this a "known,
old bug" and I should stop using minkowski because it's broken,
sometimes..? This problem drives me crazy. I have been stuck for 2 days.
Now I should avoid coincident vertices where there are none..
Hi
Am Mi., 27. Mai 2020 um 19:23 Uhr schrieb nop head <nop.head@gmail.com>:
> I think you will be waiting a long time for a fix because OpenSCAD has had
> this problem for many years and it has been reported many times.
>
what? Is this thread all for your fun? Or a repetition of a many years
known problem??
I didn't understand your "CGAL language" but Ronaldo wrote:
> I have never seen that bug before.
>
and this gave me a hope that it could give a developer a hint where to fix
it. Or if not: how to avoid this..
The workaround is to make sure there are no very close but not exactly
> coincident vertices
ok. You mean this old problem. Can you tell me what in the scad file makes
this "exactly coincident vertices"? With what angle should I detect
what vertices?? Or is it just "something with minkowski" and this a "known,
old bug" and I should stop using minkowski because it's broken,
sometimes..? This problem drives me crazy. I have been stuck for 2 days.
Now I should avoid coincident vertices where there are none..
A
adrianv
Wed, May 27, 2020 10:50 PM
Nophead, how on earth will rounding of tiny differences cause a reversed
triangle (on a large scale)? That doesn't make any sense to me at all.
(It could happen at microscale if rounding moved one point to the other
side, but we're not at micro scale in this example.)
The problem nophead is referring to has to do with internal rounding that
occurs in OpenSCAD, which rounds everything to units of 1/2^16. If you have
points that are distinct geometrically but closer than this you may possibly
get errors from CGAL about your model being invalid. I've seen this
situation happen exactly once, with points that were 1.3e-6 units apart, so
I'm skeptical that this rounding behavior is the issue here. And like I ask
above, how can rounding points together cause a face to reverse orientation?
It will cause faces to collapse (which isn't always invalid, actually).
--
Sent from: http://forum.openscad.org/
Nophead, how on earth will rounding of tiny differences cause a reversed
triangle (on a large scale)? That doesn't make any sense to me at all.
(It could happen at microscale if rounding moved one point to the other
side, but we're not at micro scale in this example.)
The problem nophead is referring to has to do with internal rounding that
occurs in OpenSCAD, which rounds everything to units of 1/2^16. If you have
points that are distinct geometrically but closer than this you may possibly
get errors from CGAL about your model being invalid. I've seen this
situation happen exactly once, with points that were 1.3e-6 units apart, so
I'm skeptical that this rounding behavior is the issue here. And like I ask
above, how can rounding points together cause a face to reverse orientation?
It will cause faces to collapse (which isn't always invalid, actually).
--
Sent from: http://forum.openscad.org/
NH
nop head
Wed, May 27, 2020 11:31 PM
Snapping vertices can cause flipped triangles when they are almost
degenerate. Possibly the gross flipped triangle is caused by the
tessellation from polygon to triangles going wrong when there are small
flipped triangles, just a guess.
Minkowski normally works fine as do most operations but any can go wrong
when PolySet snaps the results to the grid, or simply converts CGAL
rationals to double.
With simpler operations it is usually easy to fudge it to make sure
vertices don't nearly line up. In this case it doesn't seem obvious how to
do that. It works fine for me with cache flush before F6 but not when
add_rotate is set. Changing the number of vertices seems to fix it. For
example giving the sphere 32 vertices seems fine. Having 6 on a sphere is
unusual and coinciding with 6 on the circle seems to cause the problem.
On Wed, 27 May 2020 at 23:54, Jan Wieck jan@wi3ck.info wrote:
I am new to OpenSCAD, I am new to this mailing list ...
but I am not new to Free and Open Source. I have been "actively"
contributing to Open Source since the mid-90s. Different domain (mostly
databases) but no less complex.
With that said, a few comments.
On Wed, May 27, 2020 at 6:22 PM dpa sc@pankd.de wrote:
I think you will be waiting a long time for a fix because OpenSCAD has
had this problem for many years and it has been reported many times.
what? Is this thread all for your fun? Or a repetition of a many years
known problem??
Nobody says "we know about this for years" or "you'll be waiting a long
time" for their own fun. It is the simple truth.
I understand your frustration, but just because a problem is well known
doesn't mean that a solution is ready at hand.
Some development communities tend to adopt quick fixes only to create more
complicated mess down the road. Some communities (like the DB community I
grew old with) are extremely conservative and rather say "unless we find
the right fix with minimal side effects, we aren't ready to fix it, so a
workaround must do for now." And that can take years. I know of problems in
my favorite database that haven't been tackled for two decades.
I didn't understand your "CGAL language" but Ronaldo wrote:
I have never seen that bug before.
and this gave me a hope that it could give a developer a hint where to
fix it. Or if not: how to avoid this..
"Where to fix it" is a very vague description of how this actually works.
Sometimes a bug is just adding a +1 to an expression. Sometimes it is
rearranging a critical section so that it becomes thread safe. Sometimes
the "fix" would require changes to thousands of lines of code in dozens of
source files spread over a code base of several hundreds of thousands of
lines. And especially that last case has a tremendous chance of introducing
new bugs that affect not only the current development code, but backwards
compatibility.
The workaround is to make sure there are no very close but not exactly
ok. You mean this old problem. Can you tell me what in the scad file
makes this "exactly coincident vertices"? With what angle should I detect
what vertices?? Or is it just "something with minkowski" and this a "known,
old bug" and I should stop using minkowski because it's broken,
sometimes..? This problem drives me crazy. I have been stuck for 2 days.
Now I should avoid coincident vertices where there are none..
Snapping vertices can cause flipped triangles when they are almost
degenerate. Possibly the gross flipped triangle is caused by the
tessellation from polygon to triangles going wrong when there are small
flipped triangles, just a guess.
Minkowski normally works fine as do most operations but any can go wrong
when PolySet snaps the results to the grid, or simply converts CGAL
rationals to double.
With simpler operations it is usually easy to fudge it to make sure
vertices don't nearly line up. In this case it doesn't seem obvious how to
do that. It works fine for me with cache flush before F6 but not when
add_rotate is set. Changing the number of vertices seems to fix it. For
example giving the sphere 32 vertices seems fine. Having 6 on a sphere is
unusual and coinciding with 6 on the circle seems to cause the problem.
On Wed, 27 May 2020 at 23:54, Jan Wieck <jan@wi3ck.info> wrote:
> I am new to OpenSCAD, I am new to this mailing list ...
>
> but I am not new to Free and Open Source. I have been "actively"
> contributing to Open Source since the mid-90s. Different domain (mostly
> databases) but no less complex.
>
> With that said, a few comments.
>
> On Wed, May 27, 2020 at 6:22 PM dpa <sc@pankd.de> wrote:
>
>> Hi
>>
>> Am Mi., 27. Mai 2020 um 19:23 Uhr schrieb nop head <nop.head@gmail.com>:
>>
>>> I think you will be waiting a long time for a fix because OpenSCAD has
>>> had this problem for many years and it has been reported many times.
>>>
>>
>> what? Is this thread all for your fun? Or a repetition of a many years
>> known problem??
>>
>
> Nobody says "we know about this for years" or "you'll be waiting a long
> time" for their own fun. It is the simple truth.
>
> I understand your frustration, but just because a problem is well known
> doesn't mean that a solution is ready at hand.
>
> Some development communities tend to adopt quick fixes only to create more
> complicated mess down the road. Some communities (like the DB community I
> grew old with) are extremely conservative and rather say "unless we find
> the right fix with minimal side effects, we aren't ready to fix it, so a
> workaround must do for now." And that can take years. I know of problems in
> my favorite database that haven't been tackled for two decades.
>
>
>
>> I didn't understand your "CGAL language" but Ronaldo wrote:
>>
>>> I have never seen that bug before.
>>>
>> and this gave me a hope that it could give a developer a hint where to
>> fix it. Or if not: how to avoid this..
>>
>
> "Where to fix it" is a very vague description of how this actually works.
> Sometimes a bug is just adding a +1 to an expression. Sometimes it is
> rearranging a critical section so that it becomes thread safe. Sometimes
> the "fix" would require changes to thousands of lines of code in dozens of
> source files spread over a code base of several hundreds of thousands of
> lines. And especially that last case has a tremendous chance of introducing
> new bugs that affect not only the current development code, but backwards
> compatibility.
>
>
>>
>> The workaround is to make sure there are no very close but not exactly
>>> coincident vertices
>>
>> ok. You mean this old problem. Can you tell me what in the scad file
>> makes this "exactly coincident vertices"? With what angle should I detect
>> what vertices?? Or is it just "something with minkowski" and this a "known,
>> old bug" and I should stop using minkowski because it's broken,
>> sometimes..? This problem drives me crazy. I have been stuck for 2 days.
>> Now I should avoid coincident vertices where there are none..
>>
>
> The problem of coincident vertices has been in this type of software since
> I used/hacked rayshade. It is the tradeoff we pay for fast float operations
> instead of arbitrary precision math.
>
>
> Best regards, Jan
>
> --
> Jan Wieck
> Principal Database Engineer
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
RP
Ronaldo Persiano
Thu, May 28, 2020 12:32 AM
Nophead, how on earth will rounding of tiny differences cause a reversed
triangle (on a large scale)? That doesn't make any sense to me at all.
(It could happen at microscale if rounding moved one point to the other
side, but we're not at micro scale in this example.)
In this last model, I could not find any flipped triangle. But I have no
trouble in rendering the model provided that the cache is flushed before
the first F6. After that, the next F6 was fast and fine even to do the cuts
showing inside the model.
This problem drives me crazy. I have been stuck for 2 days. Now I should
avoid coincident vertices where there are none..
Take it easy! You have a work around. Just flush the cache between a F5 and
a F6. You don't need to flush it between two renders.
>
> Nophead, how on earth will rounding of tiny differences cause a reversed
> triangle (on a large scale)? That doesn't make any sense to me at all.
> (It could happen at microscale if rounding moved one point to the other
> side, but we're not at micro scale in this example.)
>
In this last model, I could not find any flipped triangle. But I have no
trouble in rendering the model provided that the cache is flushed before
the first F6. After that, the next F6 was fast and fine even to do the cuts
showing inside the model.
This problem drives me crazy. I have been stuck for 2 days. Now I should
> avoid coincident vertices where there are none..
Take it easy! You have a work around. Just flush the cache between a F5 and
a F6. You don't need to flush it between two renders.
D
dpa
Thu, May 28, 2020 1:17 AM
This problem drives me crazy. I have been stuck for 2 days. Now I should
avoid coincident vertices where there are none..
Take it easy! You have a work around. Just flush the cache between a F5
and a F6. You don't need to flush it between two renders.
what!! that easy! THANK YOU ! Perfect
> This problem drives me crazy. I have been stuck for 2 days. Now I should
>> avoid coincident vertices where there are none..
>
>
> Take it easy! You have a work around. Just flush the cache between a F5
> and a F6. You don't need to flush it between two renders.
>
what!! that easy! THANK YOU ! Perfect
O
OzAtMichael
Thu, May 28, 2020 4:10 AM
Possibly the gross flipped triangle is caused by the tessellation from polygon to triangles going
wrong when there are small flipped triangles, just a guess.
Getting warmer.
With add_rotate=7, flushed-F6, export; STL is attached.
There is z-fighting in this region.
This is slightly moved.
I then selected the two triangles (black is selected-backface)
I then remove the two faces.
Showing correctly oriented faces. Plus other issues in the region.
So it is not just small-numbers.
Meshlab
Note the two arrows there is no vertex there (488 is on the other side), there are 4-6 overlapping
triangles, one or two inverted.
There are no small triangles that I can see.
--
This email has been checked for viruses by AVG.
https://www.avg.com
> Possibly the gross flipped triangle is caused by the tessellation from polygon to triangles going
wrong when there are small flipped triangles, just a guess.
Getting warmer.
With add_rotate=7, flushed-F6, export; STL is attached.
There is z-fighting in this region.
This is slightly moved.
I then selected the two triangles (black is selected-backface)
I then remove the two faces.
Showing correctly oriented faces. Plus other issues in the region.
So it is not just small-numbers.
Meshlab
Note the two arrows there is no vertex there (488 is on the other side), there are 4-6 overlapping
triangles, one or two inverted.
There are no small triangles that I can see.
--
This email has been checked for viruses by AVG.
https://www.avg.com
