Open simonkuehling opened 11 years ago
Woah, that's a pretty good stress-test for single walls code. :)
That grid is all made of thin walls that Slic3r needs to collapse into single walls because they're thinner than 2x extrusion width. Current medial axis code is very very slow (and not the best feature in Slic3r...), but a lot of work is undergoing since November to get that fixed with a new implementation. I'll make sure this file gets tested.
Nice, that's great news :-) It's awesome to see the whole project evole at such an incredible pace.
Please don't stop reporting! :)
@mesheldrake, I just tried this with medial-thinwall and default settings. It looks like it skipped almost all the grid. I think this is a pretty good test for both its computatinal weight and its complex single-walled pattern.
If it skipped the grid in the output it still almost certainly calculated the medial axis in an earlier step in sub-infinite time. I'll put that model to the test tomorrow.
By running with --debug I didn't notice any "thin walls detected" message in the output. I'm not sure whether that debugging message is present in medial-thinwall, though (it should).
Captured the hex pattern with medial-thinwall. This is the worst case for a bug that didn't really show up on "typical" objects. Now I'm wondering if some of the stubborn transient missing fragment problems I'm seeing with this branch are small manifestations of this bug.
I think the way the thin walls came out here is one independent short segment for every hexagon side - that is no linked-together paths through the grid. (Fragments should linkup when they can, but they didn't.)
It's pretty slow when all the thin wall segments are properly generated. I just waited for a few of the bottom layers. but it was progressing, not hanging.
In the gcode preview, you can see the grid lines shift side to side on each layer, where they're alternately choosing to go to the left or right side of the >1 width thin passages they inhabit, trying to fill out the walls to the correct width on average over multiple layers.
Sliced this with one thread in 5 minutes on an older machine with the latest medial-thinwall branch posted today. I don't know if the thin mesh will come out okay in a print (maybe not), but the thinwall toolpaths all seem to be there, and at least a little bit chained together.
Gray: extrusion representation Dashed: original part boundary Red: medial axis
Good!
@mesheldrake, let's start thinking about some unit tests for the thinwall code.
I just tested this with the boost-medialaxis
branch using the supplied config file and it took 44 seconds to generate the following result:
The grid is complete and consistent among all of its layers. Ordering is fine too. However, segments are extending too much and this needs to be investigated. I guess this will not be very visible in the printed object since the extra length is absorbed in the extrusion width (it would even provide stronger bonding):
I don't understand why Repetier's rendering misses some grid segments (the 2D rendering above was made from the same file and includes all of them - and they all have the same, positive, flow).
@simonkuehling do you still have a copy of this test case? Your original links are down.
@lordofhyphens - oh, those are offline indeed... no problem, here they are again:
I tried to run this again with current master, and the medial axis code isn't run because we changed the thickness thresholds which trigger it:
Raising the External Perimeter Extrusion Width to 0.4mm I can get medial axis code to run, and the result is almost perfect, except for some connection segments which are missing:
Those missing segments are related to the pruning algorithm that tries to recognize sticks and artifacts. In most cases it does the right thing. It's hard to make it smart for every case. I think this issue can be considered solved for now, as user can just disable thin walls detection and the double-pass output will be generated, which is always correct. I'll leave this issue open for further future work on the medial axis code, but I'll remove it from the 1.3.0 milestone. Printing this geometry with single extrusions is a hard task anyway, involving lots of retractions and I expect the result to be weak and lacking...
Hi,
i have troube slicing one specific STL file that i'll attach at the bottom. Slic3r does not throw an error or such, it just keeps running at full throttle "Processing triangulated mesh" - for hours and hours (i was curious and let it do for 24 hours). i tried netfabb mesh repair without success. Usually my computer is able to successfully slice objects of comparable complexity.
My system is Ubuntu 12.04 with latest git version. In case my slightly out-of-date hardware just isn't up to this - could someone with more power please confirm this issue? That would be awesome!
air-filter-container.stl config.ini