Unexpected seam in vase mode #2841
Comments
|
This is due to the way PrusaSlicer (and the upstream slic3r) calculate the spiralized path. It is a simple hack, it just takes a horizontal slice, which it stretches along the Z axis. Therefore the two successive spiralized slices will show such a stepping artifact, if the two successive slices are not exactly the same. There is a way to simulate the spiralized slice by interpolating the contour between the two successive slices, but it is a little bit involved to do right. |
|
Thanks for the background information! I guess since it's not a bug but rather a side effect of the current implementation, should I close this issue? |
|
Please keep it open. We will try to implement interpolation between two
successive contours one day.
so 8. 2. 2020 v 21:05 odesílatel suromark <notifications@github.com> napsal:
… Thanks for the background information! I guess since it's not a bug but
rather a side effect of the current implementation, should I close this
issue?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2841?email_source=notifications&email_token=ABMPSI2WVAW3Z6LEYND2KJTRB4GBXA5CNFSM4ISGY43KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELF2NBY#issuecomment-583771783>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABMPSI7SY5BIMXROH2SVUQLRB4GBXANCNFSM4ISGY43A>
.
|
|
I leave a comment here to confirm that this issue is still present with the version 2.2.0.
|
|
This is still an issue in 2.3.1
|
|
This is still and issue and kind of negates the whole point of vasemode |
|
Hello. I've noticed this too on some of my prints and I was wondering how I would be going about getting rid of it. I've come up with something that may or may not be what you call interpolation, so I share the idea here in case it is simpler to implement (but it is in a way a hack too).
Now that's probably still not correct (because moving the point may make the path different length, which should then lead to changing Z again, etc…) but my guess is this'll be somewhat better than now and if the move would be by significant amount, it would be possible to do few more iterations. I suspect there would be some corner cases (eg. what if the point is just not there in the different Z because an edge ended)… but maybe it would work to just fall back to not doing the adjustment in such case. |
|
Its a horrible hack and has more edge cases then a case of Gillette razors, but it does work. I've actually had really good luck using a shelled version of the vase STL and slicing the bottom in PS with the infill and perimeter settings I want and then transitioning it to the spiralized version after about 2mm. 3 perimeters, concentric on the first layer and you get really good coverage for a water tight vase. |
|
Looks like it's still in PrusaSlicer 2.4.0. |
|
Would be great to improve the transition path. The jog is really obvious on conical surfaces. (Prusa Slicer 2.4.2) Let's make Vase mode something we can be proud of.
|
|
Still in PrusaSlicer 2.5.0 alpha 2 confirmed. And still very visible. |
|
The underlying issue is how the slicing is done. @bubnikv alluded to it in his message. Its sliced horizontally and then each layer is pulled in the z axis. It has to make a correction at the end of each loop to get to the start of the next. Printing larger layer heights in combination with more angular shapes accentuates it. The reason its showing up for me is I'm using a 1.8mm nozzle and that width allows for much more angular shapes to be printed in vase mode due to the overlap being available. The width allows 45 deg+ angles in vase mode, which makes for really nice, fast printing parts. @bubnikv suggested interpolating or some other smoothing function between the points, but that'll give dimensional inaccuracies and I think still some artifacting. I put together a POC slicer (SpiralSlicer) that uses a helix at the center of the object. From the helix you cast a ray out from the center point through the helix at any given height and find the intersection with the STL wall. It's iterative (more points more resolution, more time) and it has caveats like being unable to handle loop backs in the model . For instance this vase wouldn't work as a ray would pass through multiple walls. I believe there are ways to fix this but I haven't looked at it enough. I don't have the C skills to implement this myself in prusaslicer and as far as I know there is no plugin framework in Prusaslicer that would let me tack it on in a language I know. Every slicer I've looked at calculates vase mode in the same way so its not just a Prusaslicer thing. Given the availability of large nozzles I'd assert that vase mode should be given a good look at again. I've also experimented with using vase mode only for specific parts of the a print. For instance this vase, if we where able to print the bottom and top portions in vase mode switching to regular for the handle areas, would print faster and better. I have in the past sliced it both ways then stitched the gcode together from multiple files, but its a pita. All this glosses over the UI complexity it would add. Choosing a slicing engine that wouldn't work well for all objects, controlling the point density per revolution, choosing which portions to print vase vs regular. Difference in handling of a solid object (vase that isn't hollow) vs hollowed out, etc. |
|
Three years since the original issue was reported and still no progress? This is frustrating. Vase mode is significantly less useful when we can't be sure of a continuous smooth transition. |
|
Just ran across this issue myself. Thought it had to do with extraneous gcode between layers but it persisted even after I removed the code using a post-processing script. The way the interpolation is done (interpolate Z but not XY) will result in in an XY jump during a layer change on an overhang. One way to mitigate this is to over-slice (do, say, 100x the number of slices required) then sample interpolated XYZ coordinates from the intermediate slices based on distance traveled. The problem with this is that there's no guarantee that all the intermediate slices will have corresponding vertices or even the same number of vertices. This method would also significantly increase the slicing time. Another possibility is to pair up corresponding vertices on adjacent layers (again, no guarantees they do correspond), and interpolate along a line joining each pair. This would require less processing power than the over-slicing method, but still has the issue of matching up corresponding points between layers. Here's an example of the corresponding points issue... How do you match up the points? Can you come up with an algorithm to insert 15 additional points in the second one based on the total distance traveled, interpolating the XY coordinates for the inserted points? That might work but I can see it getting very messy under some conditions. But let's say you've got that far, can you then just pair up each point of the first layer with its corresponding one on the second layer, draw a line between the two, then calculate the XYZ coordinates of the interpolated point based on accumulated distance traveled around the perimeter? Again, it might work but it could also introduce other unwanted artifacts. |
|
I wrote a little post-processing app that attempts to do what I've described above. You can see the before/after in the attached image. Under the right circumstances, it works fairly well. It'd work better if the layer changes were aligned vertically. Not sure why they aren't. It's written in Java but could probably be ported to C++ fairly easily. I think this could be incorporated into the slicer's spiral vase code but, at a minimum, the slicer would need to align the layer changes to make the interpolation work better. I've also attached the JAR file and the Java source. To use the JAR file as a post-processing script, use something along the lines of the following:
OBVIOUS WARNING: This has not been fully tested. Don't attempt to print the generated gcode. It's entirely possible it could damage your printer. I'd recommend using it for comparing before/after in gcode viewer only. |
|
Ported the post-processing script to Python, and added a few refinements. I also grabbed the Prusaslicer source and stepped through the spiral vase code. And, yeah, I can see why something like this hasn't been implemented yet. The spiraling is implemented via a layer filter. The filter processes one layer at a time, with no info about the next or previous layer, meaning it can't interpolate the XY coordinates based on the adjacent layer. It'd be a major headache to retool the slicer to do so. |
|
I ran into this same issue as well. A seemingly simple "vase" shape with a taper near the bottom and the top sliced with a strange wrinkle down the side. A redditor directed me to this thread, which tells the whole story. Pretty disappointing! Thanks to the python script linked above by @degroof (good timing!) I was able to print the part how it should've looked from Slicer with no wrinkle. Great work on that, and to @degroof as well. Suggested improvements to that script - the M73 codes are removed by the script, so print progress doesn't get updated on the printer's display. Also, since there's no way to interpolate for the top layer, it ends up looking a bit off on my model, which ends in a taper. It might be better to just not print that layer at all. I'll probably delete it manually in the future. |
Yeah. It's definitely not ready for primetime. It also removes color changes, for example. Glad it worked for you but it's not even alpha code. I'd recommend, if you're going to use it as-is, opening the file in gcode viewer before printing, just to verify it doesn't do anything unexected. |
Strongly agree. I did a side-by-side of the old and new G-code with Beyond Compare and things looked pretty OK. As expected, z coordinates didn't change and the X/Y's varied slightly. I guess I'll keep using this until Prusa gets their act together. |
|
Still a problem in 2.5 across PS and SS. Above is a file I designed and use. It still functions, but does have an ugly visible seam which does play a bit with the seal of the threads. Down below is a severe example on a sphere that shows how this is still very much an issue.
I even talked to prusa support where they said they were "not aware" of this issue, even though its been documented for multiple years now, and does seriously alias lots of prints. I hope they get this solved so I am not forced to use cura for my vase mode prints. |
|
1Crystal_1h1m_0.20mm_240C_PLA_CR10V2_withlayers.txt Sadly @degroof 's python program does not catch the issue. Here are two examples in the same print. Here is the top most issue |
|
Same here, unfortunately, post-processing scripts don't work for my models. |
|
I keep hoping someone will figure a way to fix this. Doh!! The post script didn't fix the issue for me either. The two things I wanted to print via vase mode both get bit by the bug. |
|
Turning off "Avoid crossing perimeters" works for me. but what's weird is in vase mode, it still generates seams: but then it's gone when using 0.6 settings: |
|
Turning off "Avoid Crossing Perimeters" didn't do anything for me. The shift at "layer changes" is still quite ugly and I don't see a visual difference. Turning on "show seams" didn't display any seems. I'm using a 0.4mm nozzle. This problem is going to require a fundamental change in the slicing algorithm in vase mode. I wonder if the algorithm could be harvested from another open-source slicer like Cura? |
Yes, I found that sometimes the slicer includes travel moves to the exact last position (basically a no-op) and they don't have extrusion. SpiralVase leaves those alone, but clearly we shouldn't! Working on a fix now as well as some new goodies :) Stay tuned. |
|
@wekii Fixes have just been pushed, a new binary should be ready for you once the pipeline makes one. |
|
I haven't read the code from @degroof or @andrewboktor, but here's some code that works for me: https://github.com/zxcv-org/gcode-respiralizer (YMMV; BEWARE; NOT MY FAULT IF YOU BREAK YOUR PRINTER) |
Wow, it seems that the problem is fixed now. I don't see any bugs in the preview pane of OrcaSlicer 👏 Now, I have to make some real test and print this model again 😁 Thank you so much. |
|
https://github.com/zxcv-org/gcode-respiralizer Here's an example: Horizontal step present (sliced with OrcaSlicer exe from the pull request linked above by @andrewboktor): Horizontal step avoided: please feel free to grab any useful ideas from gcode-respiralizer; that's the main point of it |
Can you elaborate a bit how this problem is detected and avoided? |
"elaborate" --> wall of text :-) Detection: Removal/splicing: Detection (roughly speaking): For a segment, notice when the set of up to two closest fine perimeters for the start point has no overlap with the set of up to two closest fine perimeters for the second point. Notice also that there's a point within the segment that isn't close to any other segment, at any point along the segment. See code for more comments/precision/detail. Removal/splicing (roughly speaking): For the start point, note the closest fine perimeter. Look forward along the coarse path for a point anywhere within the coarse path that's close enough to the noted fine perimeter (any point within that perimeter) - these look for low segment-segment distance, and care about finding a pair of points that are close between the two paths, even if that pair of points is mid-segment for both paths. Keep looking a little beyond the first good-enough distance to try to find a super-close distance. Then splice in the noted fine perimeter in place of the portion of the coarse perimeter that did the jump on/off the horizontal step. See code for more comments/precision/detail. The spliced-in path is run through the force_point function, so that avoids any obvious splice in the output. If any trouble is hit while trying to find a place to end the splice, the splice is aborted and the unmodified coarse path is sent through force_point like usual. The splice does mean that the output is, in some sense, less conformant to the original geometry, since it basically sticks to path A even though path B has become "more correct" in some sense based only on z value, though it depends on how you weight the "cost" of the single extrusion through the air all by itself - the splicing assumes that's fairly high cost essentially. The splicing is easy to disable if the goal is horizontal jumping when it's "time to jump". The splicing doesn't go back to the fork in the road to try both paths and see which ends up closer to the original geometry (probably unnecessary, but technically would be slightly better). The main reason I got bothered enough about these mid-air extrusions to write the splicing stuff is that it's not always easy to snip them out cleanly - they tend to try to bridge through mid-air and turn a sharp corner while still bridging, which won't work well, and it's extra work per print. So it's nice if they're just gone instead. Other notes: The code intentionally keeps the filter (in a signal processing sense) super narrow, just using up to two fine layer perimeters and terping between the two closest points anywhere on those perimeters (mid-segment allowed). If the two found points are both in the same z direction, only the closest is used, to allow for "boundary conditions" like the top of the model or a "top layer" mid-way up the model where the next layer up takes a shortcut. The code does it this way because a wider / more continuous / less decision-y filter seemed like it would not necessarily deal well with boundary conditions - even reflecting perimeters below to "appear" above as well when there are no close perimeters above, seemed like it could just end up being worse than dropping back to closest fine perimeter in such cases. I tried to comment the code with "strategy" comments to hopefully make it plausible to read - hopefully those will be of some use; I tried to mention every place where the code is ignoring a potential problem or assuming everything will be fine or similar. I should also mention that gcode-respiralizer ignores and passes through (roughly speaking) all non-extruding gcode, other than the nop "moves" that you also hit, and also passes through extruding gcode that doesn't change Z during the extrude, so that allows the intro line and first few bottom layers to print normally, before respiralizing the spiral portion of the print. I've tried gcode-respiralizer on a few different models now - so far I haven't hit any issues. It gets rid of the vase mode seam and also the horizontal jumps, and the surface quality seems on par with the non-vase-"seam" part of the slicer's output, with the same good quality where the vase "seam" used to be. The one downside currently is the slicer takes a little while to generate the "fine slicing" used as reference (though the z height of this reference doesn't necessarily have to be ultra low), and gcode-respiralizer takes a little while to load the "fine slicing" (again, using a layer height for the fine slicing that's not quite as small would make that go faster). It's not going to win any speed benchmarks, but it does use KdTree(s) internally to find close stuff faster, and to scale reasonably well to larger models. So it's not completely awful re. speed. For model designers who use horizontal steps in advanced vase mode designs (like in openscad): If your model has periodic (in z) horizontal steps hit at the same layer height phase each occurrence in z (same phase == same step height mod layer height), that forces the phase of the splicing described above to hit at the same "clock" location around the model each time, which could still result in a perceptible difference on one side of the model if someone looks closely enough. Model designers may wish to consider this in setting the height of horizontal steps, to either imperceptibly randomize the layer height phase of the steps, or spiral the layer height phase around the model, or whatever works best for your model. Probably makes sense to consider how the horizontal step layer height phase works for both 0.3 and 0.2 layer heights. Randomizing the step heights by +/- 0.15mm could work quite nicely for some models. With legacy vase mode slicing, the horizontal step jump extrusions would always be at the vase mode seam (wherever that ends up; can vary on the way up the model). With newer vase slicing, the horizontal step jump extrusions would be in a vertical line only if the model has the same step height mod layer height each z occurrence of steps. With gcode-spiralizer the splicing to avoid the single extrusions would be in a vertical line only if the model has the same step height mod layer height for every z occurrence of steps (and hopefully mostly invisible despite being lined up vertically, but if someone looks closely enough...). Fwiw, spiraling the step height mod layer height phase around the model is something end users can do by just stretching/squishing the model in z by as many layer heights as you want step-spirals around the model, if I'm still making any sense to anyone else. Anyway, I hope gcode-respiralizer is useful, whether to process gcode or as a source of any ideas. |
|
The PR was merged in Orca a few days ago |
|
Dear community, |
|
Same patch, including some minor fixes from orca. |
|
Here is patched Prusa with default 200% max smoothing: It looks better (still not perfect) with increased value: |
|
Since this is the improvement we have after 4.5 years maybe we could get it put into PrusaSlicer? |
|
@andrewboktor are these
options really needed? Why not turn it always on and always smooth (as if Max XY were infinite)? |
Because some vase mode prints are designed for on one layer being one shape then the next layer being a completely different shape and rely on clever bridging to make it printable. If you smooth those then you end up completely breaking the intention of the design. |
Merge Full re-write of spiral vase SoftFever/OrcaSlicer#3091
|
Been waiting for this for a long time, so happy to see it implemented. Is there a way to test it? Is there a compiled version anywhere to download? I tried manually adding your changes to my sources, but I must have messed something up, because it isnt doing what it should (hollow walls etc..). I am sure I made a mistake. |
Why "manually"? Create pull request for yourself, or just use git. Try also my PR. |
Sorry, you are right. My attempt was stupid. As soon as this setting is disabled ( -> working with absolute E distances) the generated G-code is really buggy. And here is the very same model where the only change was activating "use relative E distances": Is this behavior expected/known? |
Obviously no)) Original Orca code has the same issue:
You may open but there, but what is the reason to use absolute E distance? |
|
No specific reason, It's just the default setting for my machine and I was wondering why I had a weird looking result and it turned out to be the relative E setting. I changed it and now your implementation works perfectly fine. I have another question: For parts that are "flattening out" towards the top, I am received bigger gaps with smooth spiral 200% smoothing: It becomes better if I lower the smoothing value, but I end up receiving the Z-seam of the regular vase mode: both results are not perfect. I am coming from Simplify3D which, in general, doesnt perform as good as slic3r-based slicers, but has a very well working vasemode. Here is the same part with the same settings (line width etc..) in S3D: No gaps at the top and also no Z-seam: Do you have any idea how that happens or how it could be optimzed? |
It's not my implementation. It's port from Orca, and even not my one. I just applied patch and created PR, so I have no cue how it works. |
|
I wrote that code! |
|
Fixed in PrusaSlicer 2.7.3-alpha1, thanks to @andrewboktor for the implementation. Closing. |
The spiral vase mode implmentation is causing faulty gcodes if "use relative E distances" is enabled in printer settings (see my post from Feb 17th above). |
|
It seems like the option to configure this (on/off, max xy) has been removed in Prusa's release? Would be curious to know why the Prusa devs decided that was best? |
Disabled. |
and others
Version
2.1.0-beta2+
Operating system type + version
MacOS 10.13.6
3D printer brand / version + firmware version (if known)
TronXY X5S, Marlin 1.1.7-dev
Behavior
When generating gcode for vases, instead of a continuous path, there is a linear slanted seam across all layers visible in the preview that also appears in the printed object. It is independent of the shape, source or structure of the object, and shows up in the bottom right quadrant of the print area.
Expected: seamless path along the perimeter
Actual: slanted seam in print
Project File (.3MF) where problem occurs
Vase_Spiral_Matrjoshka.3mf.zip
The text was updated successfully, but these errors were encountered: