This pull request adds the ability for users to specify input samples
on a per brush basis. The existing field in the main `Paint` struct
forces all brushes of a particular tool type to use the same value.
A new field was added to the `Brush` struct to allow for this value
to be specified there instead, and a corresponding unified value in
`UnifiedPaintSettings` has been created to allow users to use the
same value across all brushes.
Addresses #108109
Pull Request: https://projects.blender.org/blender/blender/pulls/117080
This pull request adds the ability for the `propagation_steps` value
for certain automasking settings to be applied globally instead of
using the per-brush attribute.
Previously, while the flag settings were stored at the brush and global
level, the `propagation_steps` value would always change the brush
attribute even when using the global menu.
Addresses #102377
Pull Request: https://projects.blender.org/blender/blender/pulls/117316
With the addition of F82 tinting to the Principled BSDF, metals now use
the specular tint parameter.
This can cause issues when converting materials from older versions
of Blender to newer versions if the Specular Tint isn't handled
properly for these materials.
This commit attempts to fix this by adjusting the Specular Tint color
based on the Metallic input to try and keep converted materials
consistent with older versions of Blender.
Thank you to @LukasStockner for helping out.
Pull Request: https://projects.blender.org/blender/blender/pulls/114518
Add the 'solo' flag to bone collections, effectively adding another
layer of visibility controls.
If there is _any_ bone collection with this flag enabled, only this
collection (and others with this flag enabled) will be visible.
In RNA, the following properties are exposed:
- `bone_collection.is_solo`: writable property to manage the solo flag.
- `armature.is_solo_active`: read-only property that is `True` when any
bone collection has `is_solo = True`.
The RNA property `bone_collection.is_visible_effectively` now also takes
the solo flag into account.
Pull Request: https://projects.blender.org/blender/blender/pulls/117414
The CPU implementation had the following downsides:
- The kernels sizes below 3 did not make much sense, often leading
to a full white image.
- The way how the total number of pixels in the kernel was calculated
quite strangely.
From these points of view the GPU compositor behaves more user friendly.
There is a versioning code which lowers the kernel size, to match the
result prior to these tweaks.
Pull Request: https://projects.blender.org/blender/blender/pulls/117505
This pull request adds the ability for the `Limit` and `Falloff` values for the View and Normal automask modes to be applied per-brush instead of modifying the global tool value.
Previously, while the flag settings were stored at the brush and global level, the values would always change the global value even when using the advanced tab of the brush menu.
## Testing
* `make test` results in 3 failures (49 - io_wavefront, 134 - compositor_distort_cpu, 323 - imbuf_save), but these tests appear to fail even prior to any changes being applied when running locally
* Manual testing with older version blend files to ensure that the value is defaulted correctly.
* Visual testing to verify that brush values are favored over global values.
Addresses #115174
Pull Request: https://projects.blender.org/blender/blender/pulls/117433
The Tiled default is the least commonly used mapping mode, switch the
default to something that is more commonly used.
Do it for all modes, since according to Julien it is reasonable default
behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/116933
When the object info node was originally created, the transform of an
object with a negative scale would also have negative scale. At some
point that behavior changed though, and the matrix always had positive
scale.
The negative scale is the more expected behavior (see #104926), and
66dc0ebf2e restored that behavior. But node setups started to
rely on the non-negative behavior in the meantime. So this commit adds
an absolute value node with versioning.
The versioning is added to the 401.10 file subversion bump, since
that's when the behavior changed back to the current state.
Pull Request: https://projects.blender.org/blender/blender/pulls/117425
`UUID` generally stands for "universally unique identifier". The session identifier that
we use is neither universally unique, nor does it follow the standard. Therefor, the term
"session uuid" is confusing and should be replaced.
In #116888 we briefly talked about a better name and ended up with "session uid".
The reason for "uid" instead of "id" is that the latter is a very overloaded term in Blender
already.
This patch changes all uses of "uuid" to "uid" where it's used in the context of a
"session uid". It's not always trivial to see whether a specific mention of "uuid" refers
to an actual uuid or something else. Therefore, I might have missed some renames.
I can't think of an automated way to differentiate the case.
BMesh also uses the term "uuid" sometimes in a the wrong context (e.g. `UUIDFaceStepItem`)
but there it also does not mean "session uid", so it's *not* changed by this patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/117350
Splits the flag `..._FLAG_INSERTNEEDED` between autokey and
manual keying. The fact that this flag was shared between the two
systems has been the cause of issues in the past. It wouldn't
let you insert a keyframe even though you explicitly used an operator
to do so.
In order to be clearer what options are used where, the user preferences
have been reordered.
By default "Only Insert Needed" will be enabled for auto-keying, but not for manual keying.
The versioning code will enable both if it was enabled previously.
# Code side changes
The keying system has flags that define the behavior
when keys are inserted. Some of those flags were shared
between keying and auto-keying. Some were only used for
auto-keying.
To clarify that, prefix flags that used exclusively in one or the other
system with `AUTOKEY`/`MANUALKEY`
Also the flag name on the user preferences and the tool settings was renamed.
Previously it was called `autokey_flag`. To indicated that it is not only used
for autokeying, rename it `keying_flag`.
Fixes: #73773
Pull Request: https://projects.blender.org/blender/blender/pulls/115525
The term `PIL` stands for "platform independent library." It exists since the `Initial Revision`
commit from 2002. Nowadays, we generally just use the `BLI` (blenlib) prefix for such code
and the `PIL` prefix feels more confusing then useful. Therefore, this patch renames the
`PIL` to `BLI`.
Pull Request: https://projects.blender.org/blender/blender/pulls/117325
When using the MapUV node for certain NPR workflows (for example palette
based remapping of colors) it can be useful to not use the default
anisotropic filtering.
In preparation of potentially adding more filter modes at a later stage
and to keep things consistent with the 'transform' node we use the full
set of interpolation modes in the enum, but expose only the implemented
ones in RNA..
Loading pre-4.0.20 node groups with sockets using subtypes causes
broken socket identifiers. This is because the node tree interface now
expects sockets to use the base identifiers ("NodeSocketFloat" instead
of "NodeSocketFloatFactor" etc.).
To correct this the conversion code now replaces socket idnames that
include a subtype suffix with their base names. This fix is also applied
to files between versions 4.0.20 and 4.1.10, where the socket types
may have been converted incorrectly.
Pull Request: https://projects.blender.org/blender/blender/pulls/117133
This is due to `BLI_findstring` returning wrong id from passed name.
Two IDs can have same name before making them unique so it can return
wrong id. To fix this, pass id argument instead of id_name to
`BLI_libblock_ensure_unique_name` and skip the use of `BLI_findstring`
Pull Request: https://projects.blender.org/blender/blender/pulls/116246
The previous commit introduced a new `RPT_()` macro to translate
strings which are not tooltips or regular interface elements, but
longer reports or statuses.
This commit uses the new macro to translate many strings all over the
UI.
Most of it is a simple replace from `TIP_()` or `IFACE_()` to
`RPT_()`, but there are some additional changes:
- A few translations inside `BKE_report()` are removed altogether
because they are already handled by the translation system.
- Messages inside `UI_but_disable()` are no longer translated
manually, but they are handled by a new regex in the translation
system.
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
Translation of the UI is currently split into 3 preferences:
interface, tooltips, and new data. The distinction between interface
and tooltips is currently unclear as tooltips also include a lot of
messages not displayed in the actual tooltips on mouse hover.
These include reports to the Info Editor, information in editor
headers and footers, and statuses in panels.
In order to limit the use of `TIP_()` to actual tooltips, this commit
introduces a new preference for this extra information: "Reports".
New translation macros are introduced: `RPT_()` and `CTX_RPT_()`, as
well as their equivalent for the Python API, `pgettext_rpt_()`, to be
imported as `rpt_()`.
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
Starting with Blender 4.0, Blender refuses to load a userpref.blend file
that had been generated on a macoOS machine, exiting immediately with an
unsupported GPU error. This is because when the userdef was written on
the macOS machine (assuming a recent version), it has gpu_backend set to
GPU_BACKEND_METAL (which is rejected). The same is true in reverse.
Prior to commit cdb8a8929c there was a runtime fallback such
that the setting for Metal backend would be ignored on non-Metal
platforms.
This adds a check in blo_do_versions_userdef() for if gpu_backend is set
to an unsupported backend; if so, it is set to a default supported value
for the current platform (Metal on macOS, OpenGL otherwise). This
replaces the current versioning check, as this isn't strictly related to
versioning. The new logic handles the narrower versioning case (a macOS
user upgrading to 4.0+ with a userprefs selecting OpenGL) as well.
This should be future-proof for other GPU backends, as it only overrides
in the case of an unsupported value. The logic could be generalized in
the future, perhaps.
Co-authored-by: Andrew Oates <andrew@andrewoates.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/116861
- Improve the look of them, so they feel less like from year
1998 (more details and images in the PR).
- Some of the scopes got slightly faster in the process, others
stayed the same performance (details below).
- Remove VSE Scopes related data from SpaceSeq DNA, move it into
runtime instead.
The ability to adjust the "Backwire Opacity" was mistakenly removed in
version 2.93 (b365cc017a).
As this issue went unnoticed by most users, it appears reasonable to
completely remove this setting from the code.
By making this change, there is no longer a need to define a default
value for `View3DOverlay::backwire_opacity`.
Pull Request: https://projects.blender.org/blender/blender/pulls/116799
Bone collection visibility now respects their hierarchy.
A bone collection is only visible when it is marked as visible and all
its ancestors (so parents, greatparents, etc.) are visible. Root bone
collections have no ancestors by definition, and only consider their own
visibility.
The effective ancestors' visibility is stored on each bone collection,
in its `BONE_COLLECTION_ANCESTORS_VISIBLE` flag. This makes it possible
to determine the effective visibility from just the flags of the bone
collection itself.
The `BONE_COLLECTION_ANCESTORS_VISIBLE` flag is now stored, with the
other flags, in `BoneCollection::flags`. This means that it's stored in
DNA, even though it's derived data and should actually be stored in a
runtime struct. However, `BoneCollection` doesn't have any runtime
struct yet, and I don't feel that the introduction of this flag is a
good enough reason to introduce that just yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/116784
Bundling many tests in a single binary reduces build time and disk space
usage, but is less convenient for running individual tests command line
as filter flags need to be used.
This adds WITH_TESTS_SINGLE_BINARY to generate one executable file per
source file. Note that enabling this option requires a significant amount
of disk space.
Due to refactoring, the resulting ctest names are a bit different than
before. The number of tests is also a bit different depending if this
option is used, as one uses gtests discovery and the other is organized
purely by filename, which isn't always 1:1.
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/114604
