Fuzzy skin slicing with identical patterns

[cowc1um]

Is there an existing issue for this problem?

• I have searched the existing issues

OrcaSlicer Version

2.1 beta

Operating System (OS)

Windows

OS Version

windows 10

Additional system information

intel 12900kf, rtx3080

Printer

Bambu X1C

How to reproduce

Slice model with fuzzy contour only enabled.

Actual results

When sliced the first time, some models exhibit contigious areas where the fuzzy skin generated are identical and are aligned, resulting in an area where there is no fuzzy randomness. It seems to happen mostly on cylindrical surfaces

Expected results

The fuzzy skin shouldnt align between layers at all and should be completely random. the issue can be remedied by disabling fuzzy skin after the first slice, and re-enabling it and reslicing it, resulting in truely random fuzzi

ness

Project file & Debug log uploads

Fuzzy skin issue project.zip
First attempt at slicing will show the issue. reslicing the file after disabling and reabling fuzzy will solve the issue

Checklist of files to include

• Log file
• Project file

Anything else?

No response

[SeaRyanC]

Also reported at Bambu bambulab/BambuStudio#4253

This repros pretty obviously with just a cube. I scaled it up on the Z Axis and you can see the patterns readily. The workaround offered here doesn't entirely work; subsequent slices after toggling the option still have visible repetition, though the first slice seems to give a more "obvious" patterning

[SeaRyanC]

I think I have this one figured out (if someone wants to send a PR please do, I don't have time to set up a dev environment at the moment)

Every other function in libslic3r that uses rand ensures it calls srand(time(NULL)); first, but fuzzy_polygon doesn't (see here)

Layers get batched out to each worker thread which gets a thread-local random seed with the default of srand(1), which means that every worker thread produces the same sequence of noise, leading to the visible patterns. This also explains why the "repeat" workaround mostly works: Eventually each worker thread (I'm assuming there's a thread pool here) has processed a slightly different number of layers, meaning it's in a different place in the same sequence of rand results.

The easiest way to demonstrate this is that if you restart Orca and re-slice the same cube, the same random noise gets applied, but in slightly different order depending on how the threads get scheduled, which is exactly what you see:

Calling srand(time(NULL)) is probably not a good fix, since every worker thread is likely to observe the same time(NULL) return value and just demonstrate the same problem. It sounds like you can do something like this to use the thread ID to initialize the RNG, which should guarantee each worker thread gets a different RNG sequence

srand(std::hash<std::thread::id>()(std::this_thread::get_id()));

But I haven't tried this