When e.g. using auto-key to draw on a new frame, the dopesheet
(and other editors) would not redraw to show the newly added keyframe.
This fix makes sure we send notifiers to those editors when a
keyframe is added.
The "uniform thickness" was still in the legacy "pixel" space. The fix
makes sure that value is always converted to the right radius space.
We also convert the potentially animated property for the thickness
and scale the fcurves to be in the right space.
Pull Request: https://projects.blender.org/blender/blender/pulls/121128
When using a version of Wayland that doesn't support trackpad direction
show an option to set the direction manually.
While this is a stop-gap measure until compositors support seat
version 9, the latest GNOME doesn't yet support this, so there will
be users for some years without this functionality.
Addresses issue raised in #107676.
Add _bpy._wm_capabilities(), needed for preferences code to check if
WM functionality is supported. This could be made into a public
function, see code comments for details.
Support detecting if the trackpad direction flag is propertly set
(currently unused).
Needed so Wayland compositors that don't support seat-version 9 or
newer (GNOME-46 & KDE5 for e.g) can have a working trackpad.
Eventually this option will be removed when the functionality is
widely supported.
No functional changes.
This PR moves the `ANIM_get_keyframing_flags` function to
animrig as `get_keyframing_flags`.
The docstring has been fixed since it was out of date.
Pull Request: https://projects.blender.org/blender/blender/pulls/121120
This adds a new `Transform` type similar to cycles that reduces
the amount of data passed for a typical affine 3D transform.
This then applies this type to the light data and cleanup
all usage of the former `object_mat`. This also changes the axes
macros into utility accessor functions.
Pull Request: https://projects.blender.org/blender/blender/pulls/121089
This moves the seemingly arbitrary value of "1 / 2000"
into a constant variable
(`bke::greasepencil::LEGACY_RADIUS_CONVERSION_FACTOR`)
so that it can be used in all the places where
legacy "thickness" values need to be converted.
This also expands the explanation of the factor a bit, so it's
clearer why it is needed.
This was because the distance function was assuming that
the radii were still in the legacy `px` space rather than in the
same space as the positions.
The function wasn't updated after the merge of
07749b389d
The division by `2000.0f` can be removed.
These are not fully supported, users who load these will not be able
to access all the faces within the TTC/OTC.
Existing uses of TTC/OTC won't be blocked, these are just not shown as
supported fonts in the file selector. Addresses #44254.
Ref !121060
Both vertexpaint and weightpaint would only apply all of radial symmetry
for the "initial stroke".
When going over the combinations of symmetry axis, some of radial
symmetry would be skipped, e.g. when mirroring from right to left with
`Mirror X` turned ON, a dab on the right would have radial symmetry from
that point, and an additional dab on the left from mirroring (but the
mirrored dab would not have radial symmetry on its own).
This does not lead to symmetric results at all, sculptmode also does not
behave that way (there, radial symmetry is performed on the mirror axis
as well).
Now do the same thing as in sculptmode to get symmetric results when
using mirror and radial symmetry together.
Also use the utility function to skip invalid symmetry iterations.
Stumbled over this when looking into #120843
Pull Request: https://projects.blender.org/blender/blender/pulls/120931
While using texture on the brush in vertex paint mode (neither generated
or imported texture), the brush texture is sampled based off of the
unmirrored coordinate.
To resolve, use the same method that sculptmode uses in
`sculpt_apply_texture` (flipping the coordinate over the mirror axis).
Pull Request: https://projects.blender.org/blender/blender/pulls/120935
Previously, the track axis would remain X on the other side. It should
be flipped to -X to give a symmetrical result.
Building upon ee43cf5722, this adds support for flipping the track
axis in certain constraints, namely:
- Track To
- Locked Track
- Damped Track
- Shrinkwrap
Pull Request: https://projects.blender.org/blender/blender/pulls/120979
Exposed by 6c774feba2
`BM_mesh_decimate_dissolve_ex` sets up `DelimitData` with layer offset
(start), size and end so that `bm_edge_is_contiguous_loop_cd_all` can
check a range of edges for being contiguous.
The way `cd_loop_offset_end` is calculated is wrong though, it does not
take the actual start into account (this has to be added to fix the
bug). When it is wrong, it can happen that start and end are the same,
so no check actually takes place and no delimiting edges are found.
It seems that prior to 6c774feba2 the customdata layer always had an
offset of zero, so never really showed in practice (at least I couldnt
make it break in 3.4), but after 6c774feba2 we can at least observe the
following:
- when creating a bmesh, an offset would to the uv layer would still be
zero in my tests
- however, as soon as we iterate loops of a face (as done in the
report), we get an additional layer `CD_BM_ELEM_PYPTR`
- this then changes the offset
- `BM_uv_map_get_offsets_from_layer` seems to do the right thing afaict
So to resolve, just add the "start" offset to the end, to get the right
range.
NOTE: there is a very similar `DelimitData` used in
`bmesh.ops.join_triangles` and the way in which `bm_edge_delimit_cdata`
sets up te range is exactly like what this PR proposes.
Pull Request: https://projects.blender.org/blender/blender/pulls/121033
While additional context is typically useful to include,
this is such a corner-case that it's not expected script authors
would run into this during regular development.
Since the flood fill callback uses FunctionRef now, there is no need to pack
the relevant arguments into a separate struct. Though there are a lot of
arguments now, there is one less indirection which hels when clicking
through the code.
This implements all the sculpt tools in Grease Pencil 3.
UI changes in the 3D view header and keymap entries for sculpt mode are
still minimal, more entries should be added once the relevant operators
are supported.
A set of utility functions and a shared base class
`GreasePencilStrokeOperationCommon` for sculpt operations has been added
to make individual operations less verbose.
The `GreasePencilStrokeParams` struct bundles common arguments to reduce
the amount of boilerplate code. The `foreach_editable_drawing` utility
function takes care of setting up the parameters and finding the right
drawings, so the tool only has to modify the data. Common features like
tracking mouse movement and inverting brush influence are handled by the
common base class.
Most operations are then relatively simple, with the exception of the
Grab and Clone operations.
- __Grab__ stores a stroke mask and weights on initialization of the
stroke, rather than working with the usual selection mask.
- __Clone__ needs access to the clipboard, which requires exposing the
clipboard in the editor API.
Pull Request: https://projects.blender.org/blender/blender/pulls/120508
Moving a constant variable results in a copy occurring instead. This
looks to have been an accidental change as part of ea937b304d.
A few tools will warn about this:
`Warning C26478 Don't use std::move on constant variables. (es.56)`
`Warning cpp:S5415 "std::move" should not be called on a const object.`
Pull Request: https://projects.blender.org/blender/blender/pulls/121063
This PR changes the `swap_handles` variable of the
`BeztMap` from `short` to `bool`.
The only reason it was a `short` was so that 0 could be
interpreted as "not checked" within the sorting loop.
Instead, I moved the checking for swapping to a separate loop.
That means the `BeztMap` array needs to be traversed one more time,
but given sorting might already do that multiple times that won't be
a performance issue
(plus we don't have the `if` within the sorting loop potentially messing up branch prediction).
In addition to that this PR also removes `prev_ipo` and
`current_ipo` from the `BeztMap` struct. Those were never used.
This is also partly a fix to restore 3.6 behavior.
With the move to C++, `swap_handles` was never initalized,
so the logic ` if (bezm->swap_handles == 0)` would always be false.
That resulted in the following behavior when
**rotating a bunch of keys 180deg** around their common center.
Pull Request: https://projects.blender.org/blender/blender/pulls/121076
The previous implementation was not considering each
channel magnitude, which was not rotationally
invariant. This fixes changes in lighting as the world
rotates (and if clamping is enabled).
This fixes the slightly incorrect solid angle by using
the symetries of the mapping. This avoids orientation
dependent lighting. The computation is not much more
expensive.
This PR adds the feature of displaying which property is modified
to the slider GUI.
This is useful in cases like #117287
where the slider can modify different properties during the modal operation.
The string is optional and will be empty by default.
This label is placed to the left of the slider where the percentage was usually located.
The percentage has now been moved to the right.
Pull Request: https://projects.blender.org/blender/blender/pulls/119920
This PR implements the Weight Paint tools for GPv3.
Tools:
- Draw, for assigning weight to stroke points
- Blur, smooths out weight using adjacent stroke point weights
- Average, smooths weight using the average weight under the brush
- Smear, like finger painting, drags weights in the direction of the brush
- Sample weight, sets the brush weight to the weight under the cursor
The weights are assigned to the active vertex group. When there is no
active vertex group, a group is automatically created.
When the Auto Normalize option is enabled, it is ensured that all
bone-deforming vertex groups add up to the weight of 1.0.
When a vertex group is locked, it's weights will not be altered by
Auto Normalize.
The PR already supports multi frame editing, including the use of a
falloff (defined by a curve).
The implementation is in accordance with the Weight Paint tools in GPv2.
Pull Request: https://projects.blender.org/blender/blender/pulls/118347
