What is this weird grey in BS that sits between outer wall and support?

[NeverDie]

It doesn’t appear in the color legend:

In this case, it sits between the orange outer wall and the light green support line.
As near as I can tell, it’s just empty space, but it has this curious shape to it tht starts very thin at the bottom and then gets thicker the higher it goes…until it gets truncated at the top.

It’s relevant to me because I can’t seem to get rid of this even if I were to set XY distance spacing on the support material to either near zero or zero, and consequently it leads to a problem with the second layer dispensing a support material there as a kind of bridge–which is made from a different filament (seen below in dark green):

or as light green if you look in the summary preview:

and I’d rather not have that happening, because it doesn’t always stick particularly well in this location and it’s an unnecessary filament switch. If it has to do it, I’d rather it just stick with PLA in this particular place. Unfortunately, I don’t see a way to modifier my way out of this, though maybe there is a way that I’m just not groking.

I guess it’s technically “support interface”. I tried to eliminate it by turning bottom support interface to zero layers,

but it persists anyway. And if I increase “bottom interface spacing”, it merely kicks the same problem to the next print level.
I suppose I could use a support blocker, and tried that a couple of times, but I have trouble orientating that across the entire model, because this problems repeats throughout the entire perimeter of the printer model.

“Height range modifier” would be the other approach I’ve tried, but it doesn’t seem to allow suppressing supports as part of it.

So, aside from being yet another reason I wish we could use orca slicer or prusa slicer, is there any solution, or will I just have to live with it until the BS slicer is someday improved?

Attached is the project file in case you want to play around with it or see for yourself.
2025Dec027__1345___posted.3mf (1.5 MB)

I suppose if I were to paste over the entire first layer periphery with mouse ears, I’d crush the problem that way, but that’s pretty radical. Or I could elminate automatic support generation and switch to painted-only supports, but that would be extra work and I’m not sure it would make any difference in this case.

Grok 4.1 thinks the answer is to reduce XY model distance to zero, but that comes with side effects. On the other hand, Chatgpt 5.2 complains that bambulab is preventing it from reading a link to this post and gives it a 402 instead. So, I fed it screen scrapes, and it maybe (?) nailed it:

Trying that: nope, it made no difference.

[eried]

Dont you think that grey color is just the reference 3d model that is very faded?

[Impeller_Warehouse]

So the problem here is that the slicer is placing supports on top of the circular bits of your model, and thus it puts in a support interface. Enabling “On build plate only” gets rid of this problem, but since you don’t have tree supports selected, some areas don’t get support at all since normal supports can’t “branch out” and overhang already printed parts.

[NeverDie]

Yes, that and it would be too steep an angle for the tree supports to reach if “on build plate only” were selected.

I turned off “on build plate only” because I want allow the supports to print on top of the mouse ears I merged into the model.

[Impeller_Warehouse]

Although it doesn’t really make sense that it would put support interface on the wall of the model, but not on the surface?

[NeverDie]

I didn’t use the machine generated mouse ears, such as by painting them on, because then the supports would decimate them.

Currently printing, but here’s the bigger context: This shows supports where I want them:

The spurious supports I reference above are covered over at this point, so they aren’t visible.

The merged mouse ears are functioning as an effective anti-warp/anti-curl measure by strongly anchoring the print to the build plate. Since they’re only one layer thick, they pull off fairly easily after the print is done. The print model itself is close to the maximum XY size that the H2D can accomodate, so even PLA can warp/curl at that size without countermeasures. The strategy I’m following is to interrupt long lines as much as possible, which is why I prefer this approach over brims.

[Impeller_Warehouse]

This is such a weird thing for the slicer to do. It seems it is generating supports (more like bridges) FOR the supports. Obviously there is no way to customize the support settings for supports, so some other setting is gonna have to modify this. I am still tinkering around with settings to find a solution.

[NeverDie]

And for the benefit of those reading this who aren’t familiar with using mixed filaments for support, this photo is the money shot:

Using PETG as the support interface layer filament for PLA (or visa versa), makes for a very easy and very clean release when it comes to separating the final print from the supports. However, you need a good base for it to build upon, precisely because they don’t stick that well together. You could build the entire support, including the interface layer, out of a single filament type, but then you’d waste a lot of time with switching filament as the model gets printed. Limiting it to just the interface layer reduces that “wasted” time to a minimum.

[Impeller_Warehouse]

Yeah, just got a P2S Combo and I haven’t had to print a model with different materials yet, but soon maybe. Can only imagine the quality increase having that support gap set to 0. Also still not much progress on stopping that pesky support interface.

[NeverDie]

@Impeller_Warehouse

Can only imagine the quality increase having that support gap set to 0.

Yes, I think you’ll find it’s well worth it, especially when you have a huge ceiling to support or something like that.

[Impeller_Warehouse]

I have dug around a lot and researched a lot, and it seems this is a bug. I think the slicer for some reason is interpreting the support on top of the cylinders (2) very close to the edge as overhanging. So it puts in the support interface (1) as if it was a overhang that it is supporting from the bottom.

This is most certainly not a bottom interface layer as those settings are working properly. Modifiers for some reason don’t allow the control of support within a specific area or block the use of a material, which would have fixed this situation.

Unfortunately, no work arounds seem to be present unless the mouse ears are replaced with a brim or their geometry is altered in a similar way, such that all supports are either generated not on the mouse ears or on them.

[NeverDie]

Thanks! At least it’s not just me then.

FWIW, both Orca Slicer and Prusa Slicer offer more control than the current version of Bambu slicer, and it sure seems like that gap in capability is growing, not shrinking. Just sayin’. Now whenever people say “Who needs Orca slicer anyway? Isn’t Bambu Slicer just as good?” I’ll post a link to this page as an example. I wish I didn’t need to, but when you get into the more advanced levels of control, the differences become a lot more clear, as well as who is leading and who is struggling to keep up. The sad thing is we’d still have Orca slicer if Bambu hadn’t shut them out so blatantly.