Reset Defaults left the undo stack in an invalid state,
with the active undo step left at the previous state then it should
have been.
Now the buttons own undo logic is used to perform undo pushes.
1. Now handles cyclic strokes correctly.
2. Added a sharp threshold value to allow preservation of sharp corners.
Reviewed By: Antonio Vazquez (antoniov), Aleš Jelovčan (frogstomp)
Ref D14044
1. Now will remove lines if both adjacent faces are back face.
2. Added a check to respect material back face culling setting.
3. Changed label in the modifier to "Force Backface Culling" (which reflect more accurately with what the checkbox does).
Reviewed By: Antonio Vazquez (antoniov), Aleš Jelovčan (frogstomp)
Ref D14041
- No need for `normal_tx` array if we normalize the planes in `plane_tx`.
- No need to calculate the distance squared to a plane (with `dist_signed_squared_to_plane_v3`) if the plane is normalized. `plane_point_side_v3` gets the real distance, accurately, efficiently and also signed.
So normalize the planes of the member `CameraViewFrameData::plane_tx`.
This is a regression partially introduced in rB0a6f428be7f0.
Bones being transformed into edit mode were snapping to themselves.
And the bones of the pose mode weren't even snapping.
(Curious that this was not reported).
Since Python 3.10 is now supported on all platform,
bump the minimum version to reduce the number of Python versions that
need to be supported simultaneously.
Reviewed By: LazyDodo, sybren, mont29, brecht
Ref D13943
This is an alternate fix for T35170 since it caused T44415.
Having the undo system manipulate the key-block coordinates is error
prone as (in the case of T44415) there are situations when it's
important to apply the difference with the original shape key.
This reverts dab0bd9de6, and instead
avoids the problem by not using the data in `Mesh.key` as a reference
for updating shape-keys when exiting edit-mode.
The assumption that the `Mesh.key` in edit-mode won't be modified
until leaving edit-mode isn't always true. Leading to synchronization
errors. (details noted in code-comments).
Resolve this by using shape-key data stored in the BMesh.
Resolving both T35170 & T44415.
Details:
- Remove use of the original vertices when exiting edit mode.
- Remove use of the original shape-key coordinates when exiting
edit-mode (except as a last resort).
- Move shape-key synchronization into a separate function:
`bm_to_mesh_key`.
- Split the synchronization loop into two branches,
depending on the existence of BMesh shape-key coordinates.
- Always write shape-key values back to the BMesh CD_SHAPEKEY layers.
This was only done in some cases but is now necessary for all
shape-keys as these are used to calculate offsets where the `Mesh.key`
was previously used.
- Report a warning when the shape-key layer isn't found as this uses an
imperfect method of restoring coordinates which should only be used as
a last resort.
Reviewed By: mont29
Ref D14127
The problem was when the Object Offset was enabled because the Constant Offset flag was not checked and the offset always was added to the transformation matrix.
Limit the min and max of the IDProperty for the node group input
from 0 to infinity, and the soft min and max between 0 and 1.
Thanks to @PratikPB2123 for investigation.
Instead of accessing the `CD_NORMAL` layer directly,
use the proper API for accessing mesh normals. Even if the
layer exists, the values might be incorrect due to a deformation.
Related to ef0e21f0ae, 969c4a45ce, and T95839.
The flags overlapped ever since normalize was added, so this
requires versioning to copy the flag value. This needs to be
done both in Blender 3.1 and 3.2.
Differential Revision: https://developer.blender.org/D14165
The flags overlapped ever since normalize was added, so this requires
versioning to copy the flag value.
Differential Revision: https://developer.blender.org/D14165
The code was using the same flag value for different modifiers,
resulting in matching the toggle to random overlapping flags.
Differential Revision: https://developer.blender.org/D14165
The constraints solver is now able to handle more cases correctly.
Also the behavior of the boundary fixes is slightly changed if
the constraints thickness mode is used.
Differential Revision: https://developer.blender.org/D14143
The modifier supports arithmetic operations, like Add or Multiply,
but for some reason omits Minimum and Maximum. They are similarly
simple and useful math functions and should be supported.
Differential Revision: https://developer.blender.org/D14164
The node animation versioning code passes `nullptr` to the `oldName` and
`newName` parameters, but those weren't `NULL`-safe. I added an extra
check for this.
No functional changes, just a crash fix.
Previously, all operators using `PaintStroke` would have to store
the stroke in `op->customdata`. That made it impossible to store
other operator specific data in `op->customdata` that was unrelated
to the stroke.
This patch changes it so that the `PaintStroke` is passed to api
functions as a separate argument, which allows storing the stroke
as a subfield of some other struct in `op->customdata`.
Althought the float buffers are only used as cache, current code paths
don't look at the flags to identify which kind of image it is. Actual
fix would be to check flags, but that wouldn't be something to add one
week before release.
This commit fixes it by removing the buffers after use in the image
engine.
The previous behavior called RNA_enum_item_add a second time,
filled it's contents with invalid values then subtracted totitem,
this caused an unusual reallocation pattern where MEM_recallocN
would run in order to create the dummy item, then again when adding
another itme (reallocating an array of the same size).
Simply memset the array to 0xff instead.
Even though the size of the map was set back to DEFAULT_SIZE_EXP,
the underlying arrays were left unchained. In some cases this caused
further expansions to result in an unusual reallocation pattern
where MEM_reallocN would run expand the entries into an array
that was in fact the same size.
Bug was introduced in D12167.
Reading input size from an input socket is not possible in tiled compositor before execution is initialized. A similar change was done for the base class, see BlurBaseOperation::init_data().
Reviewed by: Jeroen Bakker
Differential Revision: https://developer.blender.org/D14067
