5.1.1 Failing During Slicing Process of File

3hrisc0 commented 2 years ago

Application Version

5.1.1

Platform

Windows 10

Printer

Creality Ender-3 V2

Reproduction steps

Import STL and Slice File

Untitled CE3_penguin.zip cura.log

Actual results

1.Progress Bar Shows but no progress is made, Shows Up Empty till it fails

Expected results

Gives me a File that I can then Send to printer to start printing

Checklist of files to include

[x] Log file
[X] Project file

Additional information & file uploads

Screen Shot of Task Manager during it Failing the Slicing process

Piezoid commented 2 years ago

For developers:

This bug is caused by the merging of mesh vertices closer than 30µm (on Ultimaker/CuraEngine@6734fe21 ). This breaks polylines and triggers a pathological case in SlicerLayer::connectOpenPolylinesImpl which ends up allocating all available memory. After vertices merging, some layers have a lot of open polylines many of which are 2 vertices long:

[2022-09-16 21:20:52.529] [warning] Layer at z=3520 has 23672 open polylines.
[2022-09-16 21:21:28.412] [warning] Layer at z=3640 has 23664 open polylines.
[2022-09-16 21:22:04.377] [warning] Layer at z=3760 has 23676 open polylines.
[2022-09-16 21:22:39.937] [warning] Layer at z=3880 has 23651 open polylines.
[2022-09-16 21:22:58.107] [warning] Layer at z=4000 has 23657 open polylines.
[2022-09-16 21:23:12.311] [warning] Layer at z=4120 has 23653 open polylines.

They are merged in a suboptimal order: the previously merged polygon in merged into a 2-line (before joinPolylines,polyline_0.size() = 2 and polyline_1.size() >> 2)
polyline_1 is cleared but not deallocated, this leaves each merged polyline with a growing allocated capacity,
=> about 2 23.6k 23.6k / 2 = 560 million IntPoints are allocated during a connectOpenPolylinesImpl run.

Avoid merging vertices:

```diff diff --git a/src/mesh.cpp b/src/mesh.cpp index 82a651a9c..7bb2b3e1a 100644 --- a/src/mesh.cpp +++ b/src/mesh.cpp @@ -111,7 +111,7 @@ int Mesh::findIndexOfVertex(const Point3& v) for (unsigned int idx = 0; idx < vertex_hash_map[hash].size(); idx++) { - if ((vertices[vertex_hash_map[hash][idx]].p - v).testLength(vertex_meld_distance)) + if (vertices[vertex_hash_map[hash][idx]].p == v) { return vertex_hash_map[hash][idx]; } ```

Fully deallocate polyline_1:

```diff diff --git a/src/slicer.cpp b/src/slicer.cpp index cec4bbc96..729fae4c9 100644 --- a/src/slicer.cpp +++ b/src/slicer.cpp @@ -390,6 +390,7 @@ void SlicerLayer::joinPolylines(PolygonRef& polyline_0, PolygonRef& polyline_1, std::swap(polyline_0[idx], polyline_0[size_0 - 1 - idx]); } } + polyline_0.reserve(polyline_0.size() + polyline_1.size()); if (reverse[1]) { // reverse polyline_1 by adding in reverse order @@ -402,7 +403,7 @@ void SlicerLayer::joinPolylines(PolygonRef& polyline_0, PolygonRef& polyline_1, for (Point& p : polyline_1) polyline_0.add(p); } - polyline_1.clear(); + polyline_1 = Polygon(); } SlicerLayer::TerminusTrackingMap::TerminusTrackingMap(Terminus::Index end_idx) : m_terminus_old_to_cur_map(end_idx) ```

3hrisc0 commented 2 years ago

I got it to slice after I found another article. Ended up moving it 10 in the X and Y Direction and 90 Degrees Clockwise seemed to make it Happy. #13066

GregValiant commented 2 years ago

@Piezoid, I've looked at a lot of these models and I have thought that the common property that they have all had is the extreme resolution of the meshes...the sheer density of triangles that comprise the surfaces. I exported this Penguin model from Cura as an STL and the file is 37mb with 385428 vertices and 770728 triangles. Trying to slice it brought my laptop to it's knees as have many of the other high resolution models that are unable to slice. After simplifying the model with MS 3D Builder it is 16mb with 136455 vertices and 270788 triangles. That is still a very high resolution considering the physical size of the model, but the model slices at that resolution (it took a while but did finish).

I think part of this has to be the density of the point clouds of scans and the subsequent density of the triangles created from those point clouds in whatever software the artists are using. There is no way to hold a .2 x .4 smear of hot plastic to those resolutions. There is likely no way to do anything with models of those resolutions except to stare at the computer generated model. Turning it into a physical model without ignoring a lot of the resolution would appear to be impossible given the limitations of FDM.

Yes @3hrisc0 I have passed along that moving and/or rotating some models allows Cura to slice them but that is just a workaround and not a fix. It would be better if models with vertex/triangle densities above some number would be noted and kicked back to the user to simplify. At least there would be some way to tell if a failed slice was because of the resolution or because of model errors. If the models keep getting produced at higher and higher resolutions (and they probably will) then although implementing something like Piezoids suggestions would work for a while, they would probably end up being a stopgap measure.

The resolution of this simplified model is about 1/3 of the original. I don't think anyone would notice.

Piezoid commented 2 years ago

@Piezoid, I've looked at a lot of these models and I have thought that the common property that they have all had is the extreme resolution of the meshes...the sheer density of triangles that comprise the surfaces. I exported this Penguin model from Cura as an STL and the file is 37mb with 385428 vertices and 770728 triangles. Trying to slice it brought my laptop to it's knees as have many of the other high resolution models that are unable to slice. After simplifying the model with MS 3D Builder it is 16mb with 136455 vertices and 270788 triangles. That is still a very high resolution considering the physical size of the model, but the model slices at that resolution (it took a while but did finish).

I ran the latest master in a debugger after after noticing abnormal memory consumption. This bug is unlike the usual "can't slice" bugs where a malformed trapezoidal graph crashes during traversal. With this model, at least on CuraEngine master 5.2, the memory blows up during the first step of the slicing process when sliced polygons are repaired. Of course reducing the resolution solves the issue, as it is less likely that vertices get merged. Furthermore the merging is not correctly implemented and is dependent on the alignment of vertices align with the 30µm grid, so moving/rotating it may improve the situation.

Given the similarities, it may be possible that this bugs interacts with the trapezoidal traversal bug, if the stitching of the polylines results in invalid polygons. Anyway, it is probably best to disable the vertex merging, as discussed here.

I think part of this has to be the density of the point clouds of scans and the subsequent density of the triangles created from those point clouds in whatever software the artists are using. There is no way to hold a .2 x .4 smear of hot plastic to those resolutions. There is likely no way to do anything with models of those resolutions except to stare at the computer generated model. Turning it into a physical model without ignoring a lot of the resolution would appear to be impossible given the limitations of FDM.

While I agree that his mesh is way too fine, a downside of lower resolution is increased vibrations and lowered print speed.

Ultimaker / Cura