Unexpected seam in vase mode

[suromark]

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

[bubnikv]

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.

[suromark]

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?

[bubnikv]

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 https://github.com/prusa3d/PrusaSlicer/issues/2841?email_source=notifications&email_token=ABMPSI2WVAW3Z6LEYND2KJTRB4GBXA5CNFSM4ISGY43KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELF2NBY#issuecomment-583771783, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSI7SY5BIMXROH2SVUQLRB4GBXANCNFSM4ISGY43A .

[Kachidoki2807]

I leave a comment here to confirm that this issue is still present with the version 2.2.0.

[LuisHerrero92]

This is still an issue in 2.3.1

[DavidBjerreBjoerklund]

This is still and issue and kind of negates the whole point of vasemode

[vorner]

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).

• Slice to layers like usual (this is being done now, both in vase and non-vase mode)
• Re-arrange the Z positions of the extrusion, so its going uphill (this is being done now and this makes it the vase mode)
• For each point of the „layer“, slice the object once again, but in the adjusted Z, move the point in the X/Y coordinates to the newly computed place (this is the new addition).

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.

[Grummle]

Its a horrible hack and has more edge cases then a case of Gillette razors, but it does work. https://github.com/Grummle/SpiralSlicer

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.

[kosteklvp]

Looks like it's still in PrusaSlicer 2.4.0.

[clivius]

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.

[5jvm0u4]

Still in PrusaSlicer 2.5.0 alpha 2 confirmed. And still very visible.

[Grummle]

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.

[animatorgeek]

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.

[degroof]

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... I've got a gcode file where there's are two adjacent layer at 148.6 and 148.8. The first has 217 G1 commands and the second has 202.

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.

[degroof]

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:

"C:\Program Files\Java\jdk-12.0.1\bin\java.exe" -jar C:\java\spiralGcodeFix.jar

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.

spiralGcodeFix.zip src.zip

[degroof]

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.

spiralGcodeFix.zip

[mjgoldberg]

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.

[degroof]

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.

[mjgoldberg]

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.

[SytanSD]

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.

[devoh747]

1Crystal_1h1m_0.20mm_240C_PLA_CR10V2_withlayers.txt I also ran into this issue today printing the single crystal from https://www.printables.com/model/357415-led-crystals. Problem still exists in PrusaSlicer 2.6 Alpha 3.

Sadly @degroof 's python program does not catch the issue.

Here are two examples in the same print.

Here is the top most issue

[gmoissey]

Same here, unfortunately, post-processing scripts don't work for my models.

[devoh747]

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.

[yonitjio]

Turning off "Avoid crossing perimeters" works for me. On: Off:

but what's weird is in vase mode, it still generates seams:

but then it's gone when using 0.6 settings:

[animatorgeek]

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?

[yonitjio]

This is so random, I tried with 0 retraction, and the seams are gone. 0.5mm retraction:

0mm retraction:

[5jvm0u4]

It's not the seam, the "end to start point mismatch" won't show up as seam in preview. It's cause by the slicing algorithm, probably not possible to resolve by changing any individual setting.

[yonitjio]

Did you also turn off avoid crossing parameter? If I turn it on, even with 0 retraction the weird "seams" still there. But you're probably right, this thing is inherent.

[5jvm0u4]

I did, it seemed to be not effecting anything.

[animatorgeek]

Re turning off retraction: that looks like it's not in vase mode. In vase mode there are no seams (other than the bug we're talking about in this issue). The slicer will not show any seam dots in vase mode except in the base layers before vase mode starts.

On Tue, Aug 22, 2023 at 4:05 AM yonitjio @.***> wrote:

This is so random, I tried with 0 retraction, and the seams are gone. 0.5mm retraction: [image: image] https://user-images.githubusercontent.com/22361729/262330138-09739e38-c65d-4a3e-80c9-47321dbecb03.png

0mm retraction: [image: image] https://user-images.githubusercontent.com/22361729/262330572-34544b99-1ebe-416b-9e54-e06363db9fa3.png

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/2841#issuecomment-1687974714, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYWWGPWAUVREOVCBNILJ7TXWSG7ZANCNFSM4ISGY43A . You are receiving this because you commented.Message ID: @.***>

[yonitjio]

It's in vase mode, I made a different profile for vase mode. That's why I said it's weird. Oh well, may be it's different bug. I hope you can find solution for your case. Best of luck.

[gaiuscosades]

Bump, but also if the issue does not get solved (complete redesign of vase mode algorithm) it would be nice if the enforcers of the "paint on seam" function would be respected for this pseudoseam. Therby making it hideable at least for some of us. i.e. for me... ^^

[rosenstand]

This bug is annoying. I was hoping to use Prusa printers to print lamp shades and vases, but the results are unsellable with this bug.

[johnnydoesdesign]

This bug is annoying. I was hoping to use Prusa printers to print lamp shades and vases, but the results are unsellable with this bug.

I don't think this is the same issue. As most cases of the "seam" appearing happens when the endpoint of the previous "layer" has a difference in XY to the first point of the next. In your example, the end and beginning should be right on top of each other on the vertical wall sections at least. So either there's an unhappy congruence of the layer shift happening right where your pattern is or something different is going on. How is the pattern on the wall created? is it modelled? You should check the dimensions of your pattern and the layer heights.

[rosenstand]

I’m pretty sure it’s the same bug. The model was made with Blender and is just a basic cylinder with small vertical ridges, then deformed with a <3000 degree Z swirl. So geometrically really simple and apparently a great torture test for this bug.

On other models, although not as clearly visible, I also notice that the pattern is not perfectly vertical but moves slightly as Z height increases during the print. I can attach photos of them as well, if it’s any help. Prints was on a MK3S btw., I now have a MK4 to test on as well.

Since I posted the last comment, I have bought a FLSUN V400 which uses Cura. The problem is not present there.

[johnnydoesdesign]

Why is this issue still here? This is really bugging me and making my products worth less!

I attached a picture of two shapes, where it's quite visible, that the seam especially exists where the XY Coordinates between two spirals change a lot. Look at the left shape: where it is nearly vertical the seam is barely visible. where the angle is greater it becomes obvious. On the right shape too. (the vertical walls are actually 3° slanted, that's why the seam is there too.)

Cura fixed it for most parts ages ago. There is an option called smoot spiralized contour. From what I see it just interpolates the XY coordinates of each point of one spiral according to the one above. The first point isn't moved at all, the last point is 100% moved to where the first of the next spiral will be. If it's a perfect cylinder no point will move. (note that the tooltip in cura states, that the seam (circled green) is ONLY visible in the layer preview and will not be printed. Which is true.)

Of course, this will smooth out small features that exist within only one layer. So this would not help in a case like the design @rosenstand showed. BUT If the design is changed, so that each feature is 2-3 layers high it would still give a similar-ish result.

[degroof]

I poked around in the source code a while ago and, from what I can tell, fixing this issue would pretty much require scrapping the current vase mode algorithm and rewriting it from scratch. Right now, it's taking each individual horizontal slice and altering it to be a spiral. This results in a non-contiguous series of spirals (one for each layer).

To achieve a contiguous spiral, the code would need to sample the X and Y values of the surface of the model as the Z value moves up its height. I'm assuming that's what Cura does, at least.

It'd be a big change, which may be why it hasn't been prioritized.

[johnnydoesdesign]

That's a shame. everything else about PS implementation of vasemode is soo much superior. eg having the option to change layer heights within a model is fantastic! But apparently they aren't planning on updating Vasemode to G2 G3 gcode as well ... might be a bad or a good sign :D

[devoh747]

I wish they had bug bounties.. I would contribute a few bucks to seeing this fixed. I bet I am not the only one that would.

[QuiNz0r]

any update on this? This ia a huge issue actually

[andrewboktor]

I've been working on something Before

After

It still has a lot of bugs and needs a lot more work.

[GuzziRaz]

https://github.com/prusa3d/PrusaSlicer/issues/2841#issuecomment-1785254820 Cura fixed it for most parts ages ago. There is an option called smoot spiralized contour. From what I see it just interpolates the XY coordinates of each point of one spiral according to the one above. The first point isn't moved at all, the last point is 100% moved to where the first of the next spiral will be. If it's a perfect cylinder no point will move.

Assuming we slice from bottom up, can we not just do the opposite? Then we only need to know the layer below (which we do because it's already sliced): Interpolate the XY coordinates of each point of one spiral according to the one below. The first point is 100% moved to where the last of the previous spiral was, the last point isn't moved at all. If it's a perfect cylinder no point will move.

Sorry if I'm just stupid and miss something obvious.

[johnnydoesdesign]

Assuming we slice from bottom up, can we not just do the opposite? Then we only need to know the layer below (which we do because it's already sliced): Interpolate the XY coordinates of each point of one spiral according to the one below. The first point is 100% moved to where the last of the previous spiral was, the last point isn't moved at all. If it's a perfect cylinder no point will move.

Sorry if I'm just stupid and miss something obvious.

Well to me - a person that has no idea whatsoever how prusaslicers vase mode is written, and a person that also has no idea how to write any code for it anyways - that sounds viable.

[johnnydoesdesign]

I've been working on something ... It still has a lot of bugs and needs a lot more work.

Could you explain what you did? (in short simple non-coding language pls :D ) I am genuinely curious. All I see is that the seam on the 11o'clock is gone.

[degroof]

XY interpolation seems to work pretty well. I wrote a python script to do something like that a while ago, and it came out OK. The calculations can get a bit fiddly when the line segments between adjacent layers don't match up well.

Another approach would be to oversample at say 10x (e.g. slice at 0.02mm instead of 0.2mm), and then pick the coordinates from one ot the ten layers depending on how far along the path you are. The more you oversample, the smoother the transitions would be, but the slicing would take longer. (cue adding a "quality" slider 😀 )

[andrewboktor]

I've been working on something ... It still has a lot of bugs and needs a lot more work.

Could you explain what you did? (in short simple non-coding language pls :D ) I am genuinely curious. All I see is that the seam on the 11o'clock is gone.

I am taking the CURA solution. When doing spiral mode, we gradually increase z from start to end. Rephrasing that, we start with z identical to the previous layer and we gradually increase it so that at the end we're at the height of the current layer. The technical term is: we interpolate z.

What I did is I added interpolation for X and Y as well. But it's not so straight forward because you need to decide on which point are you going to interpolate to. The approach I have now works well for symmetric shapes but won't work well for asymetric ones. I already know what I want to do next, it'll just take time to write it up :). Oh also the current implementation crashes the slicer sometimes so gotta figure that out too.

[degroof]

What I did is I added interpolation for X and Y as well. But it's not so straight forward because you need to decide on which point are you going to interpolate to. The approach I have now works well for symmetric shapes but won't work well for asymetric ones.

I ran into the same issue with the python script. It's pretty straightforward when adjacent layers have similar paths, or at least the same number of vertices, but things can really go sideways if the two paths are significantly different.

[QuiNz0r]

What I did is I added interpolation for X and Y as well. But it's not so straight forward because you need to decide on which point are you going to interpolate to. The approach I have now works well for symmetric shapes but won't work well for asymetric ones.

I ran into the same issue with the python script. It's pretty straightforward when adjacent layers have similar paths, or at least the same number of vertices, but things can really go sideways if the two paths are significantly different.

The python script works well for my purposes, I only have one big Issue: the script erases my variable layer height, any chance to implement that?

[andrewboktor]

@rosenstand Would you be willing to share the stl for the vase you shared above for testing?

[andrewboktor]

In case people missed it. I rewrote vase mode to fix this issue and more. PR in Orca linked above. Please provide feedback.