VeryFine MaxResolution (<0.1mm) results in jagged artifacts and worse slicing

[daT4v1s]

Application Version

Cura 4.3.0 , Official Build

Platform

Linux Ubuntu 18.04 LTS , Ultimaker 2+

Display Driver

Intel Graphics

Steps to Reproduce

set max resolution to LessThan 0.1 mm slice print view tool-path result in PreviewPane

Actual Results

the lines look tangles,and coarser i thought a lower number meant a finer result, but if was simply coarser the artifacts are expected to be regular, but are jagged here and also there are occasional spurious blotches

is this due to code being emitted being finder than what the printer can represent? (heard of 0.04mm but haven't verified this)

also the printing times changed irregularly for other prints when tweaking this value (more than 10 minutes at some values for a 2-4 hours print)

Expected results

lines look smoother when using a finer resolution, print paths follow the curve, remain smooth, no spurious blobs around the print

Additional Information

this is still the case after disabling/resetting various settings, except for the resolution related

various resolution setting sweep, starting from 0.01mm (supposedly finest) notice the random blobs @ 0.01mm and 0.03mm

• this became more noticeable when using a finer mesh tessellation (relevant of not?)

[daT4v1s]

oops - maybe I should have filed this in https://www.github.com/Ultimaker/Cura/issues how shall i move this?

[Ghostkeeper]

That's okay. Maybe you can provide a project file that reproduces the issue? That's via File -> Save... (Not the save button in the bottom left.) I've tried this with a high resolution cylinder but wasn't able to get that effect.

One thing you could try as a test is to disable wall overlap compensation.

[daT4v1s]

the .3mf cura-file is 34mb, (>10MB attachment limit) the artifacts are still there despite turning off OverlapCompensation

[Ghostkeeper]

You could upload it elsewhere (WeTransfer?) and post a link here.

I tried to reproduce it by loading a 700MB sphere with 1cm diameter into Cura, the highest resolution model I have. But the surface was smooth.

[daT4v1s]

MaxRes bug demo, (AutoDropModelsOff) ZeroHorizontalExpansion .3mf

[Ghostkeeper]

Got it. I was thinking maybe that it had something to do with Compensate Wall Overlaps but it doesn't. It seems to be reducing the resolution way too much. I guess 0.01mm is getting somewhat near the slicing resolution of 0.001mm so maybe we're seeing some rounding errors. I'll put up a notice to discuss with the rest of the team.

[smartavionics]

Hi @daT4v1s , i have a possible fix that you could try if you are willing to install one of my development builds which you can find at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0. I will build a release containing the fix tomorrow (Sunday).

I am still seeing some weird roughness in the wall at one end of your model which is odd as the rest of it looks good.

[smartavionics]

Hello @daT4v1s , I have now uploaded a new Linux build (1027) if you wish to try it. Please note that in this build, the resolution settings have been moved to the Mesh Fixes section.

I haven't been able to fix the roughness that occurs in one corner of your model. Something weird's going on.

[smartavionics]

I think that rough region is being created by Cura due to the mesh being less uniform in that region. Firstly, here's an image of the mesh on another portion of the model's outline that slices without the roughness...

Notice how the triangles on the edge are pretty uniform all the way around that curve.

Now compare that with this image which is the edge that gets sliced all rough...

It looks very different, doesn't it? Much more random.

Obviously, Cura should cope with that less uniform mesh but at the moment, it doesn't. I'm not familiar with that part of the slicer but I'm guessing the problem lies in the code that takes the mesh and forms the basic polygons?

[smartavionics]

I reduced the mesh down to 100000 triangles and the rough region has gone. That part of the mesh now looks like this...

I don't intend to spend any more time on this as now we know that the problem can be avoided.

[daT4v1s]

@smartavionics ~the appimage build wouldn't work until after extracting~ (didn't work due to comma i added to filename) but typing numbers: numpad does not work, main keyboard does

may i ask what program you you to view/edit the mesh, i don't recognise it

also for the part that is rendered rough, whatever the cause, the problem is not in the normals of the mesh face

[smartavionics]

but typing numbers: numpad does not work, main keyboard does

Sorry, I never use the numpad but I'll look at that.

To view the mesh (as shown in my images above), I use gmsh which I build from the their git source.

I reduced the mesh size using meshlab which I installed from https://launchpad.net/~zarquon42/+archive/ubuntu/meshlab

also for the part that is rendered rough, whatever the cause, the problem is not in the normals of the mesh face

I wonder if it is simply the density of the triangles in that region that is causing confusion. Other regions of that sloping edge that goes around your model look quite different.

[daT4v1s]

the fillet rounds did improve @ fine-resolution an updated version of the file had different scaling, and surprisingly the

weird roughness

was gone at different scaling (0.8% vs ~0.72% shrinkage compensation) slight changes result in dramatic differences in the wrinkles at the mesh

at 1.0055× scaling also had this random blotch (it appears to be ironing) but after closing and re-opening (not saving) and redo-ing the scaling, i wasn't able to reproduce it

is this fuzzing cura? it sometimes hangs during slicing instead of eventually finishing. Does repeatedly scaling the object within cura introduce rounding errors into the mesh, esp if the mesh is dense (fine spacing between vertices)?

there should be a better way of testing scaling & resolution settings instead of doing this semi-manually

screenshots: scaling sweep .7z

also notice the travel moves (non-convergent/inconsistent/erratic vs mesh scale) - is that supposed to happen?

don't know if it's related but blender thinks some parts of the mesh are self-intersecting

[Ghostkeeper]

Does repeatedly scaling the object within cura introduce rounding errors into the mesh, esp if the mesh is dense (fine spacing between vertices)?

There are two rounding errors that could occur:

1. Floating-point rounding in the scaling matrix. These rounding errors propagate (so repeatedly scaling will increase the error). However the errors are on the order of 0.00000000000002% (2*10^-16).
2. Rounding to micrometres in CuraEngine. These rounding errors don't propagate, so repeatedly scaling will not increase the error.

We have automated tests for the simplification feature. The problem with fuzzing them is that you'd need to know the ground truth. But there are certainly some properties that we could test better, like the length of the smallest line segment after simplification or the maximum deviation.

[Virtox]

As my bug report was diverted here, for me it goes awry when max resolution goes below 0.5mm already. Even with a clean an simple mesh, I have posted a file and images here: https://github.com/Ultimaker/Cura/issues/7245

Is it possible to turn of simplification completely some way until it is fixed, at least in surface mode or spiral vase? I usually have very clean manifold meshes that should be relatively easy to turn into paths that follow the mesh points exactly.

[Ghostkeeper]

Currently, no. I've ran into that problem myself too. When I need a test that is unmodified by the simplification and has small segments, I'd need to either disable it in CuraEngine's source code (which requires a from-source build of CuraEngine) or I'd need to use the SVGToolpathReader (which is limited in many ways, but sufficient for some tests).

There is no real workaround for this bug, which makes it all the more stringent.