Using the same center as long as possible

[MULTIPL3X]

Ever thought of Expanding the arcs further form the first center like this?

In some of your pictures you can see that there are more printing issues when starting at a new center maybe this would help to increase print quality.

[stmcculloch]

@MULTIPL3X Great idea. It results in an incredible improvement in surface quality!

https://user-images.githubusercontent.com/9290784/208489632-84dda0bd-c0ba-4d96-9dd9-c2765d962b8e.mp4

[rvmn]

Hi Steven, thanks so much for making this fantastic and well, pretty mind-boggling, discovery and sharing it! 👍. You could be making milllllionsss, or help everyone and make it FOSS :-)) I took a few spare evenings and made a POC of it by integrating it in Prusaslicer, a small option as 'Arc overhang' that you set as bottom infill (used for both all bridges and overhangs) and let it automatically print overhangs. I am building a fork of SuperSlicer that is aimed at multicolor 3d printing (mixing extruder) because there is hardly any support for it slicerwise. I will be publishing this in a few weeks. I hope you are ok with me integrating the Arc overhang as default setting, i can put your name and link (in the code for sure, maybe somewhere else as well). I took a small movie of the integrated result in prusaslicer.

https://user-images.githubusercontent.com/8228964/209891959-bc7fce22-c4e7-4563-a363-f6e824599dfc.mp4

This POC in Prusa i have abandoned because prusa offers no control over the starting point of the infill (so you have to rotate the model to get the rigth starting point, hassle...). I made a small possible improvement by starting in the corner because in the middle the first dot will always tend to droop down, and on the side it can't. I have not tested it IRL yet, so I have to see if it prints well. If you like i can send you the windows build i made so you can experiment with it (can also build a linux build...). I will publish the code in a few weeks on github inside my multicolor slicer (pleccer). Gcode file: Prusa_Arc_Overhang_POC.zip Best, greets Roberto

[stmcculloch]

@rvmn WOW!! Great work! Thank you for taking the time to add this into a real slicer. It looks super promising! I'd love to check out the Windows build you made to try it out.

You're free to incorporate and improve upon arc overhangs however you wish. If you want to make them enabled by default, by all means go for it! Could you include a link to the main github page (https://github.com/stmcculloch/arc-overhang) in the tooltip when you hover over the setting?

[rvmn]

@stmcculloch Yeah, a tooltip link sounds very logical, that is what is builtin already in Prusa, I'll link it to here. Here you go then, Ill just put it in here: download_link To use it just go to the Settings - Print - Infill and set Bottom Infill to Arc (which means detected overhangs and bridges). If it starts the infill printing from the wrong side just rotate the object and try again :) I keep this Prusa version as backup, so if you need a quick change (like reverse to middle midpoints) tell me, I can change it and repost. The new SuperSlicer version is working much better, without the extrusion path direction issue. I just now want to also add a detection of inflex overhangs vs non-inflex overhangs and only add support on inflex overhangs which really need support to not be printing mid-air. I have a algo ready to do that (octree on angles and tree-walk to bottom). Also Superslicer's detection of overhangs and bridges is much better: Prusa just uses normal perimeters on a lot of bridges, anyway, Prusa is nice as well, no question.

Have fun and tell me if you have wishes/improvement thingies etc.

[rvmn]

I quick modify-made a version of the build with centered start point, just for comparison: centered Here is the test file I use mostly, btw: overhang_thing.zip

I was seeing a nice video on 3d printing software advances in a industrial based 3d printing companion called Ai Build. I think what is really interesting and really innovative is the simulation they do of the print to adjust extrusion rates, speeds based on what really is going to happen. I was thinking we could also just mail them, en-masse, asking them if we can use their simulation for making good Arc overhang, good idea right?

[stmcculloch]

@rvmn I tried out the builds you posted, corner and centered. Great start! I see the issues you mentioned about the path direction and overhang detection. It sounds like your SuperSlicer version is very promising, I would love to know when you have that ready.

As for the AI build, it sounds really cool, but I think of that approach of simulation or in-process correction as a last resort. My wish is that arc overhangs become reliable enough with default settings that it works "great" or at least "good enough" 99% of the time, similar to how bridging is currently.

[radarOverhead]

Great work on this fantastic idea. I would be happy to be a tester of different methods using either PrusaSlicer or SuperSlicer on linux. Sitting here in awe of how far you have pushed the boundaries here

[rvmn]

Ok, to give a small update on the progress of Pleccer development and arc integration: orientationing works!! I made a small demo to show the new updated version:

movie

For anyone interested in testing, I'll post the new Pleccer alpha binaries for windows and linux (building deps takes ages on WSL, hopefully also tomorrow finished...) here tomorrow.

Small caveats I've found, so far:

• overhangs with holes create a hole in the arcs, need to create more arcs starting on each side there. I'd say two arcs each on opposite side should do? Maybe two arcs coming from opposite corners is even better (supposing its a square)? Or does anyone have a better idea? I am still thinking on this situation.
• sometimes the print direction is reversed (printing end of arcs first), this needs a fix in bridge angle detection

[stmcculloch]

I cannot wait :) Amazing progress, thank you so much!

I've been trying to implement this for myself into a fork of superslicer but I have so much to learn and it's taking a long time. I would love to be able to see how you did it so that I can start making my own tweaks. Will you be pushing these changes to the Pleccer github?

[rvmn]

Sure, it will be AGPL like the source, with the stable version in Feb. week1 or 2, i am halfway with the other features now. For anyone interested, the windows build of alpha1 of Pleccer, with Arc overhang Linux build is building, took 3 noons to build the deps in windows WSL :) and the build is building atm, one minute..

Next upgrade I have thought out, is an idea i call 'slitting' arcs. They work a bit like slits in a wave slitting interference/diffraction experiment, but it's not scientifically related in any way so i take no personal responsibility if you try what happens when you point a big laser at it and hope it will behave like wave or a . I am thinking on implementing an actual wave function to make the arc become 'wavy', which opens new options to edit the wave function later:) Here a drawing of the idea in action. It is working when the arc's become to straight and then changes them into arcish things again:

[MULTIPL3X]

Hey rvmn great work so far. I am pretty excited to make some test prints.

The last few days I also thought of possible problems when the arcs radius is getting too big. My idea was to add a setting called 'max arc radius' which makes the slicer start a new centre when it is reached. Not sure if it would be better to use waves or just new centre's but it would be interesting to make some tests.

[radarOverhead]

Really looking forward to the Linux build rvmn!

Tried building it yesterday and failed miserably. Kept getting errors. I musta gotten something wrong early on...

[rvmn]

It is still busy, following Murphy's law it should be done in about two days;-P I guess it might be faster, it's just hard to predict with such slow progress.

[stmcculloch]

I downloaded the pleccer prerelease and tested it with a model I designed that has a bunch of simple bridges and overhangs: https://www.printables.com/model/363919-overhang-and-bridging-test-model

Here are my results:

It works in some cases but it seems to have issues finding the right edge to start from. In the original implementation, the starting point was defined as the point on the overhanging polygon that is farthest away from the boundary of the polygon. I'll do a bunch more testing this week, this was a bit rushed since it's quite late and I have work tomorrow :)

Great progress so far, it makes me so happy to see this idea come to life in less than 1 month!!

[rvmn]

@radarOverhead here you go, the promised build for linux: Pleccer alpha1 linux

[radarOverhead]

Thanks so much rvmn ! downloading now!

[radarOverhead]

Its workin! Life is gettin in the way,, however. Did a quick test after rushing all of the settings. The arcs are well overextruded and, therefore, sagging badly. I tried first to quickly slow print speed, didnt help. I then reduced the extrusion rate, which did help greatly. Then got called away .

FYI, I'm using a CR10sProV2 with diy direct drive all metal hotend running klipper. Petg and tpu almost exclusively. Printing functional parts that are under tension and compression. In direct exposure to the elements in a fairly hot environment (+40c numerous days of the summer).

Currently printing swimming pool parts that are submerged 100%

Will post pics when I can.

[radarOverhead]

I'm seeing the same issues stmcculloch is seeing.

Then I noticed that we can use arc as an infill and thot maybe infill parameters will effect the start point of the arc overhangs and it does.

I initially had a fill angle of 45deg. If I change that to 0deg, now top solid infill arcs on some samples I made are starting on an edge and going the correct way. Still testing...

Great work stmcculloch and rvmn!

[rvmn]

@stmcculloch Thanks for that great test model, got it working (on github). Now the next issue is the path planning optimization sometimes kicks in and changes things around, then i think it is usable.

@radarOverhead Oh yeah it listens to bridge_angle and bridge_infill, and you should keep the angle at 0 to have automatic bridge angle detection, might make it some additional angle in the future, a modifier angle. love to see what models you make, im designing a mmu and color mixing printhead. And a merged multi model test file: arc_overhang_models.stl.zip

UPDATE: I fixed two major issues yesterday that now make this alpha2 release in fact printable on most not too complex models. Firstly, the path planning bug is fixed: as long as the paths are continuous the printing direction is goind to be ok, no more issue there. The second is it will now always start on an edge and not accidentally hang out somewhere middle-ish. For giving a small example on the results check these images out:

[rvmn]

https://github.com/rvmn/SuperPleccer/discussions/1

[radarOverhead]

Still keeping tabs on progress here.

Found Alpha2 was extruding arcs from the outside in, in some cases. Much better to have the filament stretch over the previous arc vs "hopefully stick".

Eagerly awaiting Alpha3 !

[rvmn]

ok, alpha3 is added. it is much much more reliable and adds bridge direction detection tweaking for if you find angle is off (see release info for where to find it) !!! edit NOTE: if you put the first number in the scoring table on 6040 you get better results.

also this version adds the pedestal overhang printing, i tested it and it seems to only work when the pedestal is centered (small mistake.. i wanted it to be published now so i didnt fix that obvious loc:-P).

edit NOTE: put

[radarOverhead]

Thanks rvmn !

Giving it a whirl now ...

[rvmn]

i have an even better idea i think: i am going to make a new infill type i call 'wavy' it is just a perpendicularly angled line infill with a wave function behind it. it should work also because the waves increase the connectiveness between subsequent infill lines. then, to make it perfect the next level i call 'wavy arc' infill which combines the wavy and arc infill.

[pedroloco2]

Interesting idea, in fact it would be more logical to create a new and specific infill type to have more control, especially in the case that it has to be postprocessed. Is the source code available or just the compiled version.

[rvmn]

@pedroloco2 thanks

it will be AGPL like the source, with the stable version in Feb. week1 or 2, i am halfway with the other features now

im adding these as default infills for the new slicer (Pleccer) which is a fork of bambustudio for multimat color mixing printing (rgbw style or cmyk style will be avauilable with color calibration storage and usage). you can wait for it until release half feb to see source code or find a compiled prerelease here, in a few days or the arc infill version of superslicer

regarding the wavy infiill i am still thinking what params there will be, at least amplitude (height wave) and frequency (amount waves) both as relative numbers to the average width to span and as absolute nrs. so you can say give me 8 waves on the average everywhere with a height of 0.5 relative to width, so the waves scale to width. but absolute setting is probably more sensical, it will so you geta wave every cm everywhere for example. but a min waves on average setting will be aded to make sure you get enough waves with any setting.

[rvmn]

A little update for anyone reading this: https://github.com/rvmn/SuperPleccer/discussions/3

[stmcculloch]

@rvmn Epic! I like that you added the small supports for the arcs, a lot of people were asking about that!

Once your pleccer release is available, I will share it with as many people as possible, and hopefully convince CNC kitchen to make a follow-up video exploring pleccer and arc overhangs. Your work deserves a lot of attention for taking my humble proof-of-concept and turning it into a real tool for everyone to use.

[rvmn]

@rvmn Epic! I like that you added the small supports for the arcs, a lot of people were asking about that!

Once your pleccer release is available, I will share it with as many people as possible, and hopefully convince CNC kitchen to make a follow-up video exploring pleccer and arc overhangs. Your work deserves a lot of attention for taking my humble proof-of-concept and turning it into a real tool for everyone to use.

Thanks!:+1: That would be awesome!

Arcs and spirals are working perfect now, in all senses of the word, i will release them in the beta1 version next week: announcement beta1

[stmcculloch]

Here's an unexpected update! Nicolai Wachenschwan has created a prusaslicer post-processing script that performs a modified version of the original arc overhang algorithm. Please check it out here: https://github.com/nicolai-wachenschwan/arc-overhang-prusaslicer-integration

It works pretty well! But we would appreciate some help testing it and improving it! @rvmn you may want to take a look at this, as I think your pleccer implementation could incorporate some ideas from this script. For example, we can now handle holes, although it uses the old algorithm so that means it'll use recursive arcs which look worse, but can still be useful. Here's a sample of what it can do:

[pedroloco2]

In my humble opinion, and without detracting from the effort of Nicolai Wachenschwan (any contribution is always welcome), I am convinced that the work @rvmn is doing is the way to go. For my part, I would like to suggest a few things that may be useful: 1: It is not specifically necessary that they be arcs, it can be any other shape that facilitates the location of the initial point. Even the printing order can be from the outside to the inside with the use of columns or support pillars. 2: It is essential to overlap (bonding) each line between 5% and 15% according to the material to give greater stability and less deformation. 3: Both the print speed and the fan speed must be selectable specifically for this type of overhang.

[rvmn]

In my humble opinion, and without detracting from the effort of Nicolai Wachenschwan (any contribution is always welcome), I am convinced that the work @rvmn is doing is the way to go. For my part, I would like to suggest a few things that may be useful: 1: It is not specifically necessary that they be arcs, it can be any other shape that facilitates the location of the initial point. Even the printing order can be from the outside to the inside with the use of columns or support pillars. 2: It is essential to overlap (bonding) each line between 5% and 15% according to the material to give greater stability and less deformation. 3: Both the print speed and the fan speed must be selectable specifically for this type of overhang.

Thanks, I think both are important: an ongoing experimental approach with the arc fundamental techniques with testing and i'll then ofcourse do the coding into a slicer to make it usable to the public.

I think the arc repetition/recursion is best only to be used when needed because it is causing sagging. As a rule perhaps the arc should only be renewed when a) there is a big difference in arc length i.e. a hole or b) when the radius of the arc becomes too small which in fact is also the case in point a) so b) could be the only needed criterium. If @nicolai-wachenschwan or you @stmcculloch could implement that in the script and perhaps also do some tweaking of the flow rate or overlap of the arcs and show. In the slicer version i will work out this criterium and a new arc function to make new arcs when needed. As for the long curling overhang (bottom left image) i think there the arc repetition fits really well as well, i was thinking splitting up such surfaces but this looks really really nice!! thanks a lot @nicolai-wachenschwan!!

Thanks a lot for the ideas @pedroloco2; would you reckon a extrusion width multiplier that increases a little when the arcs become bigger would be an idea? I am thinking for the small arcs you might actually want a small extrusion because otherwise they sag and overextrude, while the bigger the arc the more logic a bit extra extrusion becomes, to bind well. So a extrusion_factor_start (like 0.9) and an extrusion_factor_increment (like 1.05 per arc). Speed as increment is also an idea. As for shape: arcs are best, i think, other shapes just are less smooth, and smooth will extrude equallest. only shape i have been considering is a (smooth) spearhead pattern: aka the 'sharc' (teeth) pattern this would probable i think reduce warping a bit because the shapes intergrip in the vertical direction. I have no plan yet to work it out yet, but perhaps the script could be upgraded.

[nicolai-wachenschwan]

In my humble opinion, and without detracting from the effort of Nicolai Wachenschwan (any contribution is always welcome), I am convinced that the work @rvmn is doing is the way to go. For my part, I would like to suggest a few things that may be useful: 1: It is not specifically necessary that they be arcs, it can be any other shape that facilitates the location of the initial point. Even the printing order can be from the outside to the inside with the use of columns or support pillars. 2: It is essential to overlap (bonding) each line between 5% and 15% according to the material to give greater stability and less deformation. 3: Both the print speed and the fan speed must be selectable specifically for this type of overhang.

I didn't now about @rvmn 's work. I saw no updates on stevens page and thought the idea died out. I speak Python intermediate, but C/C++ not that well. Therefore manipulating a slicing software was not an option for me, but the post-processing-script was a thing I make reality instead of waiting for companys to move.

Of course the long term solution is an integration into a slicing software, like @rvmn does. Great work and thank you for your apreciation!

A manipulation of the script to alway iterate until rMax and split the arc as needed is easy and fast to implement. But it raises more questions: How much should be rMax? i.e.: what amount of curvature is needed for the layer adhesion? How long is the minimal linelength? How much overlap should the arclines have for proper adhesion?(script arcwidth=95% of nozzle dia. extrusion:1.35 x nozzle_dia^2*pi/4.) What role plays the speed, cooling, extrusion multiplier, material, nozzle size?

Or all in one question: What are the needed parameters for a successful, reliable print of the arc overhangs? Those are physical limitations, which should be answered first and lead to useful code.

we could investigate with the help of "design of experiments" (and using analysis of variance), because a lot of these factors will have cross relations.

My findings so far: I thought rMax was small, like 20mm. Therefore recurision is needed to ensure enough curvature for the filament to adhere to. But: a D-Shape with diameter of 100mm, rMax=50mm printed perfect. Limit seems to be higher. Valid for continous arcs. Extrusion multiplier 1.35 = good stability+good quality. >1.5=inconsistent extrusion/blobs/sagging. Printing at 1.5mm/s and small arcs at 0.5mm/s = almost 0 sagging, very nice surface quality. (arc center offset=2mm). Long and small brdiges do not have enough stability to support their own weight and deform. All for PLA,190C,cooling 100% on a mk3s, 0.4mm nozzle.

[nicolai-wachenschwan]

I thought about the data gathering today. How do we understand the adhesion process and its needed conditions + limits? =>If we do so we could taylor a specific algorithm that performs ideal in various (specific) usecases.

What I propose to find the Process Limits: we could measure the maximum printable radius without any support aka the point where the support can't support its own weight. This would allow easy user warning if the print is to ambitios and is likely to fail.

To quantify the print quality we could measure the maximal successfully printable radius, depending to the other factors. like speed, width,...=>If we achive rMax>100mm we can save us a lot of algorithmic hassle in arc generation. =>Supporting the arcs with a middle beam. Suggested factors: 1) extrusionMultiplier, 2) ArcWidth(aka Overlap between individual arcs), 3) nozzle_diameter , 4) width 5) print speed 6) print direction (I noticed failures at some specific angles, maybe because of cooling) 7) Temperature 8) ?

we can choose up to 8 factors to analyse with only 16 prints, executed as in the current idea each print will take 2-6 hours. What we will get is a definitive model of the process, so we can tell for example: Temperature does not matter much, as the effect is very small. Possible Test Geometry:

What I can do: prepare the gcode-files and do the numbercrunching to extract the effect strength etc. (my "Minitab" Licence expired but my Matlab should do the trick: Multivariante Analysis of Variance). What I can't do: Currently I dont have time to do the prints myself :/ Also I cant do the pretests to determine the range of the parameters (example:width:5-50mm).

What do you think of this approach?

PS: I modified the script so it can generate the gcode for these tests.

[pedroloco2]

"I didn't now about @rvmn 's work. I saw no updates on stevens page and thought the idea died out. I speak Python intermediate, but C/C++ not that well. Therefore manipulating a slicing software was not an option for me, but the post-processing-script was a thing I make reality instead of waiting for companys to move."

@nicolai-wachenschwan, I see that you have understood my comment and I think that it is not necessary to clarify it, but I apologize if my message was interpreted as a criticism, since I was not referring to your work or to the knowledge of programming languages (every one of us tries to solve the problems that arise with the tools that we have), although I maintain that the implementation through post-processing-script is not the ideal way, tend to have much less control, it is not impossible but it has many limitations. I have no doubt that if you collaborate with @stmcculloch, @rvmn and whoever wants to join, we will be able to enjoy this function in a very short time.

"Or all in one question: What are the needed parameters for a successful, reliable print of the arc overhangs?"

_"Thanks a lot for the ideas @pedroloco2; would you reckon a extrusion width multiplier that increases a little when the arcs become bigger would be an idea? I am thinking for the small arcs you might actually want a small extrusion because otherwise they sag and overextrude, while the bigger the arc the more logic a bit extra extrusion becomes, to bind well. So a extrusion_factor_start (like 0.9) and an extrusion_factorincrement (like 1.05 per arc). Speed as increment is also an idea."

When printing the "arcs" lines the flow rate (and therefore extrusion width multiplier and printing speed) must remain constant and be lower than the rest of the print (much more the speed). Any variation will tend to produce sag or lack of adhesion and therefore greater deformation. Bonding "arcs" lines by amount (more lines for the same area) not by changing extrusion factor, overlap between 5% and 15% (or more in some specific cases).

"As for shape: arcs are best, i think, other shapes just are less smooth, and smooth will extrude equallest. only shape i have been considering is a (smooth) spearhead pattern: aka the 'sharc' (teeth) pattern this would probable i think reduce warping a bit because the shapes intergrip in the vertical direction. I have no plan yet to work it out yet, but perhaps the script could be upgraded."

I would not rule out the 'sharc' (teeth) pattern at all, using it in the same orientation as the "arcs" it is very likely that it will help to greatly reduce the warping at the lateral ends.

I hope to be able to make a little free time outside of my work and to be able to collaborate more actively and not stay just in words.

[stmcculloch]

Of course, the final goal is for this to be integrated into a real slicer, and that's what @rvmn is already making really good progress on. That said arc overhangs are still very experimental, and there's still a lot of room for improvement.

I think there's benefit to having a python post-processing script simply because python is so much easier to understand and modify than a full slicer implementation with C++, and it makes for a great research tool. There are so many potential changes to the algorithm that would make it print cleaner/faster/more reliably and I'm sure we have just barely scratched the surface. It is a lot easier to quickly iterate ideas in python, and then once a good algorithm is figured out, we can do a more efficient implementation in C++.

If the community wants to contribute and accelerate this idea, I'm sure people would be more comfortable modifying a post-processing script than the C++ code directly. Personally, the C++ coding is a bit out of my depth so I haven't been able to really help on that side, but Python is much more familiar and I'm sure many people feel the same way.

There's just a few of us working on this now, but I think we can soon get some more interest and help with this idea now that it is essentially ready for people to use. @rvmn any idea when pleccer will be released? I'm sure some 3D printing youtube channels would like to cover this, and that'll probably bring in a bunch of new people who would help test.

[rvmn]

@stmcculloch that's not how these issues work, you can't just copy everything into this one ;) i like that it stays! it's not like discourse where it is like gone and you can try search it in the big tunnel thing. i looked into that option but ftm i focus on getting things finished and the recursion is the last thing i need to irreconcilably add so as to make it 'work-OOB-and-IRL', also then i upload the code. (as side note, internally there is a arachne version of so-called concentric infill which uses arachne's adjustable line width, i could use that but it's been a question of whether that's going to really give better prints. personally i think it will only perhaps in the end do away some gap filling with the loose straws there are, and that is just a small issue for infill be it for overhangs a tiny winy bit bigger.) btw, a windows version is available again

[rvmn]

@rvmn any idea when pleccer will be released? I'm sure some 3D printing youtube channels would like to cover this, and that'll probably bring in a bunch of new people who would help test

Really very almost. It's a bit of a guess; finalizing actually always takes more than what you foresee, but i will need this coming weekend to finish the inner work and am extra half week to finish the external stuff, web site and tests and builds.

[stmcculloch]

@rvmn Good point, we probably shouldn't be using an issue as a "general" chat. I added a discussion page for more 'disorganized' chat. So now we can keep these issues on topic :)

[nicolai-wachenschwan]

@pedroloco2 Sure thing, I didn't take it as an offense, but thank you for your kindness! @stmcculloch : Great idea to use the post-processing script as testbench, didn't think about that. Example: you want to print shark-teeth? Modify "create_circle" function and you can test the idea. @rvmn : of course the ideas wont be 1:1 portable, but I think it can be useful to test ideas and fine-tune them into concrete mathematical expressions. Example: what is a good criteria to make a new centerpoint and where should it be, so it performs well in a lot of different geoemtrys?

Regarding the warping issue I am thinking of printing a surface with reducing the thermal stress by printing lines with a small length, distribute the stresses in different directions and print islands in a random order, that grow together slowly. Maybe kind of a hilbert-curve, split into multiple parts? I am still thinking of a way to accomplish this surface structure.

[pedroloco2]

With respect to warping specifically, the most serious problem occurs when printing the following layers. The ideal solution would be to place support pillars at all ends of the arc-overhang layer and every certain distance (short, because otherwise the pillars would also be deformed and therefore reducing their usefulness) throughout the perimeters, but this would take us to the beginning and to ask ourselves if the use of normal supports is not better with the increase in speed that this implies.

From my point of view, it would be very important to specifically define the cases in which arc-overhangs eliminate or significantly reduce the use of supports and concentrate efforts there, and not try to apply them compulsively. According to my experience, I have noticed that applying them in large areas, or not very symmetrical or with a single support base, warping takes center stage, making it impossible to print parts that require dimensional accuracy and stability.

Going back to the beginning of the conversation and to the experimentation stage, I can think of an alternative and easy to test methodology that can be useful to find the limits of "arc-overhangs" in order to reduce warping, this would be: change the printing direction of each perimeter loop (one clockwise and another counter-clockwise) and that the number of perimeters is an even number and not less than 4. The next layer will print everything (overhangs paths included) in the reverse direction, reducing the flow a bit and so on for a number not less than 4 layers (counting the initial layer). If this basic example shows some slight improvement, it means that the material used has room to start testing different patterns or structures that reduce warping, such as those suggested @rvmn and @nicolai-wachenschwan.

PD. @stmcculloch: "List of good ideas" is a good idea ;>

[NunoFilipePereira]

I have been following this project since the beginning. But I was never able to install it on the prusa through my mac. Are there any specific things? Or does anyone have the same setup that might help? This project is top

[nicolai-wachenschwan]

You can download PrusaSlicer for mac Here: https://help.prusa3d.com/downloads#_ga=2.46906144.64351760.1677914604-1896826261.1677535725

script should work, only the install of the librarys is different.

[NateTG]

I suggested this to @nicolai-wachenschwan, but maybe it fits better here. With a smoothly varying extrusion width, it's possible to move the center of curvature a little bit with each arc:

The arcs are thickest in the middle and then thin out proportionally to the cosine of the angle off center so that the width in the X direction is constant, and they stack. (The edges are about 0.7 times as thick as the middles here.)

I don't have easy access to a 3D printer right now, so I can't test how possible it is to control the width in a suitable way.

[rvmn]

Sure, it will be AGPL like the source, with the stable version in Feb. week1 or 2, i am halfway with the other features now. For anyone interested, the windows build of alpha1 of Pleccer, with Arc overhang Linux build is building, took 3 noons to build the deps in windows WSL :) and the build is building atm, one minute..

Next upgrade I have thought out, is an idea i call 'slitting' arcs. They work a bit like slits in a wave slitting interference/diffraction experiment, but it's not scientifically related in any way so i take no personal responsibility if you try what happens when you point a big laser at it and hope it will behave like wave or a . I am thinking on implementing an actual wave function to make the arc become 'wavy', which opens new options to edit the wave function later:) Here a drawing of the idea in action. It is working when the arc's become to straight and then changes them into arcish things again:

coming in the next pleccer version:

Schermopname van 20-04-23 09:57:52.webm

more info