For fixing the paint-splatter issue Iswitched to a new way of drawing the polygon, which could result in missed strokes of pixels at the edge of (UV) polygons. This change should catch most of the remaining X% where that happened.
done as part of CURA-12662
It was using the old (well, relatively speaking ... from the start of development of the current paint-epic) getIntersectRatioViaPt (three times no less), which was massive overkill for what we're trying to accomplish here.
done as part of CURA-12662
Using the camera is more standard, and while it has some downsides ('smearing'/large skews on surfaces angled away from the camera) it seems to have the least quirks (or at least ones that users are used to already). -- Also the what was here previously was just wrong, I'm just saying it could in theory have been solved the way I originally wanted to, but that'd take a long time to get completely right and efficient.
part of CURA-12662
This fixes the issue that it wouldn't flood over the 'rim' whenever the endpoints of a stroke was wholly within one plane, but the stroke itself would overlapp another. Plus also handle click on single point and use transformed mesh consistantly.
part of CURA-12662
Various fixes applied; method of drawing changed a bit (use qpath, otherwise we can't fill, right-size the brush in various ways (w/h of UV-canvas taken into account, fix that 'stroke-coords' are _yet another_ coord system instead of the same as one of the existing) also, with the stroke; fix that it should have been a convex hull of the union, not a convex hull of the intersection -- also take the scale of the model into account (which we need to) (but this has a side-effect in that the brush is now always the same size, regardless of which size the object is -- makes sense, but not 100pct sure if wanted) -- various other things cleaned up etc.
part of CURA-12662
This prevents 'paint splatter', that is, previously, we had just a begin and an end point (actually we had a temp stopgap that iterated per triangle, but similar problems persisted), which we then mapped directly to UV and drew the stroke in that space. This causes the stroke to overlap parts of the UV-map that it didn't touch in 3D at all.
Now, we instead gather each triangle, map that to the estimated stroke plane, intersect the result with the stroke-shape, then map the resulting polygon back to UV-space.
At the moment this code isn't fully working yet -- but I solved all of the obvious things that can be wrong, and it could partially be that I based this branch off of a moment in time the other branch wasn't functionally properly.
part of CURA-12262
CURA-12660
The UV-unwrapping is now done in a background job, and the UI displays a waiting state. This fixes the issue where the user would start painting but the model was not ready yet, and the first stroke would be missing.
CURA-12660
This required a refactoring of the management of the active view. The previous behavior was that anyone could set the active view, depending on certain conditions. But now we also have a view that is set by a tool, so sometimes the actually set view would be incorrect. Now each Stage requests an active view, and each tool CAN also request an active view. Then the Controller decides which view should actually be active depending on the active stage and tool.
CURA-12660
The previous method actually doesn't work when Cura is packaged because the plugins paths change. This method is much safer, and uses the actual SolidView instance.
CURA-12660
When a message box is displayed, some offscreen rendering passes (face selection) render an unpredictable result and we are unable to start painting.
This went through a refactoring of the rendering passes. Since doing the offscreen rendering outside the Qt rendering loop caused some troubles, we now use the rendering passes only inside the Qt rendering loop, so that they work properly. Tools also have the ability to indicate which extra passes they require, so that we don't run all the passes when they are not required.
Since this issue also concerns the support blockers placement and rotation by face selection, they have been updated so that they now also always work.
The face selection mechanism using the Selection class was partially working and used only by the rotation, so now it has been deprecated in favor of the new mechanism.
