Miniature Test (with Arachne)

Still got some under-extrusion going on but could also be due to the speed of 60mm/s being too high.

Parameters

Nozzle: 0.2mm
Wall Generator: Arachne
Minimum wall width/feature size: 20%
Layer height: 0.14mm
Outer perimeter layer divider: 3 (Outer layer height: 46μm)
Outer wall speed: 60mm/s
Wall loops: 3
Sparse infill: Gyroid at 10%
Minimum sparse infill threshold: 5mm²
Tree support: enabled
Top/bottom z distance: 0.08

Time saving

Layer height 46μm: 3h05m
Outer perimeter divider 46μm: 1h32m
About 50% time saving

After some tests the time saving can be between 20-50% depending on the models.

That's an interesting idea. These artifacts will probably be less obvious if we print with a 0.3 mm layer height and use 2 outer wall dividers (resulting in 0.15 mm per divider). Is this intended to achieve fast printing while still maintaining a smooth finish?

These artifacts will probably be less obvious if we print with a 0.3 mm layer height and use 2 outer wall dividers (resulting in 0.15 mm per divider).

Probably, at that small scale the artifacts could be many factors, slower outer wall speed definitely helps, but still not perfect.

Is this intended to achieve fast printing while still maintaining a smooth finish?

Yes, this is based on one of the many post processing scripts from TenTech.
Specifically this one https://github.com/TengerTechnologies/Smoothificator

These artifacts will probably be less obvious if we print with a 0.3 mm layer height and use 2 outer wall dividers (resulting in 0.15 mm per divider).

Probably, at that small scale the artifacts could be many factors, slower outer wall speed definitely helps, but still not perfect.

Is this intended to achieve fast printing while still maintaining a smooth finish?

Yes, this is based on one of the many post processing scripts from TenTech. Specifically this one https://github.com/TengerTechnologies/Smoothificator

I'm glad that there are skilled people like you, which turn concepts into actual slicer implementations. I love the opensource community, thanks for working on this!
I don't know if you have seen the update to the script @philyeahz @SoftFever . I didn't have the time to make a good read.me. So sorry for that. I've changed some things and "miss-used" adaptive layerheight to keep a more accurate dimensional accuracy. https://youtu.be/eIHOYqJPfSY It also now tries to get as close as possible to the desired layerheight which is not a very visible difference in layerheight to the naked eye

Just checking, is this PR still active?

Just checking, is this PR still active?

Not really, I could rebase and fix the small issues so it could be merged as an experimental feature,
but to really make it good would still need a lot of work, like designing proper handling of multi layer height layers (sorting, collision checking, overhang and bridging) and not just blind z-shifting.

Just checking, is this PR still active?

Would it be interesting enough to have it in the slicer?

There are still a couple of problems with the concept itself. If there is general interest in the topic, I could revisit it. But unfortunatly only in my script, as I'm not experienced with the Orca code.

Another benefit I can see is that it would help tremendously with steep overhangs without supports.
This way we could have denser flatter overhang steps without decreasing layer height globally. Speed + quality + strength boost simultaneously.