[CURA-10407] Introduce fractional layer-height support gaps #1955
Conversation
First see if the part of the support (interface only for now) that should (perhaps) be a bit lower if the support z gap is not a multiple of the layer height, can actually be lowered at all without upending the code too much. This turns out to be possible. Next is actually setting the proper gap height (or what's left of the gap after already dropping down to the layer that needs to be a fractional height.) Proof of concept mostly in the sense that the quality of the code added may not reflect our standards, and would also be missing functionality (for instance; what if we print without support-interface). part of CURA-11041, which is the proof-of-concept for CURA-10407
Instead of half-height layers in each area that could potentially be affected by non-layer-height modulo support z distance, actually calculate the proper z-offset that is needed for the fractional layer. Proof of concept mostly in the sense that the quality of the code added may not reflect our standards, and would also be missing functionality (for instance; what if we print without support-interface, or tree-support at all). part of CURA-11041, which is the proof-of-concept for CURA-10407
…ine-fill. Part of the partial layer-height support distance proof of concept: CURA-11041
belatedly part of CURA-11041 Co-authored-by: Casper Lamboo <[email protected]>
boyscouting CURA-11110
Implementation is not fully desired since it has some downsides 1. When a layer-part is partially a roof the whole outer/inner wall uses the inner/outer wall roofing print-configuration 2. Some logic is duplicated, namely the function that calculates the `filled_area_above`. This function previously lived in `SkinInfillAreaComputation`. It's not logical to create a `SkinInfillAreaComputation` instance just to re-use this utility. Proposal to fix this is to move the logic of calculating the `filled_area_above` to a more central location, this will be done in a seperate ticket. 3. The `inset0_roofing_config` and `insetX_roofing_config` contain `line_width` properties. Changing the line-widths here doesn't actually change the line width. The line widths can only be changed through the `insetX_config` and `inset0_config` configs CURA-11110
Take care of the ordering before it gets to all the order optimizers. part of CURA-10407
while working on CURA-10407
There's some code duplication that needs to be consolidated, so refactor the 'copy' (or original rather) so it's like the others and can be easily combined into one funciton. While that was being done, found that the booleans weren't flipped after the order of the input array was changed. (In order to print the lower bits _first_, _then_ the 'normal' support. part of CURA-10407
done as part of CURA-10407
Take care of the order optimizer w.r.t. partially fractional-height support-layers. part of CURA-10407
The code was attempting to access an index that was out of bounds of the array. Add guards to prevent this access. CURA-11041
|
I'm afraid the current implementation breaks the supports with a 0 Z-distance (which works properly in 5.5): |
|
Also there is a strange behavior: when I set a 0.2mm Z-distance with a 0.1mm layer height, I get only one empty layer between support and model. On 5.5 I get two empty layers as I would expect. |
|
The last two may be related -- there could be an off-by-one error? |
|
Yeah maybe :) It looks like the "intermediate" layer height grows in the wrong direction. When reducing the gap, the layer becomes sparser, which should be the opposite. |
|
... haha oh no, that's a bit embarrassing. It does sort of explain all the other bugs as well though. |
|
Yeah I think it's all the same problem, and it should be easy to fix. |
|
Forget my last comment... When the gap grows, the intermediate layer becomes sparser. That is expected. But when it finally become null-height, then it is printed as if it was full height. |
|
I see. Still probably an easy fix, just avoid the 'exactly zero' scenario. |
|
Just tested new version : 0mm gap works again, but now it does not take care about the "full" layers for the gap: actual maximum distance between support and model is at most 0.99*layer_height |
|
Last commit should fix that, I think. Tested it with support roof on and 0.2 layer height, gaps of 0.4, 0.45, 0.55, 0.6 all gave the expected results (z gaps of; 2 full layers, 2+ layers, 2+ layers, 3 full layers respectively). edit Oh, and 0mm works as well. The top layer does get split into parts 'just below model' and other parts, but I'm not sure if that's a problem, as it does have continuity with the other behaviour. |
Support gaps (z distance) between the model(s) and the support can be non-multiples of layer-heights now.