917c096be6 applied to objects only, this also applies the same fix for
the general 3D View drop operations, e.g. used for dragging materials,
images, worlds, etc.
This is needed to fix T95706, but apparently something else is still
going on. Needs further investigation.
The operators to handle object drag and drop (from the asset browser,
outliner, etc.) used the object name to find the object to add and
place. This is problematic with linking and/or library overrides, since
this may lead to multiple objects with the same name. So the wrong
object would be used by the drop operators.
Partially fixes T97320. T95706 probably needs the same fix but for
materials.
As a side-effect, the "Name" button won't show up in the Adjust Last
Operation panel anymore. This isn't really useful, and I doubt this was
ever intentionally exposed in the UI.
The operators to handle object drag and drop (from the asset browser,
outliner, etc.) used the object name to find the object to add and
place. This is problematic with linking and/or library overrides, since
this may lead to multiple objects with the same name. So the wrong
object would be used by the drop operators.
Partially fixes T97320. T95706 probably needs the same fix but for
materials.
As a side-effect, the "Name" button won't show up in the Adjust Last
Operation panel anymore. This isn't really useful, and I doubt this was
ever intentionally exposed in the UI.
The importer was not doing a notification that the scene has changed, so
the bottom status bar scene stats info was not updated right after the
new OBJ import.
Reviewed By: Julian Eisel
Differential Revision: https://developer.blender.org/D15015
Existing code to replace the file operation was failing when done from
the window for the file operation itself.
Basically, this patch does two things:
- Implement a well defined window context to use as the "owner" or
"root" of the File Browser. This will be used for managing the File
Browser and to execute the file operation, even after the File Browser
was closed.
- Ensure the context is valid when dealing with file File Browser event
handlers.
Previously the window context just wasn't well defined and just happened
to work well enough in most cases. Addressing this may unveil further
issues, see T88570#1355740.
Differential Revision: https://developer.blender.org/D13441
Reviewed by: Campbell Barton
This should decrease cognitive load because:
- Intention is more explicit
- Shorter visual scope of branches (no need to search for matching
closing brackets and `else` blocks)
- Visually less busy code because condition-checks and code that
"actually does things" are separated, with less indentation
- Avoids chaining together a bunch of conditions to a single `if`
Also: Use `const`, correct comment placement, whitespace improvements.
* Rename ambiguous rgb to scene_linear in some places
* Precompute matrices to directly go to scene instead of through XYZ
* Make function signatures more consistent
There are two issues. The biggest one was that a pixel value was used
to compare a squared distance meaning the tolerance was too strict.
The other issue was that the tolerance in pixels was different to what
the tracking mode is using.
The user-level change is that now it should be easier to tweak the
mask shape.
The 3D brush utility and the delete brush only considered segments,
so they did not handle single points. Fix by adding special cases for
single point curves.
Differential Revision: https://developer.blender.org/D14944
For the "Sphere" 3D brushes, the depth and radius are only sampled at
the beginning of the stroke. This didn't work when tablet pressure is
used as a factor for the brush radius. Now the 3D brush depth is found
with the max radius (as if the pressure was 1.0), but the pressure
factor is used afterwards.
Restructuring the way the brush executors stored the radius made
the change a bit clearer, which is where most of the diff comes from.
Differential Revision: https://developer.blender.org/D15002
Previously we would pass button state and draw information to widget
draw callbacks in a rather hacky way. Some specific flags from
`uiBut.flag` were masked out, so their bits could be reused for also
passing `uiBut.drawflag` in the same int. Instead this commit introduces
a state-info struct that can properly hold all the relevant data.
This has the advantage that it's now easier to introduce new state data
that needs to be accessible in the widget callbacks. Since we are
running out of button flags, we plan to reorganize button flags, and
split them up into multiple bitfields. In the widget drawing code, this
would have been a hassle earlier.
Also had to add a new widget callback to draw blocks as widgets (popup
backgrounds), since that would pass block flags where we would usually
pass button flags. This wasn't nice, now it's separated more clearly.
This flag was used to activate the hotkey input buttons (e.g. for
"Assign Shortcut") when opened in a popup. Since this was added, other
more generalized ways of getting this same behavior were implemented.
Had to tweak the hotkey button event handling a bit, but it seems to
behave exactly as before now.
Currently the delete brush and some other brushes use the line
segment from the current brush position to the previous position
to find curves to interact with. However, this doesn't work well
with more advanced stroke settings that purposefully use
non-contiguous brush sample locations. This commit makes
the delete brush only use the current sample location.
Differential Revision: https://developer.blender.org/D14992
Multiply the radius and strength of sculpt brushes by the pressure
when "use pressure" is turned on. The brush system isn't responsible
for this, so the pressure needs to be stored in `StrokeExtension`.
Differential Revision: https://developer.blender.org/D14996
Avoids having to manually enable data-blocks for user-edition when you
do not care about what should be edited by whom. Similar to default
behavior before introduction of system overrides (aka non-user-editable
overrides).
When labels in popups (typically headings) matched the name of a button,
the label would be activated instead of the button.
This caused the unwrap menu in the UV editor not to re-select "Unwrap"
when opening a second time.
The algorithm is not designed to be used with Closed strokes (cyclic) and actually the result is arbitrary. In order to avoid this, now the closed strokes never are merged.
Related to T98235
Feedback by: @mendio
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.
Existing code for the `Move` operator, and some `Collections` panel
operations (Object properties) was absolutely not override-safe, and
sometimes not even linked-data safe.
It wasn't possible to temporarily orbit the view, then set back to an
axis-aligned view.
Details:
- It was possible to change RegionView3D.view_rotation while the view
kept the axis alignment value (Top, Left, Front .. etc) which
displayed in the viewport overlay.
Now changing the view rotation directly or via "view_matrix" resets
the axis-alignment - clearing when the view is no longer axis-aligned
or assigning the newly aligned axis.
- RegionView3D.is_orthographic_side_view added in [0] could be assigned
but wasn't useful as it treated an enum as a boolean only setting the
RegionView3D.view to RV3D_VIEW_USER or RV3D_VIEW_FRONT.
Now enabling this aligns the viewport rotation to it's closest
axis-aligned orientation setting RegionView3D.view & view_axis_roll
accordingly. Note that the "orthographic" term is misleading as the
property only relates to axis-alignment, not to the
perspective/orthographic setting. We could consider deprecating the
current naming.
[0]: 63bae864f4
View roll checked if the resulting roll was close to a view axis
but didn't write the aligned quaternion back to the final result.
Add ED_view3d_quat_to_axis_view_and_reset_quat since most callers
to ED_view3d_quat_to_axis_view will reset the quaternion when a view
aligned axis is found.
Asserting the variables weren't NULL raised a warning with GCC 12.1,
instead of suppressing the warning, always assign NULL which is often
expected behavior and makes the function work as documented.
To clarify term still frame: This is portion of strip that displays
static image. This area can exist before or after strip movie content.
Still frames were implemented as strip property, but this was never
displayed in panel. Only way to set still frames was to drag strip
handle with mouse or using python API. This would set either
`seq->*still` or `seq->*ofs` where * stands for `start` or `end`.
When strip had offset, it can't have still frames and vice versa, but
this had to be enforced in RNA functions and everywhere in code where
these fields are set directly. Strip can not have negative offset or
negative number of still frames.
This is not very practical approach and still frames can be simply
implemented as applying negative offset. Merging these offsets would
simplify offset calculations for example in D14962 and could make it
easier to also deprecate usage `seq->*disp` and necessity to call
update functions to recalculate strip boundaries.
For users only functional change is ability to set negative strip offset
using property in side panel.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D14976
Issue revealed by rB90e12e823ff0. Hidden objects may not be fully
evaluated by the despgraph, do not attempt to restore edit/sculpt/etc.
modes for those.
Should also be backported to 2.93 LTS release.
