SCULPT_undo_push_begin no longer takes an explicit
name. Instead it takes a wmOperator pointer and uses
op->type->name for the name. This is necassary for
the redo panel to work and should fix the entire class
of bugs related to misspelled undo push names.
Cases where the calling operator is not registered
may use SCULPT_undo_push_begin_ex if desired; it
takes a name string as before.
With libepoxy we can choose between EGL and GLX at runtime, as well as
dynamically open EGL and GLX libraries without linking to them.
This will make it possible to build with Wayland, EGL, GLVND support while
still running on systems that only have X11, GLX and libGL. It also paves
the way for headless rendering through EGL.
libepoxy is a new library dependency, and is included in the precompiled
libraries. GLEW is no longer a dependency, and WITH_SYSTEM_GLEW was removed.
Includes contributions by Brecht Van Lommel, Ray Molenkamp, Campbell Barton
and Sergey Sharybin.
Ref T76428
Differential Revision: https://developer.blender.org/D15291
In practice this is harmless as in most cases checking selected
vertices is enough, however as the intention is to check all 3 elements
it's best to do so.
This commit moves the hide status of mesh vertices, edges, and faces
from the `ME_FLAG` to optional generic boolean attributes. Storing this
data as generic attributes can significantly simplify and improve code,
as described in T95965.
The attributes are called `.hide_vert`, `.hide_edge`, and `.hide_poly`,
using the attribute name semantics discussed in T97452. The `.` prefix
means they are "UI attributes", so they still contain original data
edited by users, but they aren't meant to be accessed procedurally by
the user in arbitrary situations. They are also be hidden in the
spreadsheet and the attribute list by default,
Until 4.0, the attributes are still written to and read from the mesh
in the old way, so neither forward nor backward compatibility are
affected. This means memory requirements will be increased by one byte
per element when the hide status is used. When the flags are removed
completely, requirements will decrease when hiding is unused.
Further notes:
* Some code can be further simplified to skip some processing when the
hide attributes don't exist.
* The data is still stored in flags for `BMesh`, necessitating some
complexity in the conversion to and from `Mesh`.
* Access to the "hide" property of mesh elements in RNA is slower.
The separate boolean arrays should be used where possible.
Ref T95965
Differential Revision: https://developer.blender.org/D14685
Migrate island calculation to #bm_uv_build_islands.
Simplify connectedness calculation.
Reduce memory pressure.
No functional changes.
See also: D15598
The specific functions for vertex colors and and sculpt vertex colors
can be replaced by more generic attribute functions internally.
Also remove a paramter from one function.
The "Color Attributes" system from f7bbc7cdbb has replaced
both "Sculpt Vertex Colors" and "Vertex Colors" in the UI. The Operators
for adding and removing them are unused now.
This commit does not break backwards compatibility with the Python
API, it only removes the operators, which generally aren't used by
addons anyway. The mesh RNA properties will be removed in 4.0 (T100153).
Differential Revision: https://developer.blender.org/D15077
In some cases it is mandatory to be able to hide parts of the mesh
in order to paint certain areas. The Mask modifier doesn't work in
weight paint, and edit mode hiding requires using selection, which
is not always convenient.
This makes the weight and vertex paint modes always respect edit mode
hiding like sculpt mode. The change in behavior affects drawing and
building paint PBVH. Thus it affects brushes, but not menu operators
like Smooth or Normalize.
In addition, this makes the Alt-H shortcut available even without
any selection enabled, and implements Hide for vertex selection.
Differential Revision: https://developer.blender.org/D14163
This commit adds a new face nearest snapping mode, adds new snapping
options, and (lightly) refactors code around snapping.
The new face nearest snapping mode will snap transformed geometry to the
nearest surface in world space. In contrast, the original face snapping
mode uses projection (raycasting) to snap source to target geometry.
Face snapping therefore only works with what is visible, while nearest
face snapping can snap geometry to occluded parts of the scene. This new
mode is critical for retopology work, where some of the target mesh
might be occluded (ex: sliding an edge loop that wraps around the
backside of target mesh).
The nearest face snapping mode has two options: "Snap to Same Target"
and "Face Nearest Steps". When the Snap to Same Object option is
enabled, the selected source geometry will stay near the target that it
is nearest before editing started, which prevents the source geometry
from snapping to other targets. The Face Nearest Steps divides the
overall transformation for each vertex into n smaller transformations,
then applies those n transformations with surface snapping interlacing
each step. This steps option handles transformations that cross U-shaped
targets better.
The new snapping options allow the artist to better control which target
objects (objects to which the edited geometry is snapped) are considered
when snapping. In particular, the only option for filtering target
objects was a "Project onto Self", which allowed the currently edited
mesh to be considered as a target. Now, the artist can choose any
combination of the following to be considered as a target: the active
object, any edited object that isn't active (see note below), any non-
edited object. Additionally, the artist has another snapping option to
exclude objects that are not selectable as potential targets.
The Snapping Options dropdown has been lightly reorganized to allow for
the additional options.
Included in this patch:
- Snap target selection is more controllable for artist with additional
snapping options.
- Renamed a few of the snap-related functions to better reflect what
they actually do now. For example, `applySnapping` implies that this
handles the snapping, while `applyProject` implies something entirely
different is done there. However, better names would be
`applySnappingAsGroup` and `applySnappingIndividual`, respectively,
where `applySnappingIndividual` previously only does Face snapping.
- Added an initial coordinate parameter to snapping functions so that
the nearest target before transforming can be determined(for "Snap to
Same Object"), and so the transformation can be broken into smaller
steps (for "Face Nearest Steps").
- Separated the BVH Tree getter code from mesh/edit mesh to its own
function to reduce code duplication.
- Added icon for nearest face snapping.
- The original "Project onto Self" was actually not correct! This option
should be called "Project onto Active" instead, but that only matters
when editing multiple meshes at the same time. This patch makes this
change in the UI.
Reviewed By: Campbell Barton, Germano Cavalcante
Differential Revision: https://developer.blender.org/D14591
The transformation snapping code contains a bunch of `#define`s, some ambiguously or incorrectly named attributes. This patch contains refactored code to improve this. This patch does (should) not change functionality of snapping.
Clarified ambiguously / incorrectly named attributes.
- "Target" is used to refer to the part of the source that is to be snapped (Active, Median, Center, Closest), but several other areas of Blender use the term "target" to refer to the thing being snapped to and "source" to refer to the thing getting snapped. Moreover, the implications of the previous terms do not match the descriptions. For example: `SCE_SNAP_TARGET_CENTER` does not snap the grabbed geometry to the center of the target, but instead "Snap transforamtion center onto target".
- "Select" refers to the condition for an object to be a possible target for snapping.
- `SCE_SNAP_MODE_FACE` is renamed to `SCE_SNAP_MODE_FACE_RAYCAST` to better describe its affect and to make way for other face snapping methods (ex: nearest).
Refactored related `#define` into `enum`s. In particular, constants relating to...
- `ToolSettings.snap_flag` are now in `enum eSnapFlag`
- `ToolSettings.snap_mode` are now in `enum eSnapMode`
- `ToolSettings.snap_source` (was `snap_target`) are now in `enum eSnapSourceSelect`
- `ToolSettings.snap_flag` (`SCE_SNAP_NO_SELF`) and `TransSnap.target_select` are now in `enum eSnapTargetSelect`
As the terms became more consistent and the constants were packed together into meaningful enumerations, some of the attribute names seemed ambiguous. For example, it is unclear whether `SnapObjectParams.snap_select` referred to the target or the source. This patch also adds a small amount of clarity.
This patch also swaps out generic types (ex: `char`, `short`, `ushort`) and unclear hard coded numbers (ex: `0`) used with snap-related enumerations with the actual `enum`s and values.
Note: I did leave myself some comments to follow-up with further refactoring. Specifically, using "target" and "source" consistently will mean the Python API will need to change (ex: `ToolSettings.snap_target` is not `ToolSettings.snap_source`). If the API is going to change, it would be good to make sure that the used terms are descriptive enough. For example, `bpy.ops.transform.translate` uses a `snap` argument to determine if snapping should be enabled while transforming. Perhaps `use_snap` might be an improvement that's more consistent with other conventions.
This patch is (mostly) a subset of D14591, as suggested by @mano-wii.
Task T69342 proposes to separate the `Absolute Grid Snap` option out from `Increment` snapping method into its own method. Also, there might be reason to create additional snapping methods or options. (Indeed, D14591 heads in this direction). This patch can work along with these suggestions, as this patch is trying to clarify the snapping code and to prompt more work in this area.
Reviewed By: mano-wii
Differential Revision: https://developer.blender.org/D15037
When the 'compare' is not used for the resulting selection, just hide
it. This is the case for 'Vertex Groups' atm (where only membership is
taken into account).
Similar to rB9dc9692b0979.
Differential Revision: https://developer.blender.org/D14979
Regression in [0] which removed the call to BVH-tree recalculation
before calculating the selection.
Instead of recalculating the BVH-tree, postpone recalculating mesh data
until after the selection has been calculated.
[0]: 6e77afe6ec
Added in [0] but isn't needed as all needed variables are in the
ViewContext. Avoid passing in the context is it makes debugging
issues with MESH_OT_knife_project more difficult to investigate since
it's possible values written to the ViewContext are ignored.
[0]: 6e77afe6ec
Headers should only include other headers when absolutely necessary,
to avoid unnecessary dependencies and increasing compile times.
To make this change simpler, three DerivedMesh functions with a single
use were removed.
