Bug fix: Disable filament shrink compensation for multicolor/material prints which was causing incorrect colour segmentation.

[igiannakas]

Description

Fixes the below issues reported when using filament shrink compensation together with a multi-color/material print.

The fix is detecting the use of multiple extruders and disables the compensation for multi material/color prints as it is not compatible. This is similar to the XY hole compensation that is correctly also disabled when printing multi-material prints.

This has been reported several times on both discord and here so maybe this correction helps.

Fixes #5756 Fixes #5152 Fixes #4551 Fixes #5664 Fixes #4091

Tests

Tested with multi colour print with shrink compensation - slices successfully Tested with single colour print with shrink compensation - slices successfully and applies XY correction.

[BioCookieYT]

Thanks for the workaround! I'm wondering if there is another way to achieve filament shrinkage correction since the current way has some issues with some slicer features. An idea would be to simply use the already build in object scaling function as a shrinkage correction: -> check if shrinkage is activated -> scale object using object scaling -> run slicing process

From my testing scaling doesn't affect MMU painting:

I'm not really in the C++ game so not sure if something like this would be possible. Just some idea since scaling is basically filament shrinkage correction from my understanding.

[igiannakas]

The problem is that scaling may also vary by filament. One could be 0.9 and the other 0.95 or something. Then what do you use? 🤔

[BioCookieYT]

Good point 🤔 There are 3 ways I can think of:

1. Cancel slicing with the error "Filament shrinkage must be equal"
2. Calculate the average shrinkage from all used filaments
3. Use the shrinkage of the "main filament" (in the cube example the black one -> the filament which was used first)

It kinda depends on the situation, for parts with just some colored text I would use option 3 or 1, for parts with like 4 colors in one layer option 2. Maybe an option for this in the Multicolor printer tab would be useful? (probably a lot of work to implement😐)

[igiannakas]

It’s the same issue as XY hole compensation that is skipped when doing a multi color print. In my view, material shrinkage should be baked into the model by design, so I’ve never used this. And if needed we can just adjust the size of the model as a complete scale factor.

However, many ppl have this set up and then try to slice a multi material print and then it fails and they don’t know why. So I’m proposing this approach for now, to protect the user from using an incompatible feature.

I’ll investigate if there is an alternative way but not very hopeful as this feature was lifted from SS, which also has this issue, and neither Bambu nor prusa have this implemented, so we cannot cross check what the “upstream” branches have done.

[SoftFever]

I think it would be better to have a warning notification instead of silently disable shrinkage

[igiannakas]

I think it would be better to have a warning notification instead of silently disable shrinkage

I tried that in a similar manner that XY compensation does but the method to raise the slicing message is protected and can’t call it from the parameter pointer :(. Any idea on what pop up to use as an alternative?

[igiannakas]

Mmm let me try something different

[SoftFever]

I think it would be better to have a warning notification instead of silently disable shrinkage

I tried that in a similar manner that XY compensation does but the method to raise the slicing message is protected and can’t call it from the parameter pointer :(. Any idea on what pop up to use as an alternative?

I was referring to a notification(appears at the bottom right) You can take a look at Print::validate() function, which is the place we do validate for the print and throw warning/errors notifications

[igiannakas]

Hey @SoftFever I've implemented the warning message in two places - one triggered at slice time and one at the validate function. Pick your favourite and I'll remove the other :)

The slice time message takes you to the multicoloured object, so that's nice; however it needs me to mark a function as public which I'm not too keen.

Pick one and I'll cleanup the code removing the other one 🥳

[ExR90]

I'm having this issue, but my filaments are set to 100% for shrink already. Easy to reproduce, starting in version 2.1 (any, even Beta) create a primitive cube. Paint one vertical side with any color, then slice. That color won't be in the finished product. Reverting to 2.0 and it behaves as expected.

I don't have the ability to compile my own build to test your fix for my issue but I thought I would chime in mentioning I'm having this problem with the shrinkage already at 100.

[igiannakas]

I'm having this issue, but my filaments are set to 100% for shrink already. Easy to reproduce, starting in version 2.1 (any, even Beta) create a primitive cube. Paint one vertical side with any color, then slice. That color won't be in the finished product. Reverting to 2.0 and it behaves as expected.

I don't have the ability to compile my own build to test your fix for my issue but I thought I would chime in mentioning I'm having this problem with the shrinkage already at 100.

Please save the sliced cube project file and upload it here in a zip file.

I’ve done the exact same test as mentioned above and it doesn’t behave the same as yours.

[igiannakas]

You can download the ready made build here: https://github.com/SoftFever/OrcaSlicer/actions/runs/9615570849

bottom of the page.

[ExR90]

I'm having this issue, but my filaments are set to 100% for shrink already. Easy to reproduce, starting in version 2.1 (any, even Beta) create a primitive cube. Paint one vertical side with any color, then slice. That color won't be in the finished product. Reverting to 2.0 and it behaves as expected. I don't have the ability to compile my own build to test your fix for my issue but I thought I would chime in mentioning I'm having this problem with the shrinkage already at 100.

Please save the sliced cube project file and upload it here in a zip file.

I’ve done the exact same test as mentioned above and it doesn’t behave the same as yours.

@igiannakas

Video of the behavior in 2.0 and 2.1 from my POV. I am on MacOS 14.5 (23F79) on M3 CPU https://share.zight.com/eDuKnZX6

Project file of the test cube and Gcode created of same cube is attached. cube with 3 colors.zip

[ExR90]

You can download the ready made build here: https://github.com/SoftFever/OrcaSlicer/actions/runs/9615570849

bottom of the page.

I tried this but cannot execute the binary, Finder tries to launch it and I get an error that the file is corrupted. It unzipped fine into the DMG, which also mounted fine and was able to extract the binary fine - it just states it is damaged when I try to run it.

[igiannakas]

You can download the ready made build here: https://github.com/SoftFever/OrcaSlicer/actions/runs/9615570849 bottom of the page.

I tried this but cannot execute the binary, Finder tries to launch it and I get an error that the file is corrupted. It unzipped fine into the DMG, which also mounted fine and was able to extract the binary fine - it just states it is damaged when I try to run it.

You need to run this command here to sign the file: xattr -dr com.apple.quarantine /Applications/OrcaSlicer.app

[igiannakas]

Your project file attached above is slicing OK for me:

Honestly I'm lost as cannot reproduce it :(

@SoftFever any thoughts?

[prnthp]

You can download the ready made build here: https://github.com/SoftFever/OrcaSlicer/actions/runs/9615570849

bottom of the page.

Unfortunately this PR didn't seem to fix the issue.

macOS 13.4 Intel

Project file: https://github.com/prnthp/Cone/blob/main/Cone.3mf

[ExR90]

Your project file attached above is slicing OK for me:

Honestly I'm lost as cannot reproduce it :(

@SoftFever any thoughts?

I thought maybe there was something bitched up in the preferences, so I signed into my Mac with a new user, which gave me a brand new profile like on a fresh new install of Orca - it took me through the wizard and everything. I did not configure anything other than saying I had an X1C, then did the test shown above which appears to suggest the preferences are not storing something to cause the problem.

[ExR90]

@igiannakas

Curious, I am on a Mac, and so is the other person that just chimed in on this thread. You on PC or Mac? Maybe there is something to that with respect to OS build?

[igiannakas]

I’m on an M1 Pro MacBook…

[ExR90]

I’m on an M1 Pro MacBook…

No idea then. If I roll back to 2.0 it works fine. Something strange is afoot at the local Circle-K....

[igiannakas]

Just sliced the above model successfully with an M1 MacBook Pro. We need someone to debug this with an Intel Mac? Looks like this is happening with that only?

[igiannakas]

@SoftFever need help :) :) :)

I've been trying to investigate this - but I'm hitting a brick wall.

There are two issues here.

Issue 1: Shrink compensation, that is addressed with this PR successfully (pending comments above etc)

Issue 2: There seems to be a secondary issue that is present in the built files from the GitHub actions:

The below is taken from the build of this PR. Also it's the same with the main release build.

However when I build the main branch locally with already built dependencies all is good:

Then I deleted my GitHub local folder including all build files etc and recloned the repo and rebuilt from scratch. It still works properly even after a clean dependency rebuild etc.

I've also tried running a build using a slightly older version of the GitHub actions on my cloned main branch here: https://github.com/igiannakas/OrcaSlicer/actions/workflows/build_all.yml

Firstly I downloaded my dev branch binaries from here: https://github.com/igiannakas/OrcaSlicer/actions/runs/9632430284

These were built with dependencies cached around 2 weeks ago. https://github.com/igiannakas/OrcaSlicer/actions/caches

It doesnt work again... So there is something up with the way the actions are building the binary for MacOS as it works with a local build but doesnt work with a GitHub actions build...

[Maximizer18]

@SoftFever need help :) :) :)

I've been trying to investigate this - but I'm hitting a brick wall.

There are two issues here.

Issue 1: Shrink compensation, that is addressed with this PR successfully (pending comments above etc)

Issue 2: There seems to be a secondary issue that is present in the built files from the GitHub actions:

The below is taken from the build of this PR. Also it's the same with the main release build.

However when I build the main branch locally with already built dependencies all is good:

Then I deleted my GitHub local folder including all build files etc and recloned the repo and rebuilt from scratch. It still works properly even after a clean dependency rebuild etc.

I've also tried running a build using a slightly older version of the GitHub actions on my cloned main branch here: https://github.com/igiannakas/OrcaSlicer/actions/workflows/build_all.yml

Firstly I downloaded my dev branch binaries from here: https://github.com/igiannakas/OrcaSlicer/actions/runs/9632430284

These were built with dependencies cached around 2 weeks ago. https://github.com/igiannakas/OrcaSlicer/actions/caches

It doesnt work again... So there is something up with the way the actions are building the binary for MacOS as it works with a local build but doesnt work with a GitHub actions build...

Hi, so I'm encountering the same issue on Mac OS 12.7.5 Orca slicer version 2.0.0 works perfectly fine. I don't know the slightest bit about code, but can't you see what changes between the 2 versions to see what could be causing this?

[Maximizer18]

Just sliced the above model successfully with an M1 MacBook Pro. We need someone to debug this with an Intel Mac? Looks like this is happening with that only?

I have an intel Mac. Tell me what I need to do to test whatever.

[ExR90]

Just sliced the above model successfully with an M1 MacBook Pro. We need someone to debug this with an Intel Mac? Looks like this is happening with that only?

I have an intel Mac. Tell me what I need to do to test whatever.

It isn't Intel or Mac silicon only. I've got M3 with the problem, others don't. As others have said it impacts any 2.1 version. All 2.0 versions and before slice fine. I've tried fresh install on fresh user profile and no change in behavior, as I had thought maybe something in the preferences was causing this but no.

[igiannakas]

Latest nightly Mac build should solve the non shrinkage related MMU issue. Download from the nightly and use this command to "sign" it if needed so it opens.

xattr -dr com.apple.quarantine /Applications/OrcaSlicer.app

[SoftFever]

I've updated the CI/CD build script, the problem should be fixed.

[Maximizer18]

Nightly build works! Thank you guys! Would the next update of the regular build include this fix?

[ExR90]

@igiannakas @SoftFever

Just tried the nightly and it DOES solve the "no color on vertical surfaces" issue. Hooray!

[SoftFever]

Thank you @igiannakas

I have two feedback:

1. I think a warning in Print::validate is sufficient.
2. It's probably better to check whether all used filaments have same shrinkage value? e.g. if all used filaments has 98% shrinkage, then they should just work fine. There is a way to get what filaments are used in this print, I cant' remember whether the info is available before the validation check at the moment though.

[igiannakas]

I tried it by checking if the extruders have the same shrink comp value but the algo fails even if the shrink value is the same:

I've pushed the latest update removing the slice time message :)

[igiannakas]

My hunch is that the subsequent polygon segmentation ops dont like the polygons having moved.

Also if memory is not failing me, I've noticed that this: const size_t extruder_id = pr->extruder(FlowRole::frPerimeter) - 1; Returns all extruders when even one has shrink compensation enabled... Which is very very odd as I would have guessed the below correctly identifies the associated extruder but for some reason it appears not to.

unsigned int PrintRegion::extruder(FlowRole role) const
{
    size_t extruder = 0;
    if (role == frPerimeter || role == frExternalPerimeter)
        extruder = m_config.wall_filament;
    else if (role == frInfill)
        extruder = m_config.sparse_infill_filament;
    else if (role == frSolidInfill || role == frTopSolidInfill)
        extruder = m_config.solid_infill_filament;
    else
        throw Slic3r::InvalidArgument("Unknown role");
    return extruder;
}