This Cura logic looks weird. Fill density is a percentage (0-100).

This Cura logic looks weird. Fill density is a percentage (0-100). Here we see 100something1000/fill_density…huh??? It seems like it should be fill_density*something/1000 or something like tht.

            if profile.getProfileSettingFloat('fill_density') == 0:
                    settings['sparseInfillLineDistance'] = -1
            elif profile.getProfileSettingFloat('fill_density') == 100:
                    settings['sparseInfillLineDistance'] = settings['extrusionWidth']
                    #Set the up/down skins height to 10000 if we want a 100% filled object.
                    # This gives better results then normal 100% infill as the sparse and up/down skin have some overlap.
                    settings['downSkinCount'] = 10000
                    settings['upSkinCount'] = 10000
            else:
                    settings['sparseInfillLineDistance'] = int(100 * profile.calculateEdgeWidth() * 1000 / profile.getProfileSettingFloat('fill_density'))

@Daid_Braam , I know you’re no code tutor, but you have any recollection why that’s like that specifically?

The profile.calculateEdgeWidth seems to have odd logic in it too. I think between the two, the funky infill issues people have and the occasional failure to mesh with the outer walls may occur.

Makes total sense, but the order is a bit odd I guess.

We need to calculate the distance between the infill lines. At 100% infill the distance between the infill lines is the width of the lines. At 0 infill, this distance should be infinity. (hence the special case for 0)
At 50% infill, you want twice the distance between the center of the infill lines, compared to the width of the lines. So, width * (1/0.5), or with*(1/(50/100))

The * 1000 is to get the value in microns.

But the formula is: lineWidth * (1 / (fill / 100)) * 1000, but instead of dividing a divider by 100, you can multiply the initial value by 100 and get the same result.

Now, as I usually deal with integer math, my mind kinda defaults to putting the multiplies first to prevent rounding. In this case, it just makes for harder to read code.

(And so far, I’ve been able to link just about any “infill not connecting” issue to mechanical backlash)