Ultimaker
Spiralize mode is and has been inconsistent from at least version 4.6.2
Cura Version
4.6.2 through 5.6.0 at least
Operating System
Win7/Win10/Win11 Mutiple GPUs
Printer
This is a slicer bug report, not a printer issue
Reproduction steps
Loading any relatively complex vase mode print typically experiences inconsistent slicing. As in you can load it in, slice it, and it will be missing some features (Cura is apparently randomly and inconsistently filling in small gaps that allow the model to print successfully in vase mode). Then you can simple move it to a new position (adjust X/Y) on the build plate, and it will be missing DIFFERENT features (Did I mention Cura randomly ignoring small gaps?). Or it will slice completely successfully. There is no predictability or consistency that I can see, other than each specific spot on the build plate will consistently yield the same slice.
Actual results
The model slices wrong, or it slices correctly, depending on where you place it on the plate. Since it cannot be predicted, random guesswork must be used to find a spot on the plate that causes Cura to correctly slice the model. This points to internally inconsistent code. It has only gotten worse in Cura 5.
Expected results
The model should slice exactly the same no matter where on the plate you put it, as long as it is within the boundaries of the plate.
Add your .zip and screenshots here ⬇️
The model is the same in all four images. The first two images show how simply moving the model on the plate yields a different slice.
The black circles in the third image are where Cura is ignoring gaps that are identical in width to the gaps it recognizes, circled in green.
The final image show the same model, finally sliced correctly (In Cura 4.6.2) by managing to guess the spot on the build plate that would slice it correctly.
Thanks for the report. Please zip and post a project file. Without your settings and the model this can't be investigated. The Spiralize feature changed with 5.0 and a lot of people have been disappointed with it since then. The SmartAvionics Cura build is based on 4.x Cura and his Spiralize function works as you would expect. It's what I use for Spiralize.
Post a project though. It's an interesting model.
This is my version of your model in 5.7.2. It doesn't matter where it is on the build plate, it successfully spiralizes and no "islands" develop.
Your model didn't spiralize "as expected" in SmartAvionics Cura 4.20 either so part of this is that the design just isn't working.
This is your model with "Remove all Holes" turned off. That one (gray lines) area has devolved into an "island" and somehow someway Cura has decided to ignore it when Remove all Holes is enabled.
I'm leaving the bug label on this as it sure could use another pair of eyeballs (or 10). The Cura team will take a look.
I never liked the gaps needed to insure something spiralized. It just occurred to me - What if the gaps didn't line up but rather were interleaved like this:
That ties the mess together nicely I think and doesn't interfere with spiralize.
We're already veering off into the weeds here. The model is not the issue.
The issue is that the slice is different depending upon where the model is located on the build plate, in the Cura versions referenced in the issue. This inconsistency should never happen, and likely points to internal code inconsistency, or at least a lack of necessary precision in the associated datatypes.
I admittedly have not yet tested in V 5.7.2. If the bug (different slice results when moving a complex spiralized model across the plate) has been resolved in the latest versions, then we should delete this issue, esp if the issue cannot be repeated in 5.7.2.
I never liked the gaps needed to insure something spiralized. It just occurred to me - What if the gaps didn't line up but rather were interleaved like this:
That ties the mess together nicely I think and doesn't interfere with spiralize.
I do like that "interweaving" - it reminds one that you can do any kind of "cut" as long as it divides the otherwise continuous path. I've also used spiral "cuts" to improve the strength and aesthetic appeal of spiralized models. But again, that is neither here nor there. The issue is inconsistent slicing when adjusting the X/Y position on the plate.
I also keep forgetting to mention that rotation upon the Z axis also often affects the slice (and it should not).
I don't think there would be any difference in 5.7.2.
When rotating the model makes a difference in the slice, it is often an indicator of something "off" about the model. I'm not saying there isn't a bug here...I'm saying there isn't only a bug here. There appears to be issues with the model structure and the spiral path it generates.
This is your model in PrusaSlicer in Spiral Mode. There are missing areas and there are Z seams.
This is your model sliced in OrcaSlicer in Spiral Mode. Again, missing areas and there are Z seams.
This is the Cura slice
None of them appear to be correct. Either all 3 slicers are bugged (possible), or there is something within the model that is causing them to fail to produce a desired result (probable).
The model I mocked up is not the same but it is very similar in shape. I designed features into it to force certain paths and allow spiralize to work.
This is the one I came up with in Prusaslicer using the same settings. The toolpath is different, but it is a spiral.
All three slices are erroneous. It is not the model. I would appreciate it if you could point to what you consider to be specific problems with my model's geometry, rather than just using (in the case of Cura, buggy, and in the case of PrusaSlicer, misconfigured) slice results to judge its integrity instead.
Prusa errored because, no offense, you didn't tell PrusaSlicer how to slice it properly. I don't use Orca, but I assume the same issue happened there since it is derivative.
There is a setting called Slice Gap Closing Radius in PrusaSlicer. It tells PrusaSlicer the maximum size gap it should ignore and treat as a single contiguous piece of geometry. My model has gaps in ALL the necessary locations (if you zoom in or use xray mode, or use your favorite CAD you can see them), but they are quite small. If you set Slice Gap Closing Radius from the default to something like .001, you will find the model slices perfectly, and consistently no matter where it is located on the plate nor how it is rotated. That slicers close gaps (essentially modifying geometry) by default and without explicit warning is troubling (it seems they ASSUME problematic geometry as the default), while those of us who pay attention to the geometry of our models must suffer accordingly. At least PrusaSlicer allows adjustment of this setting to the point that it's assumptive behavior is negligible.
I should probably mention that this is just one of a huge collection of vase models I've been generating. Once they start using small gaps to generate interesting "internal" features (not really internal with regard to topology, but appearing to be to the naked eye), Cura starts slicing them inconsistently, unless I crank up the gap widths intolerably high.
All of these models are parametrically generated using OpenSCAD code of mine, which doubles up wall width to support nozzle travel in both directions as needed, and also adds those tiny gaps to the models to expose all required surfaces as external topology. It is very precise (more than I would be with regular CAD).
These techniques are similar if not identical to those employed by 3D printable airplane designers to achieve internal features in their vase-mode printed wings and other vase-mode printed sections.
I was thinking of airplane printing when I saw it.
Within Cura I cannot get it to acknowledge all the 0.02 gaps.
Playing with some of the wall settings I get some interesting results, but no "correct" results.
This is the same area as above but with Horizontal Expansion at -0.01. This just isn't right.
I used an online repair site to check your model. It didn't really find anything, but it did add some vertices and triangles. --> 0 Naked edges (?) --> 0 Planar holes (?) --> 0 Non-planar holes (?) --> 0 Non-manifold edges (?) --> 0 Inverted faces (?) --> 0 Degenerate faces (?) --> 0 Duplicate faces (?) --> 0 Disjoint shells (?) -> Repairing: 100.00% ----- Repair completed in 2024ms ------ -> Vertex count changed from 2530 to 2865 (+335) -> Triangle count changed from 5056 to 5726 (+670)
That is usually more of a "personal preference" of the particular repair software rather than an indication of errors in the model.
I used that "repaired" model for all experiments in this post (to keep it "apples and apples").
I'm not experienced in either Prusa or Orca. Making the single change you suggested did not work for me however, the repaired model did Spiralize in both PrusaSlicer and Orca.
I get the same erroneous Cura slicing in @smartavionics MB fork of Cura which is based on Cura 4.x. His version is my go-to for spiralize and it also ignored some of the gaps causing parts of the model to be ignored.
Finally, I threw the model into Bambu Studio just for kicks and it ignored all the .02 gaps.
At that point I got bored with it and decided to have another cup of coffee and get my gear ready to go fishing.
"I'm not experienced in either Prusa or Orca."
I can post the PrusaSlicer 3mf project if that helps you, but I really must insist you examine and critique the geometry of my model itself instead of continuing to base your judgements upon inconsistent relativistic slicer results. The model is not the issue. Seriously. I can post a different (actually multiple different), more simple vase models that demonstrates the same problem, if that will also help convince you.
I agree that the model does not appear to be an issue. That's why there is still a "bug" label on this.
The image in my last post details the fact that Cura is ignoring some gaps in the model while acknowledging other identical gaps. That should not happen. Converting the STL to a DXF file and checking it in AutoCAD puts those gaps at 0.01681150mm.
Is it significant to this report that Bambu Studio completely ignored the gaps? No. But it is a data point for me.
Part of what I do here in triaging the bug reports is to give the Cura Team a starting point for their investigation. The bug reports need to be looked at from all directions. I try not to leave any stone unturned. Neglecting to investigate the model would be wrong because my experience (in 4 years of doing this) has shown that in at least 75% of bug reports, it is the model that is the problem.
The Cura team will take a look. They won't need to spend much time looking at the model because I already did.
I think I have found the cause of this issue. There's a hard coded distance used to determine when two vertices should be melded (i.e. considered the same). It is set at 30uM which is too large for the above model because the weeny gaps are around 15uM wide. When I set the meld distance to 10uM, I get what looks like a good spiralized slice....
The limit was set back in 2014 so this has been a problem for some time.
Cura devs, the diff is below. Obviously, using a value of 10uM may not be ideal for other models so some testing is required to determine whether the value can be simply changed. Or maybe it needs to be a setting added to the mesh fixes group?
diff --git a/src/mesh.cpp b/src/mesh.cpp
index 3e73b09e6..ecad982a6 100644
--- a/src/mesh.cpp
+++ b/src/mesh.cpp
@@ -8,7 +8,7 @@
namespace cura
{
-const int vertex_meld_distance = MM2INT(0.03);
+const int vertex_meld_distance = MM2INT(0.01);
/*!
* returns a hash for the location, but first divides by the vertex_meld_distance,
* so that any point within a box of vertex_meld_distance by vertex_meld_distance would get mapped to the same hash.
Of course, this may not be the actual bug but by changing the value, the real bug is avoided.
https://github.com/Ultimaker/Cura/assets/585618/5b2250f4-4f33-411a-8eae-d12f8a76290c
I have opened a bug report for the Cura Engine and cross-referenced this report.
I have opened a bug report for the Cura Engine and cross-referenced this report.
Thanks! Much appreciated!!!
I think I have found the cause of this issue. There's a hard coded distance used to determine when two vertices should be melded (i.e. considered the same). It is set at 30uM which is too large for the above model because the weeny gaps are around 15uM wide. When I set the meld distance to 10uM, I get what looks like a good spiralized slice....
The limit was set back in 2014 so this has been a problem for some time.
Cura devs, the diff is below. Obviously, using a value of 10uM may not be ideal for other models so some testing is required to determine whether the value can be simply changed. Or maybe it needs to be a setting added to the mesh fixes group?
diff --git a/src/mesh.cpp b/src/mesh.cpp index 3e73b09e6..ecad982a6 100644 --- a/src/mesh.cpp +++ b/src/mesh.cpp @@ -8,7 +8,7 @@ namespace cura { -const int vertex_meld_distance = MM2INT(0.03); +const int vertex_meld_distance = MM2INT(0.01); /*! * returns a hash for the location, but first divides by the vertex_meld_distance, * so that any point within a box of vertex_meld_distance by vertex_meld_distance would get mapped to the same hash.Of course, this may not be the actual bug but by changing the value, the real bug is avoided.
You rule! Thank you so much for the analysis!
This may be a really stupid question, and if it's tangential I apologize: Why does Cura (and other slicers also) silently ignore ANY gaps, even if they are quite small? I (and presumably a significant amount of others) like to know when our model geometries are being modified, and to do so silently robs us of knowledge we might use to determine what is happening when slicing yields unexpected results. I.e. If I didn't include a parametric "gap" sizing in my vase model generation software, this problem would have been much harder to diagnose.
Cura works in uM, the smallest distance it can represent is 1 uM. However, because it's doing a lot of calculations that involve transformation of coordinates small errors can creep in which tend to accumulate. In quite a few places in the code are hard-coded tolerances that allow some slack. In this specific instance, the tolerance is too large for your model(s) which embody very small gaps. I think it would be very difficult to remove all the tolerances in the code of Cura (and the other slicers).
I think I will make the meld distance mentioned above a setting in my Cura. It will be in the next release.
FYI - release 4.20.21 is now available and it has a new setting that lets you change vertex_meld_distance. If you try it out and have any problems or requests, please open an issue at https://github.com/smartavionics/Cura/issues rather than here. Thanks.
Cura works in uM, the smallest distance it can represent is 1 uM. However, because it's doing a lot of calculations that involve transformation of coordinates small errors can creep in which tend to accumulate. In quite a few places in the code are hard-coded tolerances that allow some slack. In this specific instance, the tolerance is too large for your model(s) which embody very small gaps. I think it would be very difficult to remove all the tolerances in the code of Cura (and the other slicers).
I think I will make the meld distance mentioned above a setting in my Cura. It will be in the next release.
Thank you. That is the best explanation I have heard so far - sort of a mathematical garbage collection, if you will. I wonder how PrusaSlicer handles it so gracefully? You can crank down their Slice Gap Closing Radius to stupidly low values (like .0001) and it still outperforms Cura by a country mile.
FYI - release 4.20.21 is now available and it has a new setting that lets you change vertex_meld_distance. If you try it out and have any problems or requests, please open an issue at https://github.com/smartavionics/Cura/issues rather than here. Thanks.
Can confirm your release works flawlessly WRT to consistent and correct slicing regardless of position on the build plate and/or rotation with my vase models, or at least the few I have tested so far. Thanks!!!
Wondering if this can be adapted to work with recent Cura versions, and pulled into master at some point?
The required change is trivial. UM could easily incorporate a similar change in their Cura.
Can we please implement the proposed patch by smartavionics in the next release? And please no "Just submit a pull". I would if I could confidently do so, but it seems like the issue is already well understood, and has already been addressed by those with greater coding skills than I? Is this such a difficult change to implement? I can ask even more nicely, if that would help...
Can we please implement this change in the next update? Pretty please, with a cherry on top?