Slicer non-deterministic results

[itay-grudev]

OrcaSlicer Version

1.9.0

OS version

Ubuntu 23.10

Additional system information

AMD Ryzen 9 7950X3D GTX 3070

Printer

Creality K1 Max 0.6mm Nozzle

How to reproduce

I have a component that has a small hole that goes through the component. Sometimes when I slice, with exactly the same settings, I get this:

Most of the times, I don't get anything:

And this is the part that really puzzles, because I would really expect a software like this to be deterministic with results that are highly reproducible.

Actual results

Significant variations between slices.

Expected results

I expect that between slices with exactly the same settings, the results are the same.

Project file & Debug log uploads

Orca Project + Logs.zip

Checklist of files to include

• [X] Log file
• [X] Project file

[DVSVIDEO]

I tried it. This is a faulty model. Before slicing, right-click on the object and select the "repair model" menu item. You will get a message that the object is repaired. Then it will slice perfectly and you will always get the same

Since this is not a real error, I suggest you clear the error sheet with a short explanation at the bottom (there is enough error reporting).

[itay-grudev]

Even if the model is faulty, why isn't the result consistent? Shouldn't the same input result in the same output.

I suppose this is especially relevant on Linux, where the Fix Model feature is not supported.

[DVSVIDEO]

Wrong model, wrong result. Accept it. Move on...

[DVSVIDEO]

Even if the model is faulty, why isn't the result consistent? Shouldn't the same input result in the same output.

I suppose this is especially relevant on Linux, where the Fix Model feature is not supported.

If you start off with a flat tyre, you will always end up somewhere else again and again. Sometimes in one ditch, sometimes in another. Because the wheel is defective, it introduces an error into the system, which makes it unpredictable. If you start with a flawless wheel, you'll always end up in the same place. I hope you understand the analogy. A faulty model can lead to faulty calculations, which can vary. Solution: - Use a good model

• Correct the model with Orcaslicer
• Correct model with 3rd party program (meshmixer)

[itay-grudev]

Here is the thing, one would expect that given the same input file, the slicer algorithm follows the same instruction and produces the same G-Code every single time. This is referred to as a deterministic algorithm in Computer Science.

But in reality that doesn't seem to be the case in the slicer. There is an element of random (or another decision-making process) that branches the algorithm in different unintuitive ways and changes the resulting G-Code between slices.

This is an unexpected behaviour. It could be caused by many things and may even be intentional, although unlikely.

Yes, the file has errors, but the errors expose a deeper issue in the slicing engine.

[DVSVIDEO]

I disagree with you. When the input file is OK, the slicer handles it accurately, I always get the same result. But if the model is wrong, the floating point calculations can be wrong. These errors act like a random number generator. They may give a different result after each run. I think this would only need to be fixed if it could happen at any time. After I corrected the model you posted, each run gave the same correct result. Conclusion: the model needs fixing and not the slicer.

[github-actions[bot]]

Orca bot: this issue is stale because it has been open for 90 days with no activity.

[dstulken]

When the input file is OK, the slicer handles it accurately, I always get the same result. But if the model is wrong, the floating point calculations can be wrong. These errors act like a random number generator. They may give a different result after each run.

I don't agree.

A model should slice the same way each time. If there is a fault in the model, some logic in the parsing has to decide how to handle that fault. This fault handling should be deterministic - and since the model hasn't changed between runs, a faulty or corrupt model should still be processed the same way each time. There should not be any floating point values "acting as random number generators", because those floating point values should always be the same each time.

The fact that you get the correct result when the input file is not corrupt doesn't prove that the model is the issue here - you have simply removed the test case that was exposing the nondeterministic behavior in the slicing logic.

[github-actions[bot]]

Orca bot: this issue is stale because it has been open for 90 days with no activity.

[itay-grudev]

Ping.