arc-overhang
arc-overhang copied to clipboard
stmcculloch
Using the same center as long as possible
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.
@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
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
@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?
@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.
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?
@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.
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
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:
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
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?
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:
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.
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...
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.
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!!
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.
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!
@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:
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 !
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
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.
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.
@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.
A little update for anyone reading this: https://github.com/rvmn/SuperPleccer/discussions/3
@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 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
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:
