OrcaSlicer
OrcaSlicer copied to clipboard
SoftFever
[Feature Request] Non-planar slicing
Is there an existing issue for this feature request?
- [X] I have searched the existing issues
Is your feature request related to a problem?
copy of issue #1118 because of stall
Which printers will be beneficial to this feature?
All
Describe the solution you'd like
Add non-planar slicing with topologies like "circular,linghning, etc"
Describe alternatives you've considered
No alternatives yet.
Additional context
No response
Existing implementations as reference. https://github.com/DrEricEbert/Slic3r_NonPlanar_Slicing https://github.com/teachingtechYT/PrusaSlicer https://github.com/teachingtechYT/PrusaSlicer/releases/
Existing implementations as reference. https://github.com/DrEricEbert/Slic3r_NonPlanar_Slicing https://github.com/teachingtechYT/PrusaSlicer https://github.com/teachingtechYT/PrusaSlicer/releases/
As well as:
https://github.com/EiNSTeiN-/PrusaSlicer
techingtech attributes their release to them, and takes credit singularily for getting it built.
DrEricEbert made it for Slic3r, EiNSTeiN- ported it to PrusaSlicer 2.6 (close to a year ago)
My bad must've missed that!
Den fre. 19. apr. 2024 kl. 20.46 skrev TheYang @.***>:
Existing implementations as reference. https://github.com/DrEricEbert/Slic3r_NonPlanar_Slicing https://github.com/teachingtechYT/PrusaSlicer https://github.com/teachingtechYT/PrusaSlicer/releases/
As well as: https://github.com/EiNSTeiN-/PrusaSlicer techingtech attributes their release to them, and takes credit singularily for getting it built.
DrEricEbert made it for Slic3r, EiNSTeiN- ported it to PrusaSlicer 2.6 (close to a year ago)
— Reply to this email directly, view it on GitHub https://github.com/SoftFever/OrcaSlicer/issues/5053#issuecomment-2067111969, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAL2FL27PGL5C4SOO63LZC3Y6FRBLAVCNFSM6AAAAABGKG72ZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRXGEYTCOJWHE . You are receiving this because you commented.Message ID: @.***>
I'd love to see this in an Orca-Slicer build and go main-train, if there is movement on this I will kick in some cash for the developers. TIA
I want this.
https://www.youtube.com/watch?v=cbhWni9f980&t=763s&ab_channel=TeachingTech
Additional issue requiring the same: https://github.com/SoftFever/OrcaSlicer/issues/3455
sidenote: I would love to see this here!
Another implementation for reference https://github.com/makertum/non-planar-layer-fdm
This will improve print quality on some models many times over, hopefully you will add it
@SoftFever can you please comment on this issue to take up an official stance on it?
It's not in my immediate plan. But if anyone want to contribute, it's always welcomed.
Dear Community! Should everyone be interested in resolving this issue send a :rocket: here! I do not even know where/how to start, but I am hoping with a small, focused group we can achieve this!
Dear Community! Should everyone be interested in resolving this issue send a 🚀 here! I do not even know where/how to start, but I am hoping with a small, focused group we can achieve this!
I've built myself a custom printer to do that; soon or later I'll have to dig in some slicer as well. But ... I hope some developers with previous experience will be faster than me: from what I got, 99% of consumer 3d printed parts are sliced using forks of the same original code base. So, any developer with previous experience within that code base can do the job much faster than any other (and me). And/or one of the many companies taking a Common code for their dirty deeds, should finance this.
The other issue is the chance for Autodesk to abuse of their brand new patent (2015). I doubt the patent is valid: I remember non-planar CNCs pre-existing their patent but I can't figure out where I've seen it. Last time I said something like this was about Apple's MagSafe ... and attached the picture of a cattle with magnetic cable sold in Thailand in the '60s, then I got threatened online by some trolls... But, despite preventive evaluation of patent validity, they can crush someone's life by just filing a lawsuit (see SLAPs in US), even in the case the patent would then be declared not valid by a court because of "previous art" pre-existing the patent; so ... probably we should proceed with a clean room design approach, and leave the non-planar code in a patch to be applied by the users themselves. And probably that patch should be placed in some european jurisdiction, because in EU a non-profit can create and distribute the code for free even if the methods are entangled by some commercial patent. In US they have software patents and any other law made to protect predators'. So distributing it from EU, would allow americans to benefit as well, despite their laws.
I see there is significant interest in this! I have tried and failed to gather emails for the interested users through github. Please send me a mail through my github profile so I can invite you to a platform where we can better communicate on this.
@mfp20, I've looked into the changes provided by @dkbay some few months ago just to estimate effort needed to integrate those changes into Orca. There are some actual porting needed (not just a changes merging) and while I'm actually interested in making it work, but I'm not sure when I'll get a chance to work on it.
As for the changes itself, they are not sophisticated as you might think they are: treat them as "advanced ironing" which makes smooth top layer on non-horizontal surfaces.
I see there is significant interest in this! I have tried and failed to gather emails for the interested users through github. Please send me a mail through my github profile so I can invite you to a platform where we can better communicate on this.
About me, "soon or later" ... it's more "later" than "sooner". I appreciate your coordination effort but I simply can't now. I've written a dumb asm firmware for my old MKS GEN L boards (atmega2560) to make them SPI peripherals for a Klipper'ed RPi Pico master writing diretly to/from the atmega's registers and ram). Currently I'm debugging the firmware, then I'll have to tackle its driver for Klipper. Then the kinematics in the python host code as the printer has a somewhat weird topology: XY is made of parallel scara (as I wanted to avoid belts), and the 2 scara motors are mounted on an X linear rail with screws; and it's an IDEX... 2 XY heads. I'm comfortable with klipper code, but still it's a lot of learning, validating in practice the hw choices, and coding work before even thinking to address the non-planar feature (ie: the pan&tilt bed). But I'd be happy if there's a bus leaving now and I'll be able to hop on it at later stage.
@mfp20, I've looked into the changes provided by @dkbay some few months ago just to estimate effort needed to integrate those changes into Orca. There are some actual porting needed (not just a changes merging) and while I'm actually interested in making it work, but I'm not sure when I'll get a chance to work on it.
Usually projects with a long standing history and a few forks along the way, have pretty messy code. If this is the case, adding simple features is ok; adding some complex feature requires deep re-hauling. I haven't even looked at the code yet but ... maybe not: the first time I've seen the non-planar applied to fdm printers it was a post-slicing python script ... some kind of filter (parsing and modifying the g-code). And usually geometry problems can be solved by just applying more geometry, so adding a post-processing filter capability to the slicer (ie: the slicer makes the gcode, and then automatically runs the user's script) might be enough for anyone to add their own filters (included the non-planar transform). In this case the work on the slicer is minimal.
As for the changes itself, they are not sophisticated as you might think they are: treat them as "advanced ironing" which makes smooth top layer on non-horizontal surfaces.
Hold on. There are already plenty python scripts for "fuzzyskin" and similar cosmetic g-code mods; they might not be integrated in any slicer, because they might be good for one firmware only (ie: a peculiar subset of gcodes) or nobody took the disturb to integrate them in the slicer. What we are totally missing instead, in the open space, it is a slicer able to exploit the advanced kinematic of a pan&tilt bed and/or rotating (and permanently 45-tilted) nozzle in order to generate full non-planar paths. That's the target...
Again, I didn't hand-on yet so my current view could be naive. Correct my mistakes if I am wrong, please.
You are correct.
I'd like to note that I am referring specifically to the set of changes/functionality mentioned in the first comment here. Those changes are most users with mass-produced 3d printers will benefit from.
Now I see that you are talking about full-featured non-platar slicing for purpose-built printers.
I'd like to note that I am referring specifically to the set of changes/functionality mentioned in the first comment here. Those changes are most users with mass-produced 3d printers will benefit from.
The initial poster ( @Dmeerev ), like many others expressing interest on the non-planar subject, gave for granted too many things: not all the printers are created ... 3-axis cartesian. But he wrote "All" at "Which printers will be beneficial to this feature?" question. As well as he named some infill paterns: circular, lightning, ... that's structural, not skin-only. Must a single slicer accomodate them all? Can a "universal slicer" be?
If you answer yes to both this questions, well, this is a major re-hauling and ... because I have no idea of all the issues involved (yet) ... honestly I'd go for a port of the initial slic3r perl code to python, and embed the python vm into a Qt GUI (ie: crossplatform GUI) in order for the resulting slicer app to be able to run the python code. At that point you don't have a non-planar slicer, but you have a very flexible development platform able to do standard slicing same as before, as a starting point. And any guy with a week-end long spare time can deliver working improvements without the need to compile code; it opens up the way for an horde of people able and willing to spend little time. It looks to me the non-planar feature it is stuck here: a lot of interest, and a lot of people with little time to commit. This kind of evolution unleashes this potential. If you look at Kicad and Blender, the python scripting capabilities are deeply rooted in the apps... they are gigantic apps, ofc, so probably not the best examples to look at for inspiration but ... they are awesome development platforms that work good for a wide range of cases... almost universal.
Now I see that you are talking about full-featured non-platar slicing for purpose-built printers.
No, forget for a moment my peculiar printer: it's custom but not strictly needed for non-planar. A common cartesian printer can do it all as long as the depth in layers is minimal and the paths are short; you get a slow print, with minimum layer intertwining, but it may be enough to increase part strength and beautify the surfaces. Some of these results are already in slicers with fuzzyskin-like features. Then there is a somewhat minimal-improvement using conical nozzles: it's an hw mod, ofc, but it's just a matter of buying and changing a nozzle to any standard 3-axis cartesian printer.
After that there are major issues: many makers are fighting with a simple arc gcode still :) And curved paths are the thing needed both for part strenght and beautyful surfaces. Deltas are closer to succeed in this, but still, not all of them can do good curves; and not on all the build area. Some are ok about XY curves, some others do a better job on Z curves. A delta can do it easy, a cartesian must approximate (more than a delta). So we entered the hw mods arena. In this arena almost any actual maker can apply a small mod to the printhead, in order to have a rotating 45-tilted nozzle; in most cases it's just a matter of designing a custom bracket for the extruder/hotend. And probably reduce the speed in order to accomodate the increased mass (of an extra stepper on the toolhead, for rotating the 45-tilted nozzle). But still, an hw mod.
At this point we get to the purpose-built printers. And here there are no defaults on the road. All we know is that a tilt&pan bed might be the go-to solution. So core-xy printers only (and deltas). In the first iteration of my custom printer I bought some hollow-shaft steppers, and used those to pan&tilt the slinging bed ... once testing the motion, I figured out why it was a veeery bad design ... I'm an IT guy, not a mechanical engineer; so I approach mechanics by trial and error. Long story short: after a few attempts, some of which with (too) complex joints, and almost chopping off one of my fingers, I abbandoned the bed slinging and at the 6th iteration it is "an high-temp, idex, core-xy, without belts, with screws and scaras"; and it's cool. Well, it's an high temp printer. But it's Cool anyway. I don't know if the design is valid but it looks promising.
And from here, we can go to way more complex robots but ... probably ... a rotating 45-tilted nozzle printer, and a tilt&pan bed printer are the 2 only platforms that we should take into consideration when talking about the slicer. Because they are the only 2 cheap platforms that any user can get or already have once applied a small hw mod to one of his simple 3-axis cartesian printers, delta, or core-xy. And both of them can deliver the part out of full non-planar slicing.
They are not "All" printers as requested in the feature request above on this thread, but very close to it.
https://github.com/RotBotSlicer/Transform
From the link above about the 45-tilted nozzle link.
If I understand correctly, it's a set of 2 python scripts: one to transform the STL, and one to transform the gcode. More geometry :) You can use one OR the other one, in order to transform the stl OR the gcode. Resulting in a gcode exploting the 45-tilted rotatory nozzle. So, one of the 2 hw cases I wrote above is well served. And probably with minor changes can serve the tilt&pan bed case as well.
This can be added easily to current slicer. It will have to compute the transform before OR after the slicing, so it may take some more time but ... time difference in computation should be negligible.
@mfp20 I imagine this as a long term effort, which would also mean the work should be separated into smaller steps whenever possible. It's to take into consideration that people use their valuable free time for this! I'd like to encourage you to hit me up on email and join the channel, if only as a spectator for now.
Really excited to see if we can get this even in a very limited form sometime. Just to be able to see experimental support of anything of the likes to smooth a subtly rounded top surface on a box would be incredible for print quality.
EDIT; I wonder if this feature could be divided into discrete separate steps somethign like "Non-Planar Ironing" would be the first milestone as this seems to be the simplest viable approach integration wise from what i have read?
FWIW, the changes in PrusaSlicer for the NonPlanar functionality can be found here:
https://github.com/EiNSTeiN-/PrusaSlicer/commit/22c42b9844bf54728be54fd029d06a20fddd01bd
I've attached a diff of those changes, as well as the included test STL file (should go in /tests/data/nonplanar/).
nonplanar_PrusaSlicer.diff.gz wave_cube.stl.gz
Note that this patch won't apply properly to OrcaSlicer as-is. There are three referenced files that are missing:
src/libslic3r/ExtrusionRole.cpp[for adding hooks for the settings]src/libslic3r/ExtrusionRole.hpp[for adding hooks for the settings]src/libslic3r/SupportSpotsGenerator.cpp[for setting flow rate to the same as the SolidInfill]
And numerous failed hunks. Here's the full output of attempting a dry run of the patch:
$ patch --dry-run -p1 < nonplanar_PrusaSlicer.diff
checking file src/libslic3r/CMakeLists.txt
Hunk #1 FAILED at 221.
1 out of 1 hunk FAILED
checking file src/libslic3r/ExPolygon.cpp
Hunk #1 FAILED at 418.
1 out of 1 hunk FAILED
checking file src/libslic3r/ExtrusionEntity.hpp
Hunk #1 succeeded at 9 (offset -1 lines).
Hunk #2 succeeded at 161 with fuzz 2 (offset 92 lines).
Hunk #3 succeeded at 345 with fuzz 1 (offset 219 lines).
checking file src/libslic3r/ExtrusionEntityCollection.cpp
Hunk #2 succeeded at 155 (offset 1 line).
checking file src/libslic3r/ExtrusionEntityCollection.hpp
Hunk #1 succeeded at 139 (offset 15 lines).
can't find file to patch at input line 109
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/src/libslic3r/ExtrusionRole.cpp b/src/libslic3r/ExtrusionRole.cpp
|index a7ec31949..6d9484a3d 100644
|--- a/src/libslic3r/ExtrusionRole.cpp
|+++ b/src/libslic3r/ExtrusionRole.cpp
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
3 out of 3 hunks ignored
can't find file to patch at input line 146
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/src/libslic3r/ExtrusionRole.hpp b/src/libslic3r/ExtrusionRole.hpp
|index 986c139a2..04f7d94e2 100644
|--- a/src/libslic3r/ExtrusionRole.hpp
|+++ b/src/libslic3r/ExtrusionRole.hpp
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
4 out of 4 hunks ignored
checking file src/libslic3r/Fill/Fill.cpp
Hunk #2 FAILED at 146.
Hunk #3 FAILED at 156.
Hunk #4 succeeded at 780 (offset 526 lines).
Hunk #5 succeeded at 809 (offset 526 lines).
Hunk #6 FAILED at 311.
Hunk #7 FAILED at 451.
Hunk #8 succeeded at 1320 with fuzz 2 (offset 799 lines).
Hunk #9 FAILED at 565.
Hunk #10 FAILED at 857.
Hunk #11 FAILED at 865.
7 out of 11 hunks FAILED
checking file src/libslic3r/GCode.cpp
Hunk #1 FAILED at 2459.
Hunk #2 FAILED at 2472.
Hunk #3 FAILED at 2491.
Hunk #4 FAILED at 2510.
Hunk #5 FAILED at 2520.
Hunk #6 FAILED at 2535.
Hunk #7 FAILED at 2558.
Hunk #8 FAILED at 2749.
Hunk #9 succeeded at 4905 with fuzz 2 (offset 2112 lines).
Hunk #10 FAILED at 2948.
Hunk #11 FAILED at 2981.
Hunk #12 FAILED at 3123.
Hunk #13 FAILED at 3143.
Hunk #14 FAILED at 3191.
Hunk #15 FAILED at 3237.
Hunk #16 FAILED at 3248.
Hunk #17 FAILED at 3292.
Hunk #18 FAILED at 3426.
Hunk #19 succeeded at 6625 with fuzz 1 (offset 3185 lines).
17 out of 19 hunks FAILED
checking file src/libslic3r/GCode.hpp
Hunk #1 FAILED at 166.
Hunk #2 FAILED at 326.
2 out of 2 hunks FAILED
checking file src/libslic3r/GCodeWriter.cpp
Hunk #1 FAILED at 274.
Hunk #2 FAILED at 360.
2 out of 2 hunks FAILED
checking file src/libslic3r/GCodeWriter.hpp
Hunk #1 FAILED at 62.
1 out of 1 hunk FAILED
checking file src/libslic3r/Geometry.cpp
Hunk #1 succeeded at 885 with fuzz 1 (offset 139 lines).
checking file src/libslic3r/Geometry.hpp
Hunk #1 succeeded at 562 with fuzz 2 (offset 33 lines).
checking file src/libslic3r/Layer.cpp
Hunk #1 FAILED at 54.
Hunk #2 succeeded at 271 (offset -795 lines).
Hunk #3 succeeded at 363 with fuzz 1 (offset -729 lines).
1 out of 3 hunks FAILED
checking file src/libslic3r/Layer.hpp
Hunk #1 FAILED at 7.
Hunk #2 FAILED at 132.
Hunk #3 succeeded at 104 with fuzz 2 (offset -63 lines).
Hunk #4 FAILED at 239.
Hunk #5 succeeded at 205 (offset -188 lines).
3 out of 5 hunks FAILED
checking file src/libslic3r/LayerRegion.cpp
Hunk #1 FAILED at 463.
Hunk #2 FAILED at 480.
Hunk #3 succeeded at 974 (offset 98 lines).
Hunk #4 succeeded at 1001 with fuzz 1 (offset 98 lines).
2 out of 4 hunks FAILED
checking file src/libslic3r/MultiPoint.cpp
Hunk #1 FAILED at 103.
1 out of 1 hunk FAILED
checking file src/libslic3r/MultiPoint.hpp
Hunk #1 FAILED at 81.
1 out of 1 hunk FAILED
checking file src/libslic3r/NonplanarFacet.cpp
checking file src/libslic3r/NonplanarFacet.hpp
checking file src/libslic3r/NonplanarSurface.cpp
checking file src/libslic3r/NonplanarSurface.hpp
checking file src/libslic3r/Point.hpp
Hunk #1 FAILED at 159.
1 out of 1 hunk FAILED
checking file src/libslic3r/Polygon.cpp
Hunk #1 FAILED at 402.
1 out of 1 hunk FAILED
checking file src/libslic3r/Polyline.cpp
Hunk #2 FAILED at 51.
Hunk #3 succeeded at 137 (offset 35 lines).
Hunk #4 succeeded at 608 with fuzz 1 (offset 359 lines).
Hunk #5 FAILED at 275.
Hunk #6 FAILED at 288.
Hunk #7 succeeded at 654 (offset 318 lines).
3 out of 7 hunks FAILED
checking file src/libslic3r/Polyline.hpp
Hunk #1 succeeded at 295 (offset 61 lines).
checking file src/libslic3r/Preset.cpp
Hunk #1 FAILED at 432.
1 out of 1 hunk FAILED
checking file src/libslic3r/Print.hpp
Hunk #1 FAILED at 17.
Hunk #2 FAILED at 67.
Hunk #3 succeeded at 335 with fuzz 2 (offset 71 lines).
Hunk #4 FAILED at 380.
Hunk #5 succeeded at 535 with fuzz 1 (offset 119 lines).
3 out of 5 hunks FAILED
checking file src/libslic3r/PrintConfig.cpp
Hunk #1 FAILED at 1369.
1 out of 1 hunk FAILED
checking file src/libslic3r/PrintConfig.hpp
Hunk #1 FAILED at 562.
1 out of 1 hunk FAILED
checking file src/libslic3r/PrintObject.cpp
Hunk #1 FAILED at 33.
Hunk #2 succeeded at 29 with fuzz 1 (offset -24 lines).
Hunk #3 FAILED at 179.
Hunk #4 FAILED at 276.
Hunk #5 succeeded at 557 (offset 122 lines).
Hunk #6 succeeded at 997 with fuzz 2 (offset 201 lines).
Hunk #7 succeeded at 1265 (offset 355 lines).
Hunk #8 succeeded at 1333 with fuzz 2 (offset 368 lines).
Hunk #9 FAILED at 988.
Hunk #10 FAILED at 1013.
Hunk #11 FAILED at 1025.
Hunk #12 FAILED at 1058.
Hunk #13 FAILED at 1074.
Hunk #14 succeeded at 1602 (offset 472 lines).
Hunk #15 succeeded at 1985 with fuzz 2 (offset 474 lines).
Hunk #16 FAILED at 1528.
Hunk #17 succeeded at 2064 with fuzz 2 (offset 478 lines).
Hunk #18 FAILED at 1594.
Hunk #19 FAILED at 1775.
Hunk #20 FAILED at 1783.
Hunk #21 FAILED at 1791.
Hunk #22 succeeded at 2339 (offset 489 lines).
Hunk #23 FAILED at 1874.
Hunk #24 FAILED at 1979.
15 out of 24 hunks FAILED
checking file src/libslic3r/PrintObjectSlice.cpp
Hunk #1 succeeded at 7 with fuzz 2 (offset 2 lines).
Hunk #2 FAILED at 519.
Hunk #3 FAILED at 542.
Hunk #4 FAILED at 709.
Hunk #5 FAILED at 741.
Hunk #6 FAILED at 803.
Hunk #7 succeeded at 1362 with fuzz 1 (offset 539 lines).
5 out of 7 hunks FAILED
can't find file to patch at input line 2760
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/src/libslic3r/SupportSpotsGenerator.cpp b/src/libslic3r/SupportSpotsGenerator.cpp
|index 8936830f2..b0f2d0d34 100644
|--- a/src/libslic3r/SupportSpotsGenerator.cpp
|+++ b/src/libslic3r/SupportSpotsGenerator.cpp
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
1 out of 1 hunk ignored
checking file src/libslic3r/Surface.cpp
checking file src/libslic3r/Surface.hpp
Hunk #1 succeeded at 28 (offset 4 lines).
Hunk #2 FAILED at 41.
Hunk #3 succeeded at 88 (offset 17 lines).
Hunk #4 succeeded at 100 (offset 17 lines).
Hunk #5 FAILED at 92.
Hunk #6 FAILED at 234.
Hunk #7 succeeded at 303 (offset 19 lines).
3 out of 7 hunks FAILED
checking file src/libslic3r/SurfaceCollection.hpp
Hunk #1 succeeded at 74 (offset 6 lines).
checking file src/slic3r/GUI/GCodeViewer.cpp
Hunk #1 FAILED at 569.
1 out of 1 hunk FAILED
checking file src/slic3r/GUI/Tab.cpp
Hunk #1 FAILED at 1459.
1 out of 1 hunk FAILED
https://github.com/teachingtechYT/PrusaSlicer
Tried it yesterday, and this technique is just incredible! Especially when combined with ironing (actually custom ironong with the top layer line width = 0.2, ironing is broken in that fork):
https://github.com/user-attachments/assets/3d9da419-ecf3-4f3c-bffd-6c6c73c86866
