Open 3hrisc0 opened 1 year 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.
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,connectOpenPolylinesImpl
run.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
@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, 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.
Application Version
5.1.1
Platform
Windows 10
Printer
Creality Ender-3 V2
Reproduction steps
Actual results
1.Progress Bar Shows but no progress is made, Shows Up Empty till it fails
Expected results
Checklist of files to include
Additional information & file uploads
Screen Shot of Task Manager during it Failing the Slicing process