Allow the user to force Arachne to use a fixed line width on external perimeters

[VanessaE]

Is your feature request related to a problem? Please describe.

In a manner of speaking... As we all know, Arachne's primary purpose is to produce variable-width perimeters that adapt to the shape of the model, rather than trying to cram-in multiple, fixed-width perimeters and relying on gap fill to handle the rest.

However, this often produces sub-par results on small parts where there is too-little room for there to be two or more perimeters for Arachne to spread its variations across. If there are a lot of "incursions" into the space where the second-from-external perimeter would normally be placed, as would happen if the part has a lot of vertical holes near its exterior, Arachne will create variable widths for both that internal perimeter and the external one, and for the nearest parts of the the perimeters that form said hole.

Most people use a set of fixed speeds in their prints, going slow on external lines and fast on internal lines. For such prints, Arachne's variations in line width will mean variations in flow rate, since the speed of any one feature is constant. This in turn means variations in the temperature of the deposited filament, since those differences would be too rapid for the thermistor to notice. For most filaments, this wouldn't be an issue, but you're using one of those filaments that changes color according to print temperature, it could result in minor, unplanned color variations on the part, which may or may not be desirable.

On the other hand, if you're using volumetric/autospeed mode, those variations mean the print speed must vary up and down accordingly in order to keep the flow rate constant, which may result in minor variations how glossy or matte the surface is. These variations in print speed may also induce unexpected changes in fan speed, amplifying that glossy/matte variation, though this would require a fairly large part and rather extreme differences in part geometry.

In addition, these variations in line width are not entirely balanced-out by the required changes in the tool path, meaning thinner lines tend to be ever so slightly inset from the ideal surface, which is most visible on particularly-glossy filaments like PETG, as the light will glint-off the surface weirdly in those spots. There are other issues here on Github that discuss this bit, and I've seen it in my own prints, too.

Variations in line width are usually fine for infill and internal perimeters, but they are definitely bad for external perimeters.

Describe the solution you'd like

I would like a setting that'll force Arachne to use a fixed line width on external perimeters.

Describe how it would work

Simple: in the "Width and Flow" page, if external perimeter width is set to something other than 0, just use that value like you would in the "classic" perimeter generator. If it's set to 0, use the normal variable line width like it does now.

Either way, internal perimeters, infill, etc. would continue their variable-width behavior, thus that which is hidden from view will soak-up all of the above artifacts that may result from Arachne's normal variable-width behavior.

Describe alternatives you've considered

The only other alternative I can see is to use the "classic" perimeter generator and careful tinkering with internal line widths to get the best compromise, but that perimeter generator comes with its own set of problems (most notably, illogical print ordering decisions, crazy travel moves, and crazy gap fill widths where perimeters would fit).

[CCS86]

I totally agree.

You would be better off posting this in Prusa Slicer, or Bambu, or Orca, though. SS is effectively dead at the moment.

I actually think there is a better way forward compared to Arachne. But I haven't gotten any traction yet:

https://github.com/prusa3d/PrusaSlicer/issues/10357

[VanessaE]

You would be better off posting this in Prusa Slicer, or Bambu, or Orca, though. SS is effectively dead at the moment.

I've looked at PrusaSlicer recently (using the current release, and poking around just a couple of days ago), and compared to Superslicer, it feels... nerfed, even in Expert mode. Plus its video/graphics rendering lacks antialiasing/filtering, making it look horrible.

Never used Bambu or Orca before. What advantages do they have over the others?

My biggest obstacle to trying other slicers is the inability to port my existing configs/profiles over. I've put a lot of time into fine-tuning my settings, I'd hate to have to start over.

I actually think there is a better way forward compared to Arachne. But I haven't gotten any traction yet

That's a little surprising really -- from a cursory look, your idea seems like it would be a good compromise.

[drone777]

There is wall_distribution_count parameter, but this leaves unchanged internal center perimeters. Leaving unchanged external perimeters would be very good. Only for variable external perimeter i dont use arachne, cause it leaves uneven surface.

[supermerill]

What if I use the classic algorithm for the external perimeter +thin walls, and arachne for the rest? That shouldn't be hard.

[VanessaE]

What if I use the classic algorithm for the external perimeter +thin walls, and arachne for the rest? That shouldn't be hard.

That sounds like it would work well, sure.

But there's one problem with that idea: the classic perim generator makes illogical choices for print order (#3127), so that would need to be addressed first.