Open thierryzoller opened 4 years ago
Some more info to consider: https://community.octoprint.org/t/new-plugin-anti-stutter-need-testers/18077
There is a plugin for octoprint in the making to convert g1 to g2/g3 post-slicing.
SuperSlicer won't be able to do much more than this when it runs off STL files. Only when slicing STEP files it can do better.
problem is with step-import, is that i need to do offset, difference, union, intersection on polygons. Currently, using clipper, it's possible for a vector of points. If you add bezier curve, it may need a rewrite, be slower, etc...
Let's also keep in mind G5 bezier curves. Maybe G5 bezier curves do not need to be implemented at the same time, but they should be kept in mind so that any STEP file or G2/3 arc code doesn't need to be completely refactored to accommodate future implementation of G5 bezier curves.
See Marlin implementation documentation: https://marlinfw.org/docs/gcode/G005.html
One idea also would be (if that make sense) to use ARC support for Infill (example, gyroid)
SuperSlicer won't be able to do much more than this when it runs off STL files. Only when slicing STEP files it can do better.
Superslicer could use this for infill, thus not only postprocessing.
Personally I am not interested in ARC support because of judder, the recent changes to marlin allowing JD but disabling certain functions solved the issue. I am not getting really round shapes, and there is tons and tons of overhead printing straight lines. Maybe if a slicer could also support another fileformat than stl that would make arc more powerfull as well.
the gyroid is computed by resolving an equation for each point (step). outputing curve/bezier for gyroid means redoing it entirely, from the math formula (unless you use the post-processing script mentioned above).
The maybe only "not extremely hard" possibility is for archimedean curves.... not worth it.
for doing offset with bezier... https://stackoverflow.com/questions/4148831/how-to-offset-a-cubic-bezier-curve seems hard or slow. But step-> polygon with points near enough -> curve seems to be much quicker to do, simpler to code and won't create huge difference. If we can verify that any deviation is within a set threshold, it should be enough.
I am curious if arc support could be added by calculating the arc based on the point sections or take the inside curve of the line sections. I know 3d systems did something like this with there sla software and it made some improvements.
Edit: the way they did the calculation was to take the point segments and form a triangle with the third point at the center of the line segment. Then they took the center point of that triangle to find the arc average.
Arc welder can be used stand alone by compiling an executable. You can use it to post process your file. The octoprint plugin is just a gui for that executable.
And the slicer support will be the same. It's just more convenient.
you can integrate yourself by putting the command in the post-processing field. I don't know the details.
Maybe add STEP and CSG support?
@uis246 please... did you read the conversation, or you're a bot?
I mean STEP and CSG formats support cylinders and spheres, which makes arc generation possible. CSG is simplified OpenSCAD export format.
And still, you can't slice & offset them.
something new about this? .... i think is a great idea !!!!!
Overall explanation: https://bernhardkubicek.soup.io/post/191097625/If-you-have-a-path-of-segments Slic3r (alpha) implementation code :https://github.com/TheThirdOne/Slic3r/commits/arc-fitting Academia: https://arxiv.org/pdf/1808.01831.pdf
History
Quality difference: https://web.archive.org/web/20160826184103/http://www.cosineadditive.com/blog/2015/7/1/g2-g3-vector-based-printing
Post Processing