"Found" this feature, thought I might share.

NTwoO · February 13

Sorry if I'm boring power users with knowledge that they are familiar with, but I stumbled on this and thought I might share.

During one of my projects and playing with TPU/PLA combinations I noticed the following feature. If two STLs are merged in the same material, the inner walls are sliced as separate walls and not filled as usual. At the time it was undesired and I solved it by generating the STLs as one for the material that was the same. A few months later I made a filament spool attachment for my drill that is shared on Thingiverse. The first version was made as one STL and the drill attachment simply snapped off. Remembering my multi STL use case. I used it here to make a far more durable solution.

The two models were imported into Cura. In OpenSCAD they are on the correct coordinates to merge with the hexagon fitting snugly in the part.

Below are the slicing results of the dual STL that were merged in Cura:

As comparison, here are the slice results if the part was imported as a single STL.

Slashee_the_Cow · February 13

This isn't really a Cura feature. OpenSCAD makes an implicit union of all parts, and when exporting an STL will only export a single, watertight mesh (at least, without errors). Especially with round sections, joining the two can create an average which is different to the individual parts.

For something like this, with rounded parts that need to be preserved properly, make sure you define $fn as something pretty high, generally at the start of your SCAD file:

$fn = $preview ? 64 : 2048;

That'll make previews not take forever and the actual rendering take foooooooreeeeeever with round objects by ensuring they have a ridiculously high number of facets but will also preserve as much of the resolution as possible. It will also give you a pretty damn massive file size (a single sphere exported with $fn at 2048 is over a 200MB file, so you may want to lower the 2048 slightly, but I usually go by powers of two - programming mindset - and definitely wouldn't go any lower than 512 for a high quality export - even at 1024 the sphere file size is a quarter that of the 2048, also make sure your value is evenly divisible by 4 so that the result can have integral co-ordinates) so it's maybe not always practical.