1. Do not show what's below the bed when a gizmo is open
2. Triangulate the cut so people don't see inside
3. If regular clipping plane is used, the cuts are mutually clipped by one another
4. Painting itself ignores the hidden part of the object
on_is_selectable and on_is_activable functions are now completely independent,
the former says if there shall be an icon in the left toolbar, the latter
says if the gizmo can be activated (by a shortcut or GLGizmoManager::open_gizmo)
Make is_converted_from_meters / is_converted_from_inches exclusive-or.
Maybe it would be better to make a single enum from the two booleans,
if they are exclusive-or?
This reverts commit d001195ebd. It makes no sense,
reload from disk is used when the file has changed, which means the paint-on
data are possibly meaningless or even completely wrong (referencing
triangles that no longer exist)
It is now possible to use e.g. --ensure-on-bed=0 for bools (meaning the same as --no-ensure-on-bed).
Using --no- prefix on non-boolean is an error (--no-ensure-on-bed=1)
Providing a value for --no- prefixed bool is an error (--no-loglevel 5)
'dont-ensure-on-bed' (which allows to override). This was the original
behaviour in Slic3r and Sli3rPE, probably broken long ago when CLI
was ported from Perl.
Also, --scale-to-fit should now work again (#5772)
when the respective object info line was clicked, the variable
layer height mode was opened correctly, but closing it through
the toolbar deactivated most of the icons as if it was just opened.
Filtering of unprintable regions in multi-material segmentation depends on if gap-fill is enabled or not. So sliced object is invalidated when gap-fill was enabled/disabled by option "gap_fill_enabled" or by changing "gap_fill_speed" to force recomputation of the multi-material segmentation.
For Apple's on Arm CPU computed triangle normals inside fragment shader using dFdx and dFdy has the opposite direction. Because of this, objects had darker colors inside the multi-material gizmo.
Based on https://stackoverflow.com/a/66206648, the similar behavior was also spotted on some other devices with Arm CPU.
1) Polished up wording of the error messages.
2) Made some messages in the SysInfo dialog localized.
3) Renamed LibraryCheck.cpp/hpp to BlacklistedLibraryCheck.cpp/hpp
4) CPPized the BlacklistedLibraryCheck WIN32 C code.
