This resolves a logical problem using tweak as a fallback tool.
See: T66304#828742
The select action would immediately show the gizmo underneath it,
then the tweak would be handled by the gizmo instead of moving the item
under the cursor.
Currently this works by hiding the gizmo until the tweak event ends.
While it's simpler to check if the gizmo received a mouse-down event,
it causes flickering before each drag event which feels like a glitch.
This is optional for each gizmo type because there are cases where this
can be useful to activate the gizmo immediately (mesh rip for example).
Implement T66304 as an experimental option,
available under the preferences "Experimental" section.
- When enabled most tools in the 3D view have a gizmo.
- Dragging outside the gizmo uses the 'fallback' tool.
- The fallback tool can be changed or disabled in the tool options
or from a pie menu (Alt-W).
This is the unification of all overlays into one overlay engine as described in T65347.
I went over all the code making it more future proof with less hacks and removing old / not relevent parts.
Goals / Acheivements:
- Remove internal shader usage (only drw shaders)
- Remove viewportSize and viewportSizeInv and put them in gloabl ubo
- Fixed some drawing issues: Missing probe option and Missing Alt+B clipping of some shader
- Remove old (legacy) shaders dependancy (not using view UBO).
- Less shader variation (less compilation time at first load and less patching needed for vulkan)
- removed some geom shaders when I could
- Remove static e_data (except shaders storage where it is OK)
- Clear the way to fix some anoying limitations (dithered transparency, background image compositing etc...)
- Wireframe drawing now uses the same batching capabilities as workbench & eevee (indirect drawing).
- Reduced complexity, removed ~3000 Lines of code in draw (also removed a lot of unused shader in GPU).
- Post AA to avoid complexity and cost of MSAA.
Remaining issues:
- ~~Armature edits, overlay toggles, (... others?) are not refreshing viewport after AA is complete~~
- FXAA is not the best for wires, maybe investigate SMAA
- Maybe do something more temporally stable for AA.
- ~~Paint overlays are not working with AA.~~
- ~~infront objects are difficult to select.~~
- ~~the infront wires sometimes goes through they solid counterpart (missing clear maybe?) (toggle overlays on-off when using infront+wireframe overlay in solid shading)~~
Note: I made some decision to change slightly the appearance of some objects to simplify their drawing. Namely the empty arrows end (which is now hollow/wire) and distance points of the cameras/spots being done by lines.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D6296
When introducing "drag-all-selected" support all over Blender, we
figured this wouldn't work well with the Graph Editor
selection/transform behavior.
Hence, William and I worked on the following changes, although we used
this chance to improve the behavior in general too.
For more info see T70634.
* Handles now always move with the key, regardless if they are selected
or not.
* Selecting the key doesn't select the handles anymore, their selection
is separate.
* Multiple keys and handles can now be dragged.
* Dragging a handle moves all selected handles **on the same side**.
* Tweak-dragging any handle can never affect any keyframe location,
only handles.
* G/R/S should behave as before.
* Changing the handle type with a key selected always applies the change
to both handles.
* Box selection with Ctrl+Drag now allows deselecting handles (used to
act on entire triple only).
* Box selection //Include Handles// option now only acts on visible
handles, wasn't the case with Only Selected Keyframes Handles enabled.
* Box selection //Include Handles// is now enabled by default in all
bundled keymaps.
The changes have been tested for some days by the animators here in the
Blender Animation Studio. Some changes are based on their feedback.
Also, this improves/adds comments for related code.
Differential Revision: https://developer.blender.org/D6235
Reviewed by: Sybren Stüvel, William Reynish
Add new `Backface Culling` option to the snapping properties.
This option has nothing to do with the view3d display or the
workbench `Backface Culling` option.
Limitation:
- In edit mode, this option only affects snap to faces.
Maniphest Tasks: T71217
Differential Revision: https://developer.blender.org/D6155
Deduplicate the code and use the same logic used to
calculate individual elements in `t->values_final[0]`.
Differential revision: https://developer.blender.org/D6135
Multiple selection operations failed with weight-paint + pose mode.
Weight-paint + pose mode is a special case that doesn't support
multi-pose mode, so we need to use this instead of the generic
function.
This only impacts push-pull & shrink-fatten.
Flipping this matches zoom where moving the mouse cursor up
increases the zoom-level.
Previous behavior felt unnatural when adding gizmos to these tools.
The manipulator would hide axes that were locked, even if the lock was
applied to a different space. That would lead to confusing behavior of
the manipulator. E.g.:
* Add armature
* Enter Pose Mode and select the bone
* Lock X and Y location in the Sidebar
* Enable the Move tool
* Only the Y axis is visible, but doesn't do anything on dragging
The manipulator would only show the Y axes, even though the lock is
applied to the bone's local Y axis, which matches the manipulators Z
axis.
Differential Revision: D6021
Reviewed by: Brecht van Lommel, William Reynish
When an edit-bone was locked, we hid the transform manipulator for it.
But only if the bone itself was selected, not when the root or tip were
selected, even though they are locked then too. So this makes sure the
manipulator is shown in neither case.
Users now can turn on in a viewport collections that are temporarily
hidden (eye) in the view layer.
Design task: T61327
As for the implementation, I had to decouple the visibility in the
depsgraph from the visibility in the view layer.
Also there is a "bug" that in a way was there before which is some
operators (e.g., writing a text inside of a text object, tab into edit
mode) run regardless of the visibility of the active object. The bug was
present already (with object type visibility restriction) in 2.80 so if
we decide to tackle it, can be done separately (I have a patch for it
though P1132).
Reviewed by: brecht (thank you)
Differential Revision: D5992
This basically reverts 540eb2dc1e for an alternative solution that
only enforforces release_confirm [ignoring the preference] on mouse for
the node editor.
Approved by @brecht in T70504.
Caused by rB914427afd512.
Since above commit 'pe_get_current' checks for an active depsgraph. This
caused the skipping of handling
`PT_CACHE_EDIT_UPDATE_PARTICLE_FROM_EVAL`for everything calling
`PE_get_current` (this passes a NULL depsgraph as opposed to
`PE_create_current`). So we now pass a depsgraph here as well...
Note there are two RNA cases where we pass NULL, namely
- rna_ParticleEdit_editable_get
- rna_ParticleEdit_hair_get
I guess these should be fine though (no functional change to current
master)
Reviewers: sergey
Maniphest Tasks: T69488
Differential Revision: https://developer.blender.org/D5752
The idea is to ignore dependency which comes via rigid body solver.
Reviewers: mano-wii
Reviewed By: mano-wii
Differential Revision: https://developer.blender.org/D5900
There was a mix of old and new constants. Now have one list of WM_CURSOR_*
cursor types, using GHOST standard cursors when available and otherwise falling
back to our custom cursors.
Ref D5197
