... because the extruders used for the current object can change (clear all bits of extruder #2 paint on a single object, which results in the object printed with extruder #1 only, which could result in the prime-tower needing to be gone -- or the other way around).
The _previous_ way of doing that was just spamming the stack changes, but that gave other problems.
part of CURA-12752
CURA-12752
The previous method was not efficient enough in case of large models, where a single painting stroke can easily cover almost the whole texture (in bounding box). Reverted to the version where the whole texture is counted, but cached in the SliceableObjectDecorator and updated on timer so that it is not done during painting.
Rewrite the whole 'count pixels to get extruders for paint on materials' so that it's cached outside of the extruder manager instead, so that counting pixels in a 4096x4096 image isn't called xx of times per second.
part of CURA-12752
(Not sure I'm happy with this, but) now we can use this _both_ in the slicing itself _and_ the bounds. The big downsides are a) I had to connect the scene changed signal to the on-stack-changed method, that seems ugly and potentially slow b) I'm not sure this method belongs in the ExtruderManager -- otoh, where else is it going to live (unless we want to make a new type of plugin-object?).
CURA-12752
Since both of them where a different render type (solid versus transparent) the sorting didn't work. Make them both transparent. (Though no changes where made there, see also UM/Scene/Platform -- which is not to be confused with UM/Platform.)
should fix CURA-12188
Cura lowers the available build volume height when more than 1 model is loaded. This count should include grouped nodes as one (since they will be slice as one and thus not affect the gantry), and should not include modifier meshes or support meshes (since support-meshes are always printed with the first model anyway).
Fixes https://github.com/Ultimaker/Cura/issues/16566
The solution is to do only one of these options.
Removing the disallowed area works fine when scaling models from their center. However we scale 2 or more models from the buildplate center rather than the model center. This means that the models can go outside the buildplate without it being obvious from the visualization.
The better solution is to remove the buildplate x/y scaling and keep the disallowed areas.
Removed shrinkage factor build volume scaling on x and y. This information is shown already by scaling the allowed areas around the objects.
Kept the bounding box scaling for z. This shows the max height a model can be. The objects disallowed area does not show this information.
Also removed scaling on non model disallowed areas on the build plate since this does not need to scale with the build plate anymore.
CURA-9271
Conflicts:
cura/PlatformPhysics.py -> Removed shapely on master, while QTimer import got updated to Qt6.
plugins/Toolbox -> Entire folder is deleted in master, but it was updated to Qt6 here. This can all be removed.
We need the raft thickness to determine the maximum height of the model. If using multiple interface layers, this height should be reduced.
Contributes to issue CURA-8915.
Material shrinkage now alters both the disallowed areas+, and the blue wireframe, toghether repressenting the usable build-volume. This doesn't shrink the build-plate/printer model, still keeping in line with the 'show the size of the result object in Prepare, not the resized one we do print becasue it will shrink later' principle we had originally agreed on enough. Note that the disallowed areas also take the object themzelves into account, so the user could still tell when objects are going to be printed overlapped (as the dissalowed areas of those respective models then overlap -- but not, of course, the models themselves).
part of CURA-8083
