This commit removes the transformed `Snap Base` symbol (white target)
and displays only the untransformed `Snap Base` symbol (X) when
confirming the Snap Base Edit operation.
The usefulness of the white target icon representing the transformed
`Snap Base` is debatable since it represents the snap target itself
(orange circle) during the Move operation or the direction between the
pivot and the snap target during the Rotation operation.
Having multiple symbols on the screen can clutter the interface and may
not be intuitive.
Therefore, further discussion is required.
Ref.
#108669
The snap mode called "Face Nearest" (and the "Increment" but that's for
another time) doesn't behave like the other snap modes.
Unlike the other snap modes, "Face Nearest" does not act on a Snap
Base (or Snap Source).
It always acts on the origin of individually transformed elements, (such
as each vertex individually).
It works just like the "Project Individual Elements" option.
So this commit makes the following changes:
- `Snap With` was moved to the beginning of the popover
- `Align Rotation to Target` and `Backface Culling` have been moved closer to the snap targets
- `Snap With`, `Target Selection` and `Align Rotation to Target` are no longer hidden by varying the mode and options
- `Project Individual Elements` has been replaced with the `Face Project` option
- `Face Nearest` has been moved to stick together with the `Face Project` option
Co-authored-by: Germano Cavalcante <germano.costa@ig.com.br>
Pull Request: https://projects.blender.org/blender/blender/pulls/108555
There produce unneeded empty lines in the
console. They are just relic from the time
these message were using printf.
Also remove some redundant informations in
the messages themselves.
The "Fill" message can be either a noun or a verb. This commit
disambiguates the verb usages for translation through various
translation contexts.
The more involved change is in the generation of keymaps from paint
modes. By default, the enums defining brush names are in the default
context, but this commit changes the ones including a "Fill" item to
"Brush". In order to get the same contexts in the keymap, we introduce
a specific function in `paint.cc` to return the appropriate context
depending on the tool.
Issue reported by Gabriel Gazzán (@GabrielGazzan) in #43295.
Pull Request: https://projects.blender.org/blender/blender/pulls/108561
This refactor pulls the call to get the `deformation` data from inside the selection function to the outside.
Instead, the deformed positions are now passed directly to the selection functions.
This means that the selection functions become more independent of the object type, which was the original intent.
Otherwise, using these functions with e.g. Grease Pencil will crash.
Pull Request: https://projects.blender.org/blender/blender/pulls/108650
This came up in #108096
Reason this fails is the `ui_but_has_array_value` check [which depends
on a property subtype that supports arrays]. The default `VectorBuilder`
has a `PropertySubType` of `PROP_NONE` though, so one possibility
would be to change this to `PROP_XYZ`.
However, RNA should know much better which RNA property buttons
have arrays than the UI code, so use RNA_property_array_check now
(instead of checking particular UI property subtypes).
Pull Request: https://projects.blender.org/blender/blender/pulls/108349
Fixes armature deformation bug when Preserve Volume is enabled and deforming bones are both rotated and scaled.
The bug happens because Preserve Volume uses Quaternion to interpolate rotations. A bone has 3 parts of data describing its deformation: Quaternion(w,x,y,z) rotation (`quat`), Translation(w,x,y,z) (`trans`), and Scaling(4x4 matrix) (`scale`). To calculate deformed position of a vertex `r`, it will be firstly scaled by `scale`, then rotated and translated by `quat & trans`.
The 4x4 scaling matrix `scale` has a 3x3 part `S33` about scaling and shearing along 3 axes, and a vector part `ST3` that further translate the scaled position. i.e. `scale@r = S33@r + ST3`. This enables scaling about an arbitrary "pivot" (a point `r0` satisfies `scale@r0 = r0`).
However, when blending influence of multiple bones, different bones have different scaling pivot (their head position). Since quaternion rotation and translation/scaling are not commutative operations, this is what I believe causing this bug.
How this is fixed:
Note that the translational part `ST3` of the scaling matrix is redundant in functionality with Translational part `trans` in deformation data. There exists an equivalence transformation that simultaneously change `trans` and `ST3`, while keeping the deformation unchanged.
I applied this equivalence transformation to move the pivot to the vertex that the bones are deforming, before blending multiple bone transformations. Note that now the vertex is the pivot, so scaling transformations will not change its position. Further blending/applying of scaling matrices can be avoided.
Pull Request: https://projects.blender.org/blender/blender/pulls/108134
This reverts commit 8ed65fe6de.
Fix#108553: Alt + value change doesn't work for various inputs
Fix#108621: Driven values are no longer marked in purple
When adding a texture paint slot to an object, the object could have no
material, this patch handles that by checking the material first in
`default_paint_slot_color_get`, if material is null, then it will return a
fallback default color so the operator can proceed normally.
Pull Request: https://projects.blender.org/blender/blender/pulls/108592
Prefer memcpy when exact sizes have been calculated as this removes the
implication that the string might be smaller than the length argument.
Further, passing in `len + 1` to BLI_strncpy without clamping by the
destination buffer size is reads like a common mistake,
where the length of the source may exceed the destination buffer size.
While using `std::min(sizeof(dst), len + 1)` would avoid the confusion
it's complicating a statement which can use memcpy instead.
- Paste flipped created invalid paths when the size of the name changed
left -> right: lost the 't' in right.
right -> left: lost the entire end of the RNA path.
- Correct the fixed buffer size as it may include escaped characters.
Some modifiers used `MOD_deform_mesh_eval_get` to make sure they had
a mesh to retrieve vertex groups from. But since curves don't support
vertex groups anyway, and since the curve to mesh conversion is handled
by the (legacy) curve object modifier stack anyway, this is confusing
and unnecessary. This shouldn't give any behavior changes, but some
deform modifiers on legacy curve objects might be faster if they used
to do the conversion.
This limitation was added to avoid conflicts with tools.
But since we now have the "allow_navigation" option on transform
operators, there is no real benefit to having this limitation.
No functional changes from user's point of view.
"Shrink/Fatten" is used in macros for some extrude operations.
These operations may rely on the type of mesh selection.
While some of these operations are combined with the "Move" function,
which already permits navigation, others are combined with
"Shrink/Fatten", which currently lacks navigation capabilities.
To ensure consistency and enable navigation in all extrude operations,
this commit introduces the option to enable navigation for the
"Shrink/Fatten" operator.
Fix a mistake in commit 2ce5fc4a3e that caused a crash when detaching
node links from input sockets.
When a link is detached from an input socket, `nodeRemLink` nulls the
`link` pointer of the socket.
So before the next update inputs are linked but don't have a valid `link`
pointer causing the crash, when trying to access the link in
`std_node_socket_draw`.
The introduced check avoids the crash and is more correct since it
doesn't just check one link for multi-input sockets.
Pull Request: https://projects.blender.org/blender/blender/pulls/108623
- "Invalid" in transformation messages.
- For three messages, translation occured after a string
- concatenation, so the full message was not found.
Instead, translate a format pattern and format it afterwards.
- Alembic errors when there is an import type mismatch.
Pull Request: https://projects.blender.org/blender/blender/pulls/108212
