Open Cenwulf opened 1 week ago
I believe the developer enabled the Scarf seam feature by default in V1.10.0 and temporarily disabled it mainly because they are seeking a better solution to address the inconsistency in surface performance, as described in the release notes. Based on that, the Scarf seam will be associated with filaments rather than plates or specific models. Therefore, they have moved the scarf parameters to the filament setting, hoping that it could become a set-and-forget type of feature, which I think is reasonable. We should give them some time to see if they can achieve this goal before reverting to the previous state.
As you point and the patch notes acknowledge,this is still a work in progress feature, which is all the more reason to put those settings back into process settings, at least for now. These sort of changes belong in a beta branch rather than prematurely changing the way users interact with a previously stable and usable feature for a loss of functionality and ease of use.
I understand the developer’s reasoning, I just think it’s fundamentally flawed. The seam settings are far more applicable to the model and so it’s far more appropriate that they remain in the process settings as the classic seam has for its entire existence, which itself was pretty well optimised optimised at this point and still remained a process setting despite that.
Even if the aim to make it set-and-forget is achieved, why does that make it more appropriate for them to reside in the filament profile? Is the filament profile a place for unrelated settings you don’t think the user should need to interact with? (I would say no). What’s wrong with leaving them in process settings and enabling them by default in the existing built-in presets?
By all means have overrides in the filament setting for those niche filaments where scarf seam actually isn’t appropriate (out of interest, do we know of any?). This is a very well established way of doing things, the current route is a departure from that norm and for very little benefit aside from potentially reducing clutter in the process settings (which we already have the Advanced switch is for).
To use the wall generator as an example, I’ve found very little reason to ever use anything other than Arachne. However, the classic wall generator is still the default. Should that be changed to Arachne and placed in the filament profile too? Answer: No. It has about as much to do with the filament as the scarf seam does.
Another reason not to put scarf seam settings in filament settings, these settings are unavailable for use with modifier parts. There are instances when printing multipart multicolour prints that scarf seam can cause adhesion issues and bleeding between colours on the first lay, for example, this print where a coin is printed face down in two halves with a 0.2 mm nozzle:
In the past, I would add a modifier to to ensure that scarf seam is only applied to the outer edge, now that is not possible and print quality of the inner graphic has suffered as a result.
I cannot hammer home enough that there will never be a situation where putting the scarf seam settings in the filament profile is appropriate for all use cases, and the downsides of keeping it in the process settings do not outweigh that.
Scarf settings should NOT be in the filament settings.
Please revert the scarf seam settings location back to the process settings as they were prior to the 1.10 release.
Filament settings are, in generally, a set-and-forget affair. The vast majority of tweaking on per print basis should be done in the process settings. Scarf seam settings still are, and arguably always will be, more dependent on the model being printed than the filament being used. In particular having the scarf type tucked away in filament settings is completely nonsensical. Whether a user wants a scarf seam on a contour, a hole, or both has very little to do with the filament.
It is possible that in the future scarf seam settings will get to the point where they can be a set-and-forget type of setting, and can handle any type of model or situation thrown at them. However, they're absolutely no where near that stage yet as evidenced by the fact they've been disabled by default in the latest release. Even if they were to reach this stage of development, there is a strong argument to be made that they still do not belong in the filament settings.