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

igiannakas · 2024-06-20T12:24:44Z

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 · 2024-06-20T13:26:33Z

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 · 2024-06-20T13:37:19Z

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 · 2024-06-20T13:50:21Z

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

Cancel slicing with the error "Filament shrinkage must be equal"
Calculate the average shrinkage from all used filaments
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 · 2024-06-20T14:02:46Z

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 · 2024-06-20T14:06:04Z

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

igiannakas · 2024-06-20T14:15:35Z

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 · 2024-06-20T14:18:23Z

Mmm let me try something different

SoftFever · 2024-06-20T15:09:26Z

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 · 2024-06-20T16:23:00Z

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 🥳

igiannakas · 2024-06-20T16:25:18Z

src/libslic3r/PrintObjectSlice.cpp

        }
    }
+    if(display_shrinkage_comp_error){


@SoftFever this is the slice time messsage here

igiannakas · 2024-06-20T16:25:39Z

src/libslic3r/Print.cpp

+            }
+        }
+        if (filament_shrinkage_found){
+            warning->string = L("Filament shrinkage compensation is incompatible with multi color and multi material prints. It will be ignored when printing this model.");


And the validate message here :)

…on-for-multicolor/material-prints

ExR90 · 2024-06-22T08:18:34Z

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 · 2024-06-22T08:52:22Z

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 · 2024-06-22T08:53:27Z

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

bottom of the page.

ExR90 · 2024-06-22T09:57:09Z

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 · 2024-06-22T10:02:54Z

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 · 2024-06-22T10:22:11Z

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 · 2024-06-22T10:26:05Z

Your project file attached above is slicing OK for me:

Honestly I'm lost as cannot reproduce it :(

@SoftFever any thoughts?

ExR90 · 2024-06-23T00:44:09Z

@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 · 2024-06-23T06:41:56Z

I’m on an M1 Pro MacBook…

ExR90 · 2024-06-23T07:03:13Z

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 · 2024-06-23T09:27:42Z

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 · 2024-06-23T10:37:42Z

@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 · 2024-06-23T22:23:19Z

@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 · 2024-06-23T22:25:09Z

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 · 2024-06-24T02:06:33Z

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.

…rink-compensation-for-multicolor/material-prints

igiannakas · 2024-06-25T20:21:23Z

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

…ticolor/material-prints

SoftFever · 2024-06-25T22:58:09Z

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

Maximizer18 · 2024-06-26T00:03:14Z

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

ExR90 · 2024-06-26T04:32:43Z

@igiannakas @SoftFever

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

…on-for-multicolor/material-prints

SoftFever · 2024-06-29T05:34:43Z

Thank you @igiannakas

I have two feedback:

I think a warning in Print::validate is sufficient.
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 · 2024-06-29T08:50:04Z

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 :)

…rink-compensation-for-multicolor/material-prints

igiannakas · 2024-06-29T08:53:18Z

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;
}

…rink-compensation-for-multicolor/material-prints

SoftFever · 2024-06-30T16:08:07Z

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;
}

I see.
Thank you for digging deep into the issue.
I'm thinking it might be better to port PrusaSlicer's new implementation when any of us have time: prusa3d/PrusaSlicer@4b8fe98

I feel that is a better implementation.
What do you think?

igiannakas · 2024-06-30T16:28:59Z

Oooh that looks nice!

igiannakas · 2024-06-30T16:34:09Z

Seems pretty straightforward to port - I’ll have a go at it next week/ the week after once I get a bit of free time from work :)

closing this PR as there is a better way forward.

igiannakas added 2 commits June 20, 2024 14:19

Disable filament shrink compensation for multicolor/material prints

e9baab6

Updated tooltip

1357773

igiannakas marked this pull request as ready for review June 20, 2024 12:26

igiannakas changed the title ~~Disable filament shrink compensation for multicolor/material prints~~ Disable filament shrink compensation for multicolor/material prints which was causing incorrect colour segmentation. Jun 20, 2024

igiannakas changed the title ~~Disable filament shrink compensation for multicolor/material prints which was causing incorrect colour segmentation.~~ Bug fix: Disable filament shrink compensation for multicolor/material prints which was causing incorrect colour segmentation. Jun 20, 2024

Two options for warning message

c7c3a39

igiannakas commented Jun 20, 2024

View reviewed changes

Merge branch 'SoftFever:main' into Disable-filament-shrink-compensati…

bce763c

…on-for-multicolor/material-prints

igiannakas added 2 commits June 24, 2024 19:24

Merge remote-tracking branch 'upstream/main' into Disable-filament-sh…

8e852f4

…rink-compensation-for-multicolor/material-prints

Merge remote-tracking branch 'upstream/main' into Disable-filament-sh…

1ef5bc7

…rink-compensation-for-multicolor/material-prints

Merge branch 'main' into Disable-filament-shrink-compensation-for-mul…

79b26a1

…ticolor/material-prints

Merge branch 'SoftFever:main' into Disable-filament-shrink-compensati…

a9265b2

…on-for-multicolor/material-prints

igiannakas added 2 commits June 29, 2024 09:51

Updated shrink compensation notification structure

3117f83

Merge remote-tracking branch 'upstream/main' into Disable-filament-sh…

3af5018

…rink-compensation-for-multicolor/material-prints

igiannakas added 2 commits June 29, 2024 10:04

Updated comments

93e073d

Merge remote-tracking branch 'upstream/main' into Disable-filament-sh…

af19aa7

…rink-compensation-for-multicolor/material-prints

igiannakas closed this Jun 30, 2024

igiannakas deleted the Disable-filament-shrink-compensation-for-multicolor/material-prints branch June 30, 2024 16:34

igiannakas restored the Disable-filament-shrink-compensation-for-multicolor/material-prints branch July 1, 2024 14:06

igiannakas mentioned this pull request Aug 19, 2024

Ported filament shrinkage compensation for XY and independent Z from Prusa Slicer (fixing MMU painting, seam painting, support painting issues) #6507

Merged

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

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

Conversation

igiannakas commented Jun 20, 2024 • edited Loading

Description

Tests

BioCookieYT commented Jun 20, 2024

igiannakas commented Jun 20, 2024

BioCookieYT commented Jun 20, 2024

igiannakas commented Jun 20, 2024

SoftFever commented Jun 20, 2024

igiannakas commented Jun 20, 2024

igiannakas commented Jun 20, 2024

SoftFever commented Jun 20, 2024

igiannakas commented Jun 20, 2024 • edited Loading

igiannakas Jun 20, 2024

Choose a reason for hiding this comment

igiannakas Jun 20, 2024

Choose a reason for hiding this comment

ExR90 commented Jun 22, 2024

igiannakas commented Jun 22, 2024

igiannakas commented Jun 22, 2024

ExR90 commented Jun 22, 2024

ExR90 commented Jun 22, 2024

igiannakas commented Jun 22, 2024

igiannakas commented Jun 22, 2024

ExR90 commented Jun 23, 2024

igiannakas commented Jun 23, 2024

ExR90 commented Jun 23, 2024

igiannakas commented Jun 23, 2024

igiannakas commented Jun 23, 2024

Maximizer18 commented Jun 23, 2024

Maximizer18 commented Jun 23, 2024

ExR90 commented Jun 24, 2024

igiannakas commented Jun 25, 2024 • edited Loading

SoftFever commented Jun 25, 2024

Maximizer18 commented Jun 26, 2024

ExR90 commented Jun 26, 2024

SoftFever commented Jun 29, 2024

igiannakas commented Jun 29, 2024

igiannakas commented Jun 29, 2024 • edited Loading

SoftFever commented Jun 30, 2024

igiannakas commented Jun 30, 2024 • edited Loading

igiannakas commented Jun 30, 2024

igiannakas commented Jun 20, 2024 •

edited

Loading

igiannakas commented Jun 20, 2024 •

edited

Loading

igiannakas commented Jun 25, 2024 •

edited

Loading

igiannakas commented Jun 29, 2024 •

edited

Loading

igiannakas commented Jun 30, 2024 •

edited

Loading