| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Error introduced in rB1edebb794b76.
In that commit it was kind of forgotten that the snap to grid is also
used in 3D views.
Also a refactoring and cleanup was applied to simplify the code.
|
|
The check for the flags should be `== 0` since they are describing a
negative state.
Thanks to @lone_noel for pointing out the error.
|
|
Part of a wider set of changes to Grid and Pixel snapping in the
UV Editor.
This change fixes snapping behavior for non-uniform grids, either
manually specified Fixed grids, or pixel grids where the underlying
image is non-square.
See a24fc6bbc1ae for visual changes.
Maniphest Tasks: T78391
Differential Revision: https://developer.blender.org/D16275
|
|
Do not save the "use_proportional_edit" property if it is not supported.
This prevents it from being automatically disabled.
And hide "use_proportional_edit" in `SPACE_NLA`
|
|
|
|
|
|
Error in rB236fda7faf58
|
|
Changes:
- Use the "snap_elements" property only for operators that support snapping to geometry.
- Remove unused properties:
- "use_snap_to_same_target",
- "snap_face_nearest_steps").
- Fix property with wrong name "use_snap_selectable_only" -> "use_snap_selectable"
- Fix use of dependent property flags.
- Remove redundant initialization of variables
- Simplify `poll_propety`. Only the "use_snap_project" is not hidden.
>>! In rBc484599687ba it's said:
> These options are needed for Python tools to control snapping without requiring the tool settings to be adjusted.
If that's the case, there doesn't seem to be any need to display them in the redo panel. Therefore:
- Hide snapping properties in redo panel.
Many properties have been added that can be independent of ToolSettings. Therefore:
- Save snapping properties in the operator itself. For Redo.
|
|
|
|
For example, allows a custom UV grid size of 4 x 12.
TODO: Fix snapping with custom UV grid sizes.
Manifest Tasks: T78391
Differential Revision: https://developer.blender.org/D16000
|
|
When a change happens which invalidates view layers the syncing will be postponed until the first usage.
This will improve importing or adding many objects in a single operation/script.
`BKE_view_layer_need_resync_tag` is used to tag the view layer to be out of sync. Before accessing
`BKE_view_layer_active_base_get`, `BKE_view_layer_active_object_get`, `BKE_view_layer_active_collection`
or `BKE_view_layer_object_bases` the caller should call `BKE_view_layer_synced_ensure`.
Having two functions ensures that partial syncing could be added as smaller patches in the future. Tagging a
view layer out of sync could be replaced with a partial sync. Eventually the number of full resyncs could be
reduced. After all tagging has been replaced with partial syncs the ensure_sync could be phased out.
This patch has been added to discuss the details and consequences of the current approach. For clarity
the call to BKE_view_layer_ensure_sync is placed close to the getters.
In the future this could be placed in more strategical places to reduce the number of calls or improve
performance. Finding those strategical places isn't that clear. When multiple operations are grouped
in a single script you might want to always check for resync.
Some areas found that can be improved. This list isn't complete.
These areas aren't addressed by this patch as these changes would be hard to detect to the reviewer.
The idea is to add changes to these areas as a separate patch. It might be that the initial commit would reduce
performance compared to master, but will be fixed by the additional patches.
**Object duplication**
During object duplication the syncing is temporarily disabled. With this patch this isn't useful as when disabled
the view_layer is accessed to locate bases. This can be improved by first locating the source bases, then duplicate
and sync and locate the new bases. Will be solved in a separate patch for clarity reasons ({D15886}).
**Object add**
`BKE_object_add` not only adds a new object, but also selects and activates the new base. This requires the
view_layer to be resynced. Some callers reverse the selection and activation (See `get_new_constraint_target`).
We should make the selection and activation optional. This would make it possible to add multiple objects
without having to resync per object.
**Postpone Activate Base**
Setting the basact is done in many locations. They follow a rule as after an action find the base and set
the basact. Finding the base could require a resync. The idea is to store in the view_layer the object which
base will be set in the basact during the next sync, reducing the times resyncing needs to happen.
Reviewed By: mont29
Maniphest Tasks: T73411
Differential Revision: https://developer.blender.org/D15885
|
|
This patch is a cleanup required before refactoring the view layer syncing
process {T73411}.
* Remove FIRSTBASE.
* Remove LASTBASE.
* Remove BASACT.
* Remove OBEDIT_FROM_WORKSPACE.
* Replace OBACT with BKE_view_layer_active_object.
* Replace OBEDIT_FROM_VIEW_LAYER with BKE_view_layer_edit_object.
Reviewed By: mont29
Maniphest Tasks: T73411
Differential Revision: https://developer.blender.org/D15799
|
|
This reverts commits b72eddac6190353714745756dcc335f98cda1369 and
f8b5706a1ffe61ae3bdd949ad851d6e9ff3fe188.
And fixes T100265.
It brings more problems than solutions.
|
|
Caused by {rB791bfae1d64b}.
The solution was to create the special handle for the Move Clip and Mask
transformation.
One change that cannot be reversed is showing the `G` shortcut in the
statusbar.
But the description of this shortcut was not even correct before.
|
|
in Edit Mode
Add specific modal keyitem for Vert/Edge Slide or TrackBall.
Note that there is a workround to avoid repeated keys in the status bar.
Reviewed By: campbellbarton
Maniphest Tasks: T100129
Differential Revision: https://developer.blender.org/D15597
|
|
Simplify the transform code by bundling the TransData creation, Data
recalculation, and special updates into a single struct.
So similar functions and parameters can be accessed without special
type checks.
Differential Revision: https://developer.blender.org/D15494
|
|
Replace verbose ELEM(..) usage, now each kind of mouse event has it's
own macro.
|
|
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
|
|
Since [0], transform gizmos are no longer hidden during transform.
The same can be observed for rotation gizmos.
However, as a workaround for these rotation gizmos, there was already a
drawing utility running.
With the gizmo and the utility this drawing is now being done twice.
So remove the utility/workaround and update the gizmo accordingly.
[0] {648350e456490f8d6258e7de9bf94d3a6a34dbb2}
Differential Revision: https://developer.blender.org/D9542
|
|
into enums
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 interacting with translate/rotate/scale gizmo, show the gizmo while
it's in use. There are some exceptions to this, as showing all scale
gizmos while scaling causes the gizmos to become large & distracting so
in this case only the gizmo being dragged is shown.
Resolves T63743.
|
|
Now gizmos forward the original event to transform so assuming an LMB
event is no longer needed.
|
|
Avoid multiple `sound.bl_rna.properties["channels"].enum_items` in
the same line. Note we might want a way to avoid having to do this.
|
|
The change was kind of intentional on {rB21e72496a629}.
That commit made mouse movement to "select" the contraint in Auto
Constraint a requirement.
This deduplicated the code a bit, but this requirement is not
comfortable for the first "selection" of the contraint.
So the constraint "selection" is now done in two ways:
- If there is no contraint, the "selection" is done immediately;
- If there is already a constraint, the "selection" is delayed by 1 event to simulate a constraint cancellation if there is no mouse movement.
|
|
Replace 5 arguments with a single struct as the same arguments
are used in many places.
This didn't read well and was confusing with both arguments named
`val` & `value` in the case of WM_modalkeymap_add_item.
|
|
|
|
If the `Automatic Constraint` modifier was activated while an axis
constraint was already set, the orientation used would be the default
orientation of the mode and not that of the scene.
This was because the `initSelectConstraint` function was not called in
this case and the `Automatic Constraint` mode was enabled by other
indirect means.
So the solution is to call `initSelectConstraint` in either case and
remove these "indirect means" of enabling `Automatic Constraint`.
|
|
Contrary to the initial intention (in rB9916e0193c36), `TREDRAW_SOFT`
flag, when isolated, is not cleared in `transformApply` and therefore is
used in the `drawTransformApply` callback which basically recalculates
the `transformation` which finally clears the flag.
So remove the `drawTransformApply` callback so `transformApply` is not
called when unnecessary.
Differential Revision: https://developer.blender.org/D14430
|
|
This reverts commit 6cc83f9079de11ddb53af5bab3e0442a234aadb2.
That commit removed the feature of cancel the 'Auto Constraint'
if it is enabled without drag.
|
|
If the `Automatic Constraint` modifier was activated while an axis
constraint was already set, the orientation used would be the default
orientation of the mode and not that of the scene.
This was because the `initSelectConstraint` function was not called in
this case and the `Automatic Constraint` mode was enabled by other
indirect means
So the solution is to call `initSelectConstraint` in either case and
remove these "indirect means" of enabling `Automatic Constraint`.
|
|
After rB9b298cf3dbec, the `StructRNA` declarations can now be accessed via
`RNA prototypes.h`
Also, since all redundated declarations are now removed,
`_WM_MESSAGE_EXTERN_BEGIN` and `_WM_MESSAGE_EXTERN_END` are also no
longer needed.
Differential Revision: https://developer.blender.org/D14342
|
|
`3DView`'s `use_snap` option has little or nothing to do with using
snapping in `UV`, `Nodes` or `Sequencer`.
So there are no real advantages to keeping these options in sync.
Therefore, individualize the option to use snap for each "spacetype".
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D13310
|
|
Error in b8960267dd51f9108b3b49e9b762e6b4d35ae1dc,
the flag was cleared before use.
|
|
This avoids transform jumping which is a problem when tweaking values a
small amount. A fix for T40549 was made box-select used the location
when the key was pressed.
While it's important for box-select or any operator where it's expected
the drag-start location is used, this is only needed in some cases.
Since the event stores the click location and the current location,
no longer overwrite the events real location. Operators that depend on
using the drag-start can use this location if they need.
In some cases the region relative cursor location (Event.mval) now needs
to be calculated based on the click location.
- Added `WM_event_drag_start_mval` for convenient access to the region
relative drag-start location (for drag events).
- Added `WM_event_drag_start_xy` for window relative coordinates.
- Added Python property Event.mouse_prev_click_x/y
Resolves T93599.
Reviewed By: Severin
Ref D14213
|
|
Supporting two kinds of dragging is redundant, remove tweak events as
they only supported 3 mouse buttons and added complexity from using the
'value' to store directions.
Support only click-drag events (KM_CLICK_DRAG) which can be used with
any keyboard or mouse button.
Details:
- A "direction" member has been added to keymap items and events which
can be used when the event value is set to KM_CLICK_DRAG.
- Keymap items are version patched.
- Loading older key-maps are also updated.
- Currently the key-maps stored in ./release/scripts/presets/keyconfig/
still reference tweak events & need updating. For now they are updated
on load.
Note that in general this wont impact add-ons as modal operators don't
receive tweak events.
Reviewed By: brecht
Ref D14214
|
|
|
|
Use a flag for events to avoid adding struct members every time a new
kind of tag is needed - so events remain small.
This also simplifies copying settings as flags can be copied at once
with a mask.
|
|
- Rename ED_view3d_win_to_delta `mval` argument to `xy_delta` as it
as it was misleading since this is an screen-space offset not a region
relative cursor position (typical use of the name `mval`).
Also rename the variable passed to this function which also used the
term `mval` in many places.
- Re-order the output argument of ED_view3d_win_to_delta last.
use an r_ prefix for return arguments.
- Document how the `zfac` argument is intended to be used.
- Split ED_view3d_calc_zfac into two functions as the `r_flip` argument
was only used in some special cases.
|
|
Using flags makes checking multiple modifiers at once more convenient
and avoids macros/functions such as IS_EVENT_MOD & WM_event_modifier_flag
which have been removed. It also simplifies checking if modifier keys
have changed.
|
|
This commit renames enums related the "Curve" object type and ID type
to add `_LEGACY` to the end. The idea is to make our aspirations clearer
in the code and to avoid ambiguities between `CURVE` and `CURVES`.
Ref T95355
To summarize for the record, the plans are:
- In the short/medium term, replace the `Curve` object data type with
`Curves`
- In the longer term (no immediate plans), use a proper data block for
3D text and surfaces.
Differential Revision: https://developer.blender.org/D14114
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
Ref T92709
|
|
|
|
This reverts commit 717a971035071d36af03d65713408f4da1f69cb3.
|
|
'Snap Source'""""
This reverts commit 701f2dfd5bc61c0f37603880fa21abfe8b1d9620.
|
|
Source'"""
This reverts commit 25fa6c74b977ac983a34b9adf5ab2f20fe2f4932.
|
|
This reverts commit 2a9cfdac7e126e37afb82e15a131717041f3d2f8.
|
|
This reverts commit 5e6fdaa07fff907e02b36813ccde0702bad4fb4d.
|
|
This reverts commit 805181bffae647a24e939c651da72a08c5c2b7cb.
|
