Introduce new DNA for the `Animation` data-block and its sub-data.
This includes the blenkernel code for reading & writing to blend files,
and for memory management (freeing, duplicating). Minimal C++ wrappers
are included, with just the functionality needed for blenkernel to do
its job.
The Outliner code is extended so that it knows about the new data-type,
nothing more.
For more info, see issue #113594.
Pull Request: https://projects.blender.org/blender/blender/pulls/119077
Add percentage closer filtering to shadowmap sampling and a
`shadow_filter_radius` property to lights to control it.
Notes:
* This adds PCF to `eevee_shadow_tracing_lib`, but not to
`eevee_shadow_lib`, which is used by volumes (not required) and
thickness.
* PCF is computed based on the LOD0 size. This assumes that higher
LODs are only used when the shadowmap resolution is actually good
enough to match the render resolution.
Pull Request: https://projects.blender.org/blender/blender/pulls/118220
Auto-save currently only really works in modes that use the `MemFile` undo step,
that excludes things like mesh edit and sculpt mode. Previously, Blender would
attempt to auto-save in those modes, but it would only save the last state from
before the mode was entered, which is useless when staying in the mode for longer.
This problem is *not* fixed here. However, the code now explicitly skips auto-saving
in order to avoid unnecessary short freezes in these modes when Blender auto-saves.
Furthermore, the auto-save will now happen when changing modes.
This reduces the impact of save-time-regressions with #106903.
Pull Request: https://projects.blender.org/blender/blender/pulls/118892
Armature deformation modifier for Grease Pencil v3.
Changes compared to GPv2:
- `multi` DNA field was unused and was removed.
- `vert_coords_prev` array is unused and was removed (gets passed to
armature functions but never gets allocated).
- GPv3 modifier uses the common `influence` struct to store the vertex
group name, for consistency. The
`GREASE_PENCIL_INFLUENCE_INVERT_VERTEX_GROUP` flag is copied to
`deformflag` as `ARM_DEF_INVERT_VGROUP` before evaluation, which is
used internally by armature functions.
- `BKE_armature_deform_coords_with_curves` is added as another variant
of the deform function, but uses C++ parameter types (spans instead
of raw pointers). It gets a `Span<MDeformVert>` directly instead of
deducing it internally from the object type. This is because we want
to do this curve-by-curve and already use arbitrary vector spans for
positions.
Pull Request: https://projects.blender.org/blender/blender/pulls/118752
This is a migration of the current Line Art modifier to GPv3.
Note:
- The modifier is using the exact same DNA structure as the old one, it's re-defined in a different name. At the moment all the variable names and placement after the `ModifierData` part should stay exactly the same until we do proper versioning of the modifier data and completely remove the GPv2 support.
- Vertex weight transfer feature no longer supports name initial matching ("group" used to match "group1","group2" etc). Now it will only transfer vertex weight from source vertex groups that has the exact same name as specified.
Pull Request: https://projects.blender.org/blender/blender/pulls/117028
The issue described was that the motion path didn't display the last frame
of a scene.
This PR makes the user facing motion path range inclusive on both ends.
E.g. when the user specifies a motion path from 1-24 the will now get all 24
frames, whereas previously the motion path would end at frame 23.
This also makes the `Scene Frame Range` option work properly since that
had the same issue. Now it displays the actual full scene range.
Internally, the `bMotionPath` is still exclusive on the upper bound.
It is just the `bAnimVizSettings` range that has been modified.
Pull Request: https://projects.blender.org/blender/blender/pulls/118611
Complete the rule of 5 for the asset weak reference class and remove
a separate copy function. While adding RAII behavior to a DNA struct
directly isn't so common, this seems better than doing it half-way.
This patch adds a new `Stretching Opacity` slider to the overlays panel in the UV Editor.
This allows users to tweak the opacity of the UV stretching overlay, so the image texture
can still be visible through it.
Pull Request: https://projects.blender.org/blender/blender/pulls/117381
The depsgraph CoW mechanism is a bit of a misnomer. It creates an
evaluated copy for data-blocks regardless of whether the copy will
actually be written to. The point is to have physical separation between
original and evaluated data. This is in contrast to the commonly used
performance improvement of keeping a user count and copying data
implicitly when it needs to be changed. In Blender code we call this
"implicit sharing" instead. Importantly, the dependency graph has no
idea about the _actual_ CoW behavior in Blender.
Renaming this functionality in the despgraph removes some of the
confusion that comes up when talking about this, and will hopefully
make the depsgraph less confusing to understand initially too. Wording
like "the evaluated copy" (as opposed to the original data-block) has
also become common anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/118338
This is generally more flexible and less error prone. The struct
implements a proper descructorfor this anyway. That also makes the
separate free function unnecessary-- it's redundant with the destructor.
This adds group ids to the `Sample Nearest Surface` node. This allows e.g. finding
the closest point on a specific mesh island.
Three new sockets are added:
* `Group ID`: Is evaluated on the face domain and splits the input mesh into multiple
parts, each with its own id.
* `Sample Group ID`: Determines in which group the closest nearest surface is detected.
* `Is Valid`: Outputs true if a nearest surface was found, it's false if the group is empty.
Pull Request: https://projects.blender.org/blender/blender/pulls/118150
These reports were embedded in the window manager DNA,
but they were always cleared when reading it from files. It's clearer
to just not store the reports in files at all. I also moved the reports
initialization and freeing to the constructor and destructor of the
runtime class.
This is the only place `ReportList` was embedded in DNA, so
after this we can move that to use C++ features if we want.
Pull Request: https://projects.blender.org/blender/blender/pulls/118329
The `object_to_world` and `world_to_object` matrices are set during
depsgraph evaluation, calculated from the object's animated location,
rotation, scale, parenting, and constraints. It's confusing and
unnecessary to store them with the original data in DNA.
This commit moves them to `ObjectRuntime` and moves the matrices to
use the C++ `float4x4` type, giving the potential for simplified code
using the C++ abstractions. The matrices are accessible with functions
on `Object` directly since they are used so commonly. Though for write
access, directly using the runtime struct is necessary.
The inverse `world_to_object` matrix is often calculated before it's
used, even though it's calculated as part of depsgraph evaluation.
Long term we might not want to store this in `ObjectRuntime` at all,
and just calculate it on demand. Or at least we should remove the
redundant calculations. That should be done separately though.
Pull Request: https://projects.blender.org/blender/blender/pulls/118210
The tiled compositor code is mainly still around, which is only
expected to be a short-lived period. Eventually it will also be
removed.
The OpenCL, Group Buffers, and Chunk size options are already removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/118010
Implements the design from #116067.
The socket type is called "Matrix" but it is often referred to as "Transform"
when that's what it is semantically. The attribute type is "4x4 Matrix" since
that's a lower level choice. Currently matrix sockets are always passed
around internally as `float4x4`, but that can be optimized in the future
when smaller types would give the same behavior.
A new "Matrix" utilities category has the following set of initial nodes"
- **Combine Transform**
- **Separate Transform**
- **Multiply Matrices**
- **Transform Direction**
- **Transform Vector**
- **Invert Matrix**
- **Transpose Matrix**
The nodes and socket type are behind an experimental flag for now,
which will give us time to make sure it's the right set of initial nodes.
The viewer node overlay doesn't support matrices-- they aren't supported
for rendering in general. They also aren't supported in the modifier interface
currently. But they are supported in the spreadsheet, where the value is
displayed in a tooltip.
Pull Request: https://projects.blender.org/blender/blender/pulls/116166
Currently most of the data stored in `wmWindowManager` is runtime
data not saved to files. It's confusing that it's declared in DNA then. That
also prevents us from using C++ features. This commit adds an initial
runtime struct. Moving data there can be done as a separate step.
Initially I wanted to look at moving the `ReportList` system to C++.
The runtime struct has to be defined in the blenkernel module because
the members are (will be) used there in a few places.
Pull Request: https://projects.blender.org/blender/blender/pulls/118157
When deleting all the segments the active index is generally 0. Adding a
new segment increments the active index, which pushes it out of range.
The code should not expect active index to be inside the current range.
Pull Request: https://projects.blender.org/blender/blender/pulls/118143
I added a new BLO_userdef_default.h header to contain declarations of
two global variables that are still defined in C files. Use of designated
initializers for large structs make those files harder to change.
Arguably this is a better header for them anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/118015
This feature is useful for many production scenarios as it allows for the
creation of separate render passes with specific worlds. This would help
workflows that require different skies or other backgrounds for compositing.
Ref #117919
Pull Request: https://projects.blender.org/blender/blender/pulls/117920
Visually it is the same as the execution time implemented for the
geometry nodes, and it is to be enabled in the overlay popover.
The implementation is separate from the geometry nodes, as it is
not easy or practical to re-use the geometry nodes implementation.
The execution time is stored in a run-time hash, indexed by a node
instance key. This is similar to the storage of the mode preview
images, but is stored on the scene runtime data and not on the node
tree. Indexing the storage by key allows to easily copy execution
statistics from localized tree to its original version.
The time is only implemented for full-frame compositor, as for the
tiled compositor it could be tricky to calculate reliable time for
pixel processing nodes which process one pixel at a time.
Pull Request: https://projects.blender.org/blender/blender/pulls/117885
Merge duplicated motion blur settings between Cycles and EEVEE,
and move them to `RenderData`/`scene.render`:
* `scene.cycles.motion_blur_position` -> `scene.render.motion_blur_position`
* `scene.eevee.use_motion_blur` -> `scene.render.user_motion_blur`
* `scene.eevee.motion_blur_position` -> `scene.render.motion_blur_position`
* `scene.eevee.motion_blur_shutter` -> `scene.render.motion_blur_shutter`
On the C/C++ side, this also renames `RenderData::blurfac` to
`RenderData::motion_blur_shutter`.
Pull Request: https://projects.blender.org/blender/blender/pulls/117913
For C it is an opaque pointer, for the C++ it is a class which is
defined in BKE_scene_runtime.hh.
The runtime field ensured to exist after file load, and after new
scene is added. The field is not copied when scene is copied, and
instead the copy of the scene has its own runtime field. If any of
the fields in the runtime are desired to be copied it needs to be
done explicitly.
Currently unused, but is planned to be utilized for the upcoming
compositor timing functionality,
Pull Request: https://projects.blender.org/blender/blender/pulls/117978
Ported lattice modifier from GPv2.
The `LatticeDeformData` is no longer stored in the modifier data, but calculated on-the-fly like in the mesh deform modifier. This is quite trivial data and only stores deformed positions of the lattice, so not really worth the effort and complexity of caching it.
Pull Request: https://projects.blender.org/blender/blender/pulls/117955
Add new "Soft Falloff" option on point and spot light that uses
the old light behavior from Blender versions before 4.0. Blend
files saved with those older versions will use the option.
This option is enabled by default on new lights.
Fix#114241
Co-authored-by: Weizhen Huang <weizhen@blender.org>
Co-authored-by: Clément Foucault <foucault.clem@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/117832
This implements layer parenting and layer transforms.
* Adds a new "Transform" panel in the object-data properties with the (local) translation, rotation and scale.
* Adds a new "Relations" panel with the parent property (and also bone name in case the parent is an armature).
* When converting from GPv2 to GPv3, the parent and transforms are converted too.
* Bone names are updated if they are renamed in the armature.
Implementation details:
* The positions in the drawings are always in layer space. During extraction, we transform the positions to object space. Note that this could be optimized further and done in the render engine itself.
* This means that e.g. the selection code (which needs to know where the positions are on screen) now takes this transform into account.
* The layer transform is calculated when accessed (from the location, rotation, scale properties).
* Code that needs to know where the positions are on screen now takes this new transform into account.
Pull Request: https://projects.blender.org/blender/blender/pulls/117247
When moving keys in the Graph Editor animators
usually only want to move them on one axis.
While this is possible in a few ways (G+X, or G + Middle Mouse Button click),
we could default the behavior to always lock on an axis.
This was suggested by Dreamworks animators during the
Animation & Rigging module meeting.
https://devtalk.blender.org/t/2024-01-26-animation-rigging-module-meeting/33081#patch-review-decision-time-5
This PR adds an option with which the movement is
always locked to a single axis by default.
The option can be found in the Graph Editor under "View->Auto-Lock Axis".
The movement will then be restricted to the axis along
which you've moved the cursor the most.
You can still manually override the lock behavior by pressing `X` or `Y`.
I am piggybacking off the auto locking feature you get when pressing the middle mouse button.
When the new feature is enabled I call that at the start of the transformation.
Except when:
* only handles are selected
* the tweak mode has been started on a handle
This is to not snap handles, which is a behavior that has
been requested by the artists.
Pull Request: https://projects.blender.org/blender/blender/pulls/117669
Animators (especially for film and TV) often need
to track the movement of things in screenspace.
At the end of the day, the pixel motion is what counts.
But motion paths were always in world space,
which made it hard to use when the camera
is also animated (during action scenes e.g.)
This PR introduces the feature of projecting a motion path into the screen space of the active scene camera.
Limitations
This makes the motion path only useful when looking through the active scene camera.
Switching the scene camera using markers is not yet supported.
Technical Implementation
This is achieved by baking the motion path points into the
camera space on creation. For every point calculated,
the camera is evaluated through the depsgraph and
the resulting world matrix is used.
Then I pass in the current frame's world matrix of the
camera into the shader to make sure the points follow it.
As can be seen in the video, it looks quite odd when
viewed at another angle but this is expected.
I mentioned that in the tooltip, so it shouldn't be an issue
Pull Request: https://projects.blender.org/blender/blender/pulls/117593
Since 1497005054, there is a new `ModifierData.persistent_uid` which
has more use cases than the old `session_uid`. This patch removes
`ModifierData.session_uid` and replaces its usages with the new `persistent_uid`.
Pull Request: https://projects.blender.org/blender/blender/pulls/117909
This adds a new `ModifierData.persistent_uid` integer property with the following properties:
* It's unique within the object.
* Match between the original and evaluated object.
* Stable across Blender sessions.
* Stable across renames and reorderings of modifiers.
Potential use-cases:
* Everywhere where we currently use the name as identifier. For example,
`ModifierComputeContext` and `ModifierViewerPathElem`.
* Can be used as part of a key in `IDCacheKey` to support caches that stay
in-tact across undo steps.
* Can be stored in the `SpaceNode` to identify the modifier whose geometry node
tree is currently pinned (this could use the name currently, but that hasn't been
implemented yet).
This new identifier has some overlap with `ModifierData.session_uid`, but there
are some differences:
* `session_uid` is unique within the entire Blender session (except for duplicates
between the original and evaluated data blocks).
* `session_uid` is not stable across Blender sessions.
Especially due to the first difference, it's not immediately obvious that the new
`persistent_uid` can fulfill all use-cases of the existing `session_uid`. Nevertheless,
this seems likely and will be cleaned up separately.
Unfortunately, there is not a single place where modifiers are added to objects currently.
Therefore, there are quite a few places that need to ensure valid identifiers. I tried to catch
all the places, but it's hard to be sure. Therefore, I added an assert in `object_copy_data`
that checks if all identifiers are valid. This way, we should be notified relatively quickly if
issues are caused by invalid identifiers.
Pull Request: https://projects.blender.org/blender/blender/pulls/117347
Update the look of image editor Vectorscope widget (design #116973):
- Colored and Luma options for the point cloud,
- The circles are no longer very low poly,
- Overall grid/background colors are tuned.
- Primary color locations have text labels.
Images in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/116974
Part of "improve filtering situation" (#116980), now strip scaling filter defaults to "Auto" which has logic like:
- No scale, no rotation, integer positions: Nearest (fastest)
- Scaling up by more than 2x: Cubic Mitchell, so you get nicer blending between pixels than with bilinear,
- Scaling down by more than 2x: Box, so that many pixels are averaged properly without too much aliasing,
- Otherwise: Bilinear
Existing strips that use Bilinear (which is default) get switched to Auto when loading older files.
All of this has an advantage that unless you have some special needs for your look, you can leave it at default and it will look decently good at either large up-scaling or large down-scaling, but not waste performance if you don't use any scaling at all. Previously none of the choices were good in "all cases": box (née subsampled3x3) only looks good when scaling down, cubic only looks good when scaling up, default bilinear leaves performance on the table when you don't use any scale/rotation, etc.
On something like Gold movie current edit, most of the strips effectively use Nearest now, except some that are translated into non-integer pixel positions; those stay effectively Bilinear.
Pull Request: https://projects.blender.org/blender/blender/pulls/117853
Replace: {BLENDER_RESOURCE_PATH_USER}/scripts/extensions
With: {BLENDER_RESOURCE_PATH_USER}/extensions
This makes more sense as not all extensions are scripts.
Store the 'expanded/collapsed' state of the bone collection tree view in
the DNA data of the bone collections themselves. This way the tree state
is restored when loading the file.
This commit also adds some code to the abstract tree view classes, for
supporting synchronisation of the extended/collapsed state between it
and external data. It follows the same approach as the handling of the
active element.
RNA wrappers have been added to make it possible for Python code to
expand/collapse parts of the tree.
Library overrides are supported for this property, so the
expanded/collapsed state of linked armatures can be locally saved. If
there is no override, the `is_expanded` property is still editable;
changes will not be saved to file in that case, though.
Pull Request: https://projects.blender.org/blender/blender/pulls/116940
- Adding new repositories now differentiates between "Online" & "Local"
where adding a local repository doesn't prompt for a URL.
- Support removing repositories and their files (uses confirmation
defaulting to "Cancel" to avoid accidents).
- Show an error icon next to repositories that have invalid settings,
these repositories are now ignored until the settings are corrected,
required fields are highlighted red when they're unset & required.
- Rename "directory" to "custom_directory" since an automatic path is
used when not set - created in the users scripts directory.
- Use toggles for custom-directory & remote URL instead of relying on
the value to be left an empty string for alternative behavior.
With this patch, materials are kept intact in simulation zones and bake nodes
without any additional user action.
This implements the design proposed in #108410 to support referencing
data-blocks (only materials for now) in the baked data. The task also describes
why this is not a trivial issue. A previous attempt was implemented in #109703
but it didn't work well-enough.
The solution is to have an explicit `name (+ library name) -> data-block`
mapping that is stored in the modifier for each bake node and simulation zone.
The `library name` is necessary for it to be unique within a .blend file. Note
that this refers to the name of the `Library` data-block and not a file path.
The baked data only contains the names of the used data-blocks. When the baked
data is loaded, the correct material data-block is looked up from the mapping.
### Automatic Mapping Generation
The most tricky aspect of this approach is to make it feel mostly automatic.
From the user point-of-view, it should just work. Therefore, we don't want the
user to have to create the mapping manually in the majority of cases. Creating
the mapping automatically is difficult because the data-blocks that should
become part of the mapping are only known during depsgraph evaluation. So we
somehow have to gather the missing data blocks during evaluation and then write
the new mappings back to the original data.
While writing back to original data is something we do in some cases already,
the situation here is different, because we are actually creating new relations
between data-blocks. This also means that we'll have to do user-counting. Since
user counts in data-blocks are *not* atomic, we can't do that from multiple
threads at the same time. Also, under some circumstances, it may be necessary to
trigger depsgraph evaluation again after the write-back because it actually
affects the result.
To solve this, a small new API is added in `DEG_depsgraph_writeback_sync.hh`. It
allows gathering tasks which write back to original data in a synchronous way
which may also require a reevaluation.
### Accessing the Mapping
A new `BakeDataBlockMap` is passed to geometry nodes evaluation by the modifier.
This map allows getting the `ID` pointer that should be used for a specific
data-block name that is stored in baked data. It's also used to gather all the
missing data mappings during evaluation.
### Weak ID References
The baked/cached geometries may have references to other data-blocks (currently
only materials, but in the future also e.g. instanced objects/collections).
However, the pointers of these data-blocks are not stable over time. That is
especially true when storing/loading the data from disk, but also just when
playing back the animation. Therefore, the used data-blocks have to referenced
in a different way at run-time.
This is solved by adding `std::unique_ptr<bake::BakeMaterialsList>` to the
run-time data of various geometry data-blocks. If the data-block is cached over
a longer period of time (such that material pointers can't be used directly), it
stores the material name (+ library name) used by each material slot. When the
geometry is used again, the material pointers are restored using these weak name
references and the `BakeDataBlockMap`.
### Manual Mapping Management
There is a new `Data-Blocks` panel in the bake settings in the node editor
sidebar that allows inspecting and modifying the data-blocks that are used when
baking. The user can change what data-block a specific name is mapped to.
Pull Request: https://projects.blender.org/blender/blender/pulls/117043
Adds vertex groups and basic operator support to the `GreasePencil` data
block.
Vertex groups in the `GreasePencil` ID are used as the source of truth
for vertex groups names and ordering in the UI. Individual drawings also
have vertex group lists, but they should not be modified directly by
users or the API. The main purpose of storing vertex group names in in a
drawing's `CurveGeometry` is to make it self-contained, so that vertex
weights can be associated with names without requiring the
`GreasePencil` parent data.
Vertex group operators are implemented generically for some ID types.
Grease Pencil needs its own handling in these operators. After
manipulating `vertex_group_names` the `validate_drawing_vertex_groups`
utility function should be called to ensure that drawings only contain a
true subset of the `GreasePencil` data block.
Operators for assigning/removing/selecting/deselecting vertices are also
implemented here. To avoid putting grease pencil logic into the generic
`object_deform.cc` file a number of utility functions have been added in
`BKE_grease_pencil_vgroup.hh`.
Fixes#117337
Pull Request: https://projects.blender.org/blender/blender/pulls/117476
This simplifies the C++ API for making layout panels. Now it is also more similar to the Python API.
`uiLayoutPanel` is like `layout.panel` and `uiLayoutPanelProp` is like `layout.panel_prop`.
Both, `uiLayoutPanel` and `uiLayoutPanelProp`, now exist in two variants. One that takes a label
parameter and one that does not. If the label is passed in, only the panel body layout is returned.
Otherwise, the header and body are returned for more customization.
Pull Request: https://projects.blender.org/blender/blender/pulls/117670
Thickness modifier ported to Grease Pencil v3.
Note: Uniform thickness range and UI step changed to better
match new thickness of blender unit.
![image](/attachments/2e9c9bfa-d869-4bec-a529-c3833390a201)
Pull Request: https://projects.blender.org/blender/blender/pulls/117631
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
Part of overall "improve filtering situation" (#116980): replace Subsampled3x3
(added for blender 3.5 in f210842a72 et al.) strip scaling filter with a
general Box filter.
Subsampled3x3 is really a Box filter ("average pixel values over NxM region"),
hardcoded to 3x3 size. As such, it works pretty well when downscaling images by
3x on each axis. But starts to break down and introduce aliasing at other
scaling factors. Also when scaling up or scaling down by less than 3x, using
total of 9 samples is a bit of overkill and hurts performance.
So instead, calculate the amount of NxM samples needed by looking at scaling
factors on X/Y axes. Note: use at least 2 samples on each axis, so that when
rotation is present, the result edges will get some anti-aliasing, just like it
was happening in previous filter implementation.
Images in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/117584
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
This patch adds support for _Menu Switch_ nodes and enum definitions in
node trees more generally. The design is based on the outcome of the
[2022 Nodes Workshop](https://code.blender.org/2022/11/geometry-nodes-workshop-2022/#menu-switch).
The _Menu Switch_ node is an advanced version of the _Switch_ node which
has a customizable **menu input socket** instead of a simple boolean.
The _items_ of this menu are owned by the node itself. Each item has a
name and description and unique identifier that is used internally. A
menu _socket_ represents a concrete value out of the list of items.
To enable selection of an enum value for unconnected sockets the menu is
presented as a dropdown list like built-in enums. When the socket is
connected a shared pointer to the enum definition is propagated along
links and stored in socket default values. This allows node groups to
expose a menu from an internal menu switch as a parameter. The enum
definition is a runtime copy of the enum items in DNA that allows
sharing.
A menu socket can have multiple connections, which can lead to
ambiguity. If two or more different menu source nodes are connected to a
socket it gets marked as _undefined_. Any connection to an undefined
menu socket is invalid as a hint to users that there is a problem. A
warning/error is also shown on nodes with undefined menu sockets.
At runtime the value of a menu socket is the simple integer identifier.
This can also be a field in geometry nodes. The identifier is unique
within each enum definition, and it is persistent even when items are
added, removed, or changed. Changing the name of an item does not affect
the internal identifier, so users can rename enum items without breaking
existing input values. This also persists if, for example, a linked node
group is temporarily unavailable.
Pull Request: https://projects.blender.org/blender/blender/pulls/113445
Part of overall "improve filtering situation" (#116980) task:
Add "Cubic Mitchell" filtering option to VSE strips. This is a cubic (4x4)
filter that generally looks better than bilinear, while not blurring the image
as much as the Cubic BSpline filter that exists elsewhere within Blender. It is
also default in many other apps.
Rename the (very recently added) VSE Bicubic filter option to Cubic BSpline.
Images in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/117517
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
Rename `BoneCollection::is_visible_effectively()` to
`is_visible_with_ancestors()`. Soon a "solo" flag will be introduced,
and the effective visibility of the bone collection will depend on that
too. This particular function doesn't take that into account, though,
and thus needs a rename.
Note that this does NOT rename the RNA property
`is_visible_effectively`. That will be updated when the "solo" flag is
introduced to also take that into account.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/117414
Cycles can use a per face flag to determine if a face is smooth or flat,
and there is no need to use corner normals in such cases. So revert to
not doing that as before, which also saves a bit of memory.
There is a pre-existing issue where faces are split by sharp edges and
autosmooth, which is not solved by this. It's only fixing the regression.
This adds the "Catmull-Clark" option to the subdivide modifier.
Since this option is creating 2^n segments, the "Simple" method was adjusted to do the same.
This is now consistent with the old GPv2 modifier.
Pull Request: https://projects.blender.org/blender/blender/pulls/117382
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
This is needed so extensions repositories can reference
user-script directories without them having hard-coded paths
which will be invalid when upgrading a Blender version.