Open NateTG opened 7 years ago
edge 2 of facet 2536 doesn't match edge 1 of facet 2537
facet (2536)/ first facet
vertex 0/2536 4.85633999E-001 1.31861997E+000 3.95191193E+000
vertex 1/2536 7.91876018E-001 1.18335998E+000 3.78948402E+000
vertex 2/2536 4.85810995E-001 1.31896603E+000 3.95191193E+000
facet (2537)/ second facet
vertex 0/2537 7.92492986E-001 1.18448997E+000 3.78939390E+000
vertex 1/2537 4.85810995E-001 1.31896603E+000 3.95191193E+000
vertex 2/2537 4.85633999E-001 1.31861997E+000 3.95191193E+000
edge 1 of facet 2537 doesn't match edge 2 of facet 2536
facet (2537)/ first facet
vertex 0/2537 7.92492986E-001 1.18448997E+000 3.78939390E+000
vertex 1/2537 4.85810995E-001 1.31896603E+000 3.95191193E+000
vertex 2/2537 4.85633999E-001 1.31861997E+000 3.95191193E+000
facet (2536)/ second facet
vertex 0/2536 4.85633999E-001 1.31861997E+000 3.95191193E+000
vertex 1/2536 7.91876018E-001 1.18335998E+000 3.78948402E+000
vertex 2/2536 4.85810995E-001 1.31896603E+000 3.95191193E+000
Noticed these messages from Slic3r. Model does read as manifold and I can get it to crash on copies of the model as passed through netfabb's online system.
in stl_remove_facet: neighbor = 18049 numfacets = 33734 this is wrong
removing a facet in stl_remove_degenerate
Back to the first facet filling holes: probably a mobius part.
Try using a smaller tolerance or don't do a nearby check
edge 1 of facet 59663 doesn't match edge 1 of facet 58515
facet (59663)/ first facet
vertex 0/59663 -1.15799997E-003 -1.40771997E+000 6.80000019E+000
vertex 1/59663 -1.27799995E-003 -1.40775502E+000 6.80000019E+000
vertex 2/59663 -1.20299996E-003 -1.40732801E+000 6.80000019E+000
facet (58515)/ second facet
vertex 0/58515 -5.70999868E-002 -1.41130006E+000 6.76600075E+000
vertex 1/58515 -1.27799995E-003 -1.40775502E+000 6.80000019E+000
vertex 2/58515 -1.20299996E-003 -1.40732801E+000 6.80000019E+000
edge 2 of facet 59973 doesn't match edge 6 of facet 59969
facet (59973)/ first facet
vertex 0/59973 -3.64940017E-002 -1.40397596E+000 6.80000019E+000
vertex 1/59973 -3.63250002E-002 -1.40393496E+000 6.80000019E+000
vertex 2/59973 -3.62880006E-002 -1.40392399E+000 6.80000019E+000
facet (59969)/ second facet
vertex 0/59969 -3.64940017E-002 -1.40397596E+000 6.80000019E+000
vertex 1/59969 -3.62880006E-002 -1.40392399E+000 6.80000019E+000
vertex 2/59969 -3.47770005E-002 -1.40423906E+000 6.80000019E+000
removing a facet in stl_remove_degenerate
edge 2 of facet 5862 doesn't match edge 4 of facet 6152
facet (5862)/ first facet
vertex 0/5862 1.93727002E-001 -1.41031504E+000 6.59999990E+000
vertex 1/5862 1.70900032E-001 -1.41230011E+000 6.61960030E+000
vertex 2/5862 1.93727002E-001 -1.41017795E+000 6.59999990E+000
facet (6152)/ second facet
vertex 0/6152 1.93771005E-001 -1.41059399E+000 6.59999990E+000
vertex 1/6152 1.93727002E-001 -1.41031504E+000 6.59999990E+000
vertex 2/6152 1.93727002E-001 -1.41017795E+000 6.59999990E+000
More log items; I believe these are all from the helixical shape.
The other design crashes immediately on opening the cut dialog, due to the rendering of the preview; the default cut position on that model happens to be in a "bad" spot.
The problem is somewhere in the actual cut code, I'm suspecting the repair calls myself right now.
The triangulation library is certainly not numerically stable and it needs to be replaced with something else. Until that all bets are off.
On Sun, May 14, 2017 at 9:24 PM, Joseph Lenox notifications@github.com wrote:
edge 2 of facet 2536 doesn't match edge 1 of facet 2537 facet (2536)/ first facet vertex 0/2536 4.85633999E-001 1.31861997E+000 3.95191193E+000 vertex 1/2536 7.91876018E-001 1.18335998E+000 3.78948402E+000 vertex 2/2536 4.85810995E-001 1.31896603E+000 3.95191193E+000 facet (2537)/ second facet vertex 0/2537 7.92492986E-001 1.18448997E+000 3.78939390E+000 vertex 1/2537 4.85810995E-001 1.31896603E+000 3.95191193E+000 vertex 2/2537 4.85633999E-001 1.31861997E+000 3.95191193E+000 edge 1 of facet 2537 doesn't match edge 2 of facet 2536 facet (2537)/ first facet vertex 0/2537 7.92492986E-001 1.18448997E+000 3.78939390E+000 vertex 1/2537 4.85810995E-001 1.31896603E+000 3.95191193E+000 vertex 2/2537 4.85633999E-001 1.31861997E+000 3.95191193E+000 facet (2536)/ second facet vertex 0/2536 4.85633999E-001 1.31861997E+000 3.95191193E+000 vertex 1/2536 7.91876018E-001 1.18335998E+000 3.78948402E+000 vertex 2/2536 4.85810995E-001 1.31896603E+000 3.95191193E+000
Noticed these messages from Slic3r. Model does read as manifold and I can get it to crash on copies of the model as passed through netfabb's online system.
in stl_remove_facet: neighbor = 18049 numfacets = 33734 this is wrong removing a facet in stl_remove_degenerate Back to the first facet filling holes: probably a mobius part. Try using a smaller tolerance or don't do a nearby check edge 1 of facet 59663 doesn't match edge 1 of facet 58515 facet (59663)/ first facet vertex 0/59663 -1.15799997E-003 -1.40771997E+000 6.80000019E+000 vertex 1/59663 -1.27799995E-003 -1.40775502E+000 6.80000019E+000 vertex 2/59663 -1.20299996E-003 -1.40732801E+000 6.80000019E+000 facet (58515)/ second facet vertex 0/58515 -5.70999868E-002 -1.41130006E+000 6.76600075E+000 vertex 1/58515 -1.27799995E-003 -1.40775502E+000 6.80000019E+000 vertex 2/58515 -1.20299996E-003 -1.40732801E+000 6.80000019E+000 edge 2 of facet 59973 doesn't match edge 6 of facet 59969 facet (59973)/ first facet vertex 0/59973 -3.64940017E-002 -1.40397596E+000 6.80000019E+000 vertex 1/59973 -3.63250002E-002 -1.40393496E+000 6.80000019E+000 vertex 2/59973 -3.62880006E-002 -1.40392399E+000 6.80000019E+000 facet (59969)/ second facet vertex 0/59969 -3.64940017E-002 -1.40397596E+000 6.80000019E+000 vertex 1/59969 -3.62880006E-002 -1.40392399E+000 6.80000019E+000 vertex 2/59969 -3.47770005E-002 -1.40423906E+000 6.80000019E+000 removing a facet in stl_remove_degenerate edge 2 of facet 5862 doesn't match edge 4 of facet 6152 facet (5862)/ first facet vertex 0/5862 1.93727002E-001 -1.41031504E+000 6.59999990E+000 vertex 1/5862 1.70900032E-001 -1.41230011E+000 6.61960030E+000 vertex 2/5862 1.93727002E-001 -1.41017795E+000 6.59999990E+000 facet (6152)/ second facet vertex 0/6152 1.93771005E-001 -1.41059399E+000 6.59999990E+000 vertex 1/6152 1.93727002E-001 -1.41031504E+000 6.59999990E+000 vertex 2/6152 1.93727002E-001 -1.41017795E+000 6.59999990E+000
More log items; I believe these are all from the helixical shape.
The other design crashes immediately on opening the cut dialog, due to the rendering of the preview; the default cut position on that model happens to be in a "bad" spot.
The problem is somewhere in the actual cut code, I'm suspecting the repair calls myself right now.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/3953#issuecomment-301333944, or mute the thread https://github.com/notifications/unsubscribe-auth/AFj5I42HtE45PntEhVtupItru2NIKoG0ks5r51UDgaJpZM4NaLv0 .
The tlb model did not segfault when cut in X or Y.
The segfault is occurring in poly2tri. Currently unsure as to why.
The segfault is occurring in poly2tri. Currently unsure as to why.
Because poly2tri is not numerically stable, therefore the decision it makes topologically do not correspond with the geometry. And if you do that, all bets are off and the application will crash. Depending on the data, it may happen rarely or more often.
One could either ditch poly2tri completely or try to fix it.
I did not have time for that, but I would just replace poly2tri with a time proven triangle.
https://www.cs.cmu.edu/~quake/triangle.html
On Sun, May 14, 2017 at 10:42 PM, Joseph Lenox notifications@github.com wrote:
The segfault is occurring in poly2tri. Currently unsure as to why.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/3953#issuecomment-301338549, or mute the thread https://github.com/notifications/unsubscribe-auth/AFj5I2f-Db32OwYVDDougSvtkSleYkpZks5r52clgaJpZM4NaLv0 .
Someone else found that, at least for their usage, sanitizing the inputs with clipper before getting to poly2tri worked for them, and broke out the work into a library. I'd need to confirm that it would work in these situations.
@bubnikv triangle has problems with license compatibility, it's only permitted under its default license for noncommercial use.
Numerical stability totally makes sense. Those are models with tiny triangles, and it crashed less after I simplified the models.
Someone else found that, at least for their usage, sanitizing the inputs with clipper before getting to poly2tri worked for them, and broke out the work into a library. I'd need to confirm that it would work in these situations.
http://stackoverflow.com/questions/16042940/robust- fast-complex-polygon-with-holes-triangulation-c-c-library-with-perm http://stackoverflow.com/questions/16042940/robust-fast-complex-polygon-with-holes-triangulation-c-c-library-with-permi i http://stackoverflow.com/questions/16042940/robust-fast-complex-polygon-with-holes-triangulation-c-c-library-with-permi
I saw that try. It lowers the amount of crashes to some extent, but it does not mitigate them.
@bubnikv https://github.com/bubnikv triangle has problems with license compatibility, it's only permitted under its default license for noncommercial use.
Long live FSF.
On Sun, May 14, 2017 at 11:09 PM, NateTG notifications@github.com wrote:
Numerical stability totally makes sense. Those are models with tiny triangles.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/3953#issuecomment-301340169, or mute the thread https://github.com/notifications/unsubscribe-auth/AFj5I4fLIAfLXOwkgRSHjpv2fM7U6NR1ks5r522cgaJpZM4NaLv0 .
There's polypartition as well.
Yeah, FOSS is much preferred. Could probably do a darkroom implementation of Triangle from their published papers if one had time.
I tried polypartition in the past (we even have it in the codebase) but it was worse.
on my win10, cut dialog didn't even show up, it crash as soon as I click on the "cut" button in the toolbar
Yeah, I saw this behavior on Windows 10. It is because preview is on by default and that is a nasty model for the library we use.
Version
1.2.9-1006-gb52de343
(1.3.0-dev in the UI)
Operating system type + version
Debian GNU/Linux 9.0
Behavior
Loading an stl file into the slicer and pushing the cut button causes seg fault. It might have to do with the size of the mesh. The helix-simplified will segfault mid-cut - less often when "show preview" is disabled. (Zipped samples attached.)
helix-simplified.zip tlb.zip