Development update 3 April - Arc Overhang fluid recursion implementation progress

[rvmn]

Hi all!
A little update on the progress of the new Pleccer beta coming in the coming weeks, it's coming closer each day.
Focus now lies on fixing the last problems with the mixing extruder support the color picker but there is also progress to show on the arc overhang support of Pleccer!

A rewrite of the Arc Overhang algorithm has been worked out that adds the inclusion of ´fluid´-recursion.
The recursion is called fluid because it prints full fluidly; meaning that no z-lifts or travel moves are needed (except needed side-to-side travel for letting the line cool). There should be no sagging or blobbing happening this way.
The result does become a bit different from the regular recursive arcs.

To show it a few pictures may say the most.

25%
50%
75%
100%

Right now the only parameter available is a percentage of 0 - 100% (images are of 25%, 50%, 75% and 100% resp.), but other parameters will be added in the coming week.

As you can see there is quite a big random factor and there are still some issues. The rsndom factor is hard to defeat as the algorithm calculates everything as cheaply as possible while doing the recursing and things are meant to be fluid anyhow. Next main improvement to use will be adding Arachne lines to make sure the extrusion width is adaptive so the lines adapt a bit and no holes will be in the layer. Also making the big corners less sharp using corner limits. Expect these improvements in the beta coming in the next weeks.

FYI no arcs were harmed in the making of this update!

Greets,
Pleccer

[stmcculloch]

@rvmn Very interesting idea. Is it supposed to simulate a liquid filling the available space?

Have you thought about incorporating a "flood fill" algorithm instead of using arcs? These toolpaths seem promising: stmcculloch/arc-overhang#12

General idea of floodfill:

[rvmn]

@stmcculloch yes exactly, fluid in the sense of adapting to the limits surrounded by.

flood fill is alright, i just see the start of it not being as reliable as arcs are.

the first lines from the starting edge in your example above are just simple 90deg rectilinear lines, that is what has been used for overhangs by all the 'witty' printerers. you basically have to print very slow and hope there is enough accidental upward moving turbulence caused by the part cooling fan to not have it sag ;)
this will probably happen.

btw, the arcs by themselves become flood fill at a later stage, the later stage of the flood fill is not different from the lines in above arc-infill pictures.

[rvmn]

New update on exploring arc recursion

Its a lot cleaner now already and almost without gaps. Getting Arachne at work for it was a bit of a impossibillity as that only works for concentric loops like walls and concentric infill, and not for seperate lines.

Its proven to be pretty hard to get right, because it is having to do a multi-round loop arc-by-arc to recreate the next offset outward, check the outcome, modify if needed, then rebuild the loop offset, check again and so on, so it is a pretty costly algorithm. And getting a parameter too low means bad precision and gaps as result.

[rvmn]

Update:
The major work regarding bridging and overhangs has been finished, now its only over to make the right settings available.
Nice added addition is an option to turn overhangs to bridges when a settable distance is reached (30 mm defaulting, otherwise arcing takes a lot of time).
The bridging also has a setting of how far the bridging can be reliably done, max bridge distance (20mm default). As always a small image of the result:

As you can see, in this image, quote some supports, but this is on medium support setting, it can be set to low support also.

[rvmn]

The, internally called ´arc_diffraction´, recursioning is no ´real´ recursioning but should offer quite some of it's effect also.

Right now there is only an overall strength setting (0-100), showing above is 50%; the middle setting, but internally it has periodicity, amplitude and slit width:

Schermopname.van.24-04-23.21.20.38.webm

[rvmn]

Schermopname.van.20-04-23.09.57.52.webm

Schermopname.van.20-04-23.11.26.03.webm

[rvmn]

bridging

Schermopname.van.20-04-23.11.37.18.webm

Schermopname.van.20-04-23.11.37.54.webm

[stmcculloch]

Really interesting developments! Any test prints?

[rvmn]

yes, but it hasn't been anything really worth it so far, the new arc starting points, even though they are started as part in the previous line, still sag a little bit, not much, just more than i expected them to.
as printing is just a hobby, i have to find time to print some more test files, just finished with upgrading my 2 printers and they should run fine for a while now (have a flsun sr delta and a tronxy corexy), they now print faster and have much better cooling, even though for testing i mightr turn that down a bit to get accurate 'stock 3d printer' results.
also, as last small thing, not an anouncement yet, but still, might be interesting: searching stuff on 5-axis printing i found curvislicer which doesnt even need anything special, and adds non-planar slicing. and that uses iceSL slicer, which is also really interesting. we are all bound to prusa being the 'best FOSS slicer' but iceSL is way more modernly programmed with features that make programming on it fun, where prusa is old-style 'try-not-to-create-more-spaghetti' type programming, i like that is CPP, but it is archaically programmed tbh.
Features that really make iceSL stand strong are among others:

• GLSL and image based infill, GLSL (shading language in C) is used for many things, like shading (which is putting light on 3d objects) and uses a very close to math language. See more here
• very nice, really snug, support which imho beats tree support or at least doesnt/hardly uses more material. More info
  Full feature list

In context: i tried bambu/orcaslicer, but they have become very heavy and are too slow on my 2020 surface laptop, bambu hasnt thought about performance when programming stuff in. Prusaslicer is programmed to perform but doesnt have very good printing results, it is missing logic in the code, seems to be made more by programmers and ideaists than hardcore 3d printerers. Superslicer is a working upgrade from prusa, much better printing results and actually has a lot of good working print features. it just doesn't have good support printing feature/ lacks adaptive layer height and some special options. IceSL has those all, just doesn't have a name/status yet.

SO concluding: i will/am continuing with SuperPleccer as SuperSlicer based fork. And i am going to spend some time understanding iceSL code