Using the same center as long as possible #10
Comments
|
@MULTIPL3X Great idea. It results in an incredible improvement in surface quality! VID_20221219_003908.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 :-)) Prusa_POC_Arc_Overhang.mp4This 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). |
|
@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. 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 I was seeing a nice video on 3d printing software advances in a industrial based 3d printing companion called Ai Build. |
|
@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!! Pleccer_alpha_arc_overhang.1.mp4For 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:
|
|
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. 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:) |
|
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. |
|
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 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!! |
|
@radarOverhead here you go, the promised build for linux: Pleccer alpha1 linux |
|
Thanks so much rvmn ! downloading now! |
|
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. 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 |
|
Thanks rvmn ! Giving it a whirl now ... |
|
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
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: |
|
@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, |
|
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:
|
|
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. |
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. 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). |
I didn't now about @rvmn 's work. I saw no updates on stevens page and thought the idea died out. 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. Or all in one question: What are the needed parameters for a successful, reliable print of the arc overhangs? 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 about the data gathering today. What I propose to find the Process Limits: 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.
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 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 do you think of this approach? PS: I modified the script so it can generate the gcode for these tests. |
|
"I didn't now about @rvmn 's work. I saw no updates on stevens page and thought the idea died out. @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_factor_increment (like 1.05 per arc). 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. "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: 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. |
|
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. |
|
@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.) |
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. |
|
@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 :) |
|
@pedroloco2 Sure thing, I didn't take it as an offense, but thank you for your kindness! 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? |
|
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 ;> |
|
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 |
|
You can download PrusaSlicer for mac Here: script should work, only the install of the librarys is different. |
|
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. |
coming in the next pleccer version: Schermopname.van.20-04-23.09.57.52.webm |
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.
The text was updated successfully, but these errors were encountered: