While I do understand the logic behind this behaviour, I'm wondering if I'm missing something in terms of being able/not able to make S3D do what I wished in this particular case.
When selecting a raft, S3D clearly "looks upwards" and only puts a raft layer underneath "parts that have to be printed". In case you have only one print process, that's fine : a raft will be created underneath the complete printable part, no matter the Z-height of the first printable item of that part. In this case, this looks like this (picture "full raft 1")
However, when I create a multi-process printjob of it, the moment I select an end point for the first of the processes, raft calculation will be done based upon the "amount of part being printed up until that moment". So in my case, here I started a new process after concluding the first one at 10mm. As such, S3D now only places a raft underneath that part of the object that will be printed by the end of process 1, but it will NOT print a raft underneath what as to be printed in process 2. (picture "no full raft")
Okay, this COULD be interesting sometimes, but the main issue is that for some reason, S3D will not allow the support structure that is lacking support due to the decission of process 1 to be placed on the bed starting the first line of that area of support printing : S3D will in fact "float" the support structures in air and only start printing them once the raft structures defined by process 1 are been printed. Of course, those structures have like a snowball in hell chance of bed adhesion :
Yes, I could solve this by placing a "helper surface" underneath the spaces where process 1 skips raft creation, but is there a way to force S3D into attaching those support structures to the bed at "Z=0" instead of magically letting them print in the air and hoping they'll somehow attach themselves to the printbed ? And please no "rafts are bad and ect ect ect". I don't like using rafts any more than most of you, but sometimes it's a necessary evil : just want to be sure i'm not missing something obvious here.