Part of the checks to see if translating a UI string is allowed or not
is that current thread is the main one. This was a requirement years ago
of the Boost backend for translations.
Not sure whether this can be removed or not now, but it needs to be
carefully checked, done it as its own commit, and not in a beta release
branch. ;)
Sorry for the noise, totally missed this during the patch review
yesterday.
Pasting numerical array buttons happens with `Ctrl + Alt + V`.
Holding `Alt` also triggers uiSelectContext, so having other nodes/
objects etc. selected while doing this would try to copy the pasted
values back to other objects (possibly to the ones you pasted from) and
that happens relative to the original value, so the value actually
changes.
NOTE: the `Ctrl + Alt + V` shortcut can also be used on non-array buttons, so was an issue for them as well.
To prevent the "copy-to-selected" behavior, refine the `IS_ALLSELECT_EVENT` macro to be more specific.
Pull Request: https://projects.blender.org/blender/blender/pulls/108270
Double underscores didn't communicate that this was deprecated,
and are typically for internal or platform defined identifiers and
shouldn't be used for public API's.
This PR adds conversion template to convert between Low Precision float
formats. These include Binary32 floats and lower. It also adds support
to convert between unsigned and signed float formats and float formats
with different mantissa and exponents.
Additionally overflows (values that don't fit in the target float
format) will be clamped to the maximum value.
**Reasoning**:
Up to now the Vulkan backend only supported float and half float
formats, but to support workbench, 11 and 10 unsigned floats have to be
supported as well. The available libraries that support those float
formats targets scientific applications. Where the final code couldn't
be optimized that well by the compiler.
Data conversion for color pixels have different requirements about
clamping and sign, what could eliminate some clamping code in other
areas in Blender as well. Also could fix some undesired overflow when
using pixels with high intensity that didn't fit in the texture format
leading to known artifects in Eevee and slow-down in the image editor.
**Future**
In the future we might want to move this to the public part of the GPU
module so we can use this as well in other areas (Metal backend), Imbuf clamping
See 3c658d2c2e69e9cf97dfaa7a3c164262aefb9e76 for a commit that uses
this and improves image editor massively as it doesn't need to reiterate over
the image buffer to clamp the values into a known range.
Pull Request: https://projects.blender.org/blender/blender/pulls/108168
Backgrounds in Eevee-next were different compared to Eevee-legacy.
Only when viewed from the world origin the background matched.
This change will make sure that the results of both engines matches.
Pull Request: https://projects.blender.org/blender/blender/pulls/108509
Now the operator is used for both the internal & external editor,
so there is no need for the caller to call this operator only when
the preferences are set.
Calling screen maximize while dragging could lead to UI layout change
which affects context, this lead to crashes in the icon drawing and
selection code. This patch prevents maximize operator from running if
dragging is in progress.
Might need to look into why `drag->imb->rect` is None immediately after
calling maximize, we might want it to work since it's sometimes
more convenient to drag then put into a big recieving box. But since
`wmDropBox` is predetermined, this can be a somewhat problematic.
Pull Request: https://projects.blender.org/blender/blender/pulls/107803
Add a user preference to set up a custom text editor for editing text
files with the "Edit Source" action in the UI context menu.
- An operator TEXT_OT_jump_to_file_at_point has been added.
- A custom editor can be set in the user preferences.
- A preset has been included for "Visual Studio Code".
- When the editor is not set, use Blender's internal editor.
Ref !108299.
References to data-blocks in a material were stored in-memory and could
crash if the data-blocks referenced by the material no longer existed
when pasting.
Resolve by using a blend-file for material copy/paste, matching how the
clipboard works in the 3D view-port.
Currently there is no support for including indirectly linked
data-blocks when pasting the material. Instead, data-blocks are restored
by name, by inspecting the current file.
This also fixes a crash where the `SpaceNode::nodetree` could point to
freed memory when pasting a material.
Ref !108496.
Includes contributions by @mont29.
---
Fix back-ported to main [0], including fix [1].
[0]: 5177e2f20b
[1]: 64aa96d421
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.
`hair_out_mesh` and `hair_in_mesh` implicitly share edges.
In `hair_create_input_mesh()`, edge data of `hair_in_mesh` needs to be
updated and therefore are copied to a new location. In the subsequent
frames, `psys->clmd->clothObject->edges` won't be updated and point to
freed memory block. Therefore, Blender crashes.
By freeing `hair_out_mesh` first,
1. in `hair_create_input_mesh(),` at least edge data copying is avoided
2. `psys->clmd->clothObject->edges` always points to correct memory
However, since it's possible that similar situation will happen again
by adding another strong user to the same `CustomData` in the future,
it is safer to update `psys->clmd->clothObject->edges` for every frame.
Pull Request: https://projects.blender.org/blender/blender/pulls/108480
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.
