SoftFever
Improve fuzzy skin with modifier
Description
Now using fuzzy skin on modifiers no longer generate extra perimeters between regions. ~~Currently I only completed the code for classic wall mode. Arachne still work-in-progress.~~
Note: the algorithm can be slow with complicated models when using multiple modifiers (clipping and reconstructing polygons with lots of points can be computational intense), though it shouldn't slow down when using only one modifier compare to the original algorithm.
Fix #2647 Fix #5560
Screenshots/Recordings/Graphs
Currently there will be a seam when multiple modifiers with different fuzzy settings intersect:
Not sure how to fix this though.
~~Somehow the modifier affects solid layers next to top/bottom layers. Weird...~~
~~Update: this issue is not caused by this PR though. This can be reproduced by adding a modifier with any option that does not affect the perimeters (such as the ironing option) on version 2.2.0beta as well.~~
Update 2: This issue should now be fixed with PR #6794
It would be nice if the same was done for speed modifiers: if I set a modifier to change perimeter speed for a part of an object, the modifier adds a surface (with all that comes with it, so changes of travel, lines are broken, ...) on the interface.
See this: https://3dprinting.stackexchange.com/questions/23331/how-to-change-print-speed-along-a-perimeter
Maybe check what caused the issue you solved just for fuzzy skin and solve it at the root?
It would be nice if the same was done for speed modifiers: if I set a modifier to change perimeter speed for a part of an object, the modifier adds a surface (with all that comes with it, so changes of travel, lines are broken, ...) on the interface.
See this: https://3dprinting.stackexchange.com/questions/23331/how-to-change-print-speed-along-a-perimeter
Maybe check what caused the issue you solved just for fuzzy skin and solve it at the root?
That won't be easy, but I'll look at this when possible.
While I'm not manually assigning modifiers, color painting creates them and I have no control over it; and if someone were to use beam interlocking, things get crazy as seen here: https://github.com/SoftFever/OrcaSlicer/issues/5185#issuecomment-2358947450
Care to try that test case against your build?
Currently there will be a seam when multiple modifiers with different fuzzy settings intersect:
Not sure how to fix this though.
This seam actually shows up even with a single modifier. @Noisyfox I'd like to possibly fix this. Do you understand why this seam occurs?
It seems to occur always on the "right" side of the plate, regardless of model orientation of modifier position.
Looking at the right side of the model, it's hard to see but it's there. I actually first spotted it on an actual print then made this super simple repro.
Affects Arachne only (I hope that's a huge clue to help solve it). Here's the exact same model with Classic wall generator
I have narrowed down this seam to be caused by p.clipped being false for no good reason on a single point, causing the creation of a new segment and the seam is basically at the point in between the two segments.
Confirmed my theory with some modifications to the debug svg
So now we either need to rejoin these segments or prevent that "faulty" .clipped=false value!
Currently there will be a seam when multiple modifiers with different fuzzy settings intersect:
Not sure how to fix this though.
This seam actually shows up even with a single modifier. @Noisyfox I'd like to possibly fix this. Do you understand why this seam occurs? It seems to occur always on the "right" side of the plate, regardless of model orientation of modifier position.
Looking at the right side of the model, it's hard to see but it's there. I actually first spotted it on an actual print then made this super simple repro.
Affects Arachne only (I hope that's a huge clue to help solve it). Here's the exact same model with Classic wall generator
Could you open a new issue and also attach this test project? Thanks!
Ok so the .clipped=false value was a red herring.
The actual cause of this is the start/end of the segments. It seems that the values returned from split_line do start and end at some arbitrary location. It is to the right for Arachne and to the front for classic. And that's where the seam shows up.
Below screenshot shows the front from Classic and the seam is there.
Not sure about how to fix yet.