This patch introduces the `Plane` brush, a generalization of the
existing `Flatten`, `Fill` and `Scrape` brushes, with the objective of
providing more flexibility when sculpting.
This brush has the following key features:
* `Height` and `Depth` parameters to control the range of the brush in
the local z-axis.
* Stabilizers for the normal and center of the brush plane.
When inverting, the user can choose between two options:
* `Invert Displacement`: Identical to the existing behavior, displacing
vertices away from the plane.
* `Swap Height and Depth`: Exchanges the roles of `Height` and `Depth`.
For example a brush with `Height` = 0.7 and `Depth` = 0.3 behaves as
if it had `Height` = 0.3 and `Depth` = 0.7. In particular, this
ensures that a scrape brush (`Height` = 1, `Depth` = 0) becomes
equivalent to a fill brush (`Height` = 0, `Depth` = 1) when inverted,
and viceversa.
In the existing planar brushes, the influence on a vertex is determined
by the 3D Euclidean distance between the vertex and the cursor position,
multiplied by the vertex's distance from the brush plane (and other
factors common to all brushes).
In the `Plane` brush, the 3D distance is between the vertex and the
plane center instead of the cursor position.
The Plane brush introduces two parameters — `Stabilize Normal` and
`Stabilize Plane`. These can be thought of as the non-binary version of
the `Original Normal` and `Original Plane` options found in existing
brushes. These values are a weighted moving average across a window of
previous stroke steps.
Pull Request: https://projects.blender.org/blender/blender/pulls/132723
Also adds a new `BLO_readfile_id_runtime_tags_for_write` accessor to
ensure readfile data is created before assigning a tag value.
Followup to 2ec1b6887d. Should cover the last existing ID tags that
can be moved to temp runtime readfile ID data.
This reverts commit aff2cf97a1, and re-apply 2612b27e42 fix the issue
fixed.
Grease Pencil layers can only be duplicated on the same object. Duplicating layers
from other objects will not insert the drawings into the target object and just
assume that drawing indices remain valid, which is not the case. The subsequent
drawing index user update crashes Blender.
This fix adds a new `copy_frames_from_layer` function that makes a full copy
of layer data, regardless of where that layer originates from. This is safe to use
with layers that live in other objects.
Pull Request: https://projects.blender.org/blender/blender/pulls/133722
The dolly operators poll function was set to `view3d_rotation_poll`
instead of `view3d_zoom_or_dolly_poll` which reads like a mistake.
As it happens this didn't cause any user visible problems because
RV3D_LOCK_ZOOM_AND_DOLLY is only set when all other locks are set.
Nevertheless, logically the dolly operator should check that dolly
is not locked. Updated the poll function for dolly to check neither
rotation or zoom/dolly is locked with comments noting why both are
needed.
Also expand on code-comments for why dolly enforces perspective view.
Creates a very mysterious crash in nodetree code when using deprecated
'full undo'. Needs more investigation, we need to understand what's
happening here!
This reverts commit 2612b27e42.
Also adds a new `BLO_readfile_id_runtime_tags_for_write` accessor to
ensure readfile data is created before assigning a tag value.
Followup to 2ec1b6887d. Should cover the last existing ID tags that
can be moved to temp runtime readfile ID data.
Pull Request: https://projects.blender.org/blender/blender/pulls/133715
This patch changes how the Wrap option in the Translate node works. It
now repeats infinitely when realized, and not just in its own domain.
This is essentially how it used to work prior to version 4.2, so we are
reverting that change. We also rename Wrap to Repeat for clarity.
This is part of an ongoing to project to allow the user to control how
boundaries and empty areas are filled after transformations. So similar
options will be added to all transform nodes. But this patch is the
first step, since the functionality is already there, we just need to
extend it to work in all domains.
Pull Request: https://projects.blender.org/blender/blender/pulls/133766
Artists often want to quickly switch back and forth between two or more nodes while compositing.
This patch implements two operators `NODE_OT_viewer_shortcut_set` and `NODE_OT_viewer_shortcut_get` that allow users to map a viewer node to a shortcut. For example, pressing `cltr+1` while a node is selected, assigns that node to the shortcut `1`, creates a viewer node if it has none attached and sets that viewer node to active. Pressing `1` will set the active node with shortcut `1` to active.
Shortcuts are saved in DNA to preserve them after saving/loading blend files.
Limitations:
- Only compositor node tree is supported, because shading editor has no viewer node and geometry nodes viewer works differently.
Pull Request: https://projects.blender.org/blender/blender/pulls/123641
The core issue was that the geometry batch cache (e.g. `MeshBatchCache` or
`PointCloudBatchCache`) was dependent on the object. This is problematic when
the the same geometry is used with multiple different objects because the cache
can't be consistent with all of them.
Fortunately, the only thing that was retrieved from the object was the number of
material slots, so if that can be avoided we should be fine. We can't just use
the number of material slots stored on the geometry because that may have no
material slots but still has material indices which are overridden on the object
level.
The solution is to take make the number of materials for a geometry only
dependent on the actual `material_index` attribute and not on the number of
available slots. More specifically, we find the maximal referenced material
index and handle that many materials. This number does not depend on how many
material slots there are on the object, but it still allows the object to
override materials slots that the mesh references.
A downside is that the maximum material index has to be computed which often
requires an iteration over the mesh. Fortunately, we can cache that quite easily
and the computation can be done in parallel. Also we are probably able to
eagerly update the material index in many cases when it's set instead of
computing it lazily. That is not implemented in this patch though.
The largest part of the patch is making the maximal material index easily
available on all the geometry types. Besides that, the material API is slightly
replaced and the drawing code now makes use of the updated API.
Pull Request: https://projects.blender.org/blender/blender/pulls/133498
This adds a new `DNA_print.hh` header which contains functions to print DNA
structs with all their data members in a human readable form. This is intended
for debugging purposes.
The basic usage is very straight forward: `DNA_print_struct(TypeName, data);`.
For example: `DNA_print_struct(bNode, node);`.
There is also `DNA_print_structs_at_address` which is primarily useful when
debugging what is written to a .blend file.
This was originally developed for #133063, but is already quite useful on its
own.
Pull Request: https://projects.blender.org/blender/blender/pulls/133432
Both Image and Sequencer vectorscopes used YUV U,V coordinates
as-is, but their possible ranges are different: +-0.436 and
+-0.615 respectively.
It looks like more other software (ffmpeg, shotcut, etc.)
re-scales the vectorscope UV to fill up a square, i.e. streches
out the horizontal values, so do the same.
This fixes the "skin tone indicator" line, which at 123 degrees
(90 + 33 degrees to match positive I axis of YIQ color space) was
placed assuming the UV values fill up a square. So it was at the
wrong angle before.
The vectorscope horizontal scaling and skin tone indicator line now
matches other open source (ffmpeg, shotcut) and commercial (davinci
resolve, final cut pro) software packages.
Images in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/133316
GPv2 used the depth buffer at the end of a stroke drawing operation to project points and interpolated between detected values. This does not work in GPv3 because the strokes are added directly to drawings. Depth projection has to happen continuously, updating points between the last depth value and the next when a new hit is recorded.
Resolves#125258.
Pull Request: https://projects.blender.org/blender/blender/pulls/131842
This patch automatically grays out input values which can't affect the output
currently. It works with inputs of group nodes, geometry nodes modifiers and
node tools.
To achieve this, it analyses the node tree and partially evaluates it to figure
out which group inputs are currently not linked to an output or are disabled by e.g.
some switch node.
Original proposal: https://devtalk.blender.org/t/dynamic-socket-visibility/31874
Related info in blog post:
https://code.blender.org/2023/11/geometry-nodes-workshop-november-2023/#dynamic-socket-visibility
Follow up task for designing a UI that allows hiding sockets: #132706
Limitations:
* The inferencing does not update correctly when a socket starts being
animated/driven. I haven't found a good way to invalidate the cache in a good
way reliably yet. It's only a very short term problem though. It fixes itself
after the next modification of the node tree and is only noticeable when
animating some specific sockets such as the switch node condition.
* Whether a socket is grayed out is not exposed in the Python API yet. That will
be done separately.
* Only a partial evaluation is done to determine if an input affects an output.
There should be no cases where a socket is found to be unused when it can actually
affect the output. However, there can be cases where a socket is inferenced to be used
even if it is not due to some complex condition. Depending on the exact circumstances,
this can either be improved or the condition in the node tree should be simplified.
Pull Request: https://projects.blender.org/blender/blender/pulls/132219
Resolve an error where the brushes from the image/3D viewport
where shared but the tool was not. Causing the brush not to match
the appropriate tool when both an image & 3D viewport were displayed.
Resolve the issue by adding support for a "pending" tool,
a tool ID which is to be used.
This accounts for cases where it's not known if the requested tool
exists and uses the same code paths for initializing tools as is done
for initializing on file load for e.g.
Ref !133085
The hardcoded value doesn't work well with real scale human heads for
example (was already adjusted once in a76b5d3a07).
The result for too high values is a complete "freeze" of the whole curve
(since the solution from e7606139ba has the problem that it keeps
running into max iterations of the collision solver).
As long as no better solver is implemented, it is better to have an
adjustable value (to work on differently sizes objects) to not run into
the above issue (same as the old particle hair system had) and show it
in sculptmode next to the button which enables collision.
This is done per `Curves` (same as the flag
`CV_SCULPT_COLLISION_ENABLED`), similar to symmetry settings
[alternatively, it could be part of `BrushCurvesSculptSettings` but I
think it makes more sense in Curves] and then passed on to the
`CurvesConstraintSolver`.
Includes versioning code (to set the default for old files).
Pull Request: https://projects.blender.org/blender/blender/pulls/132997
This makes specifying a legacy type for new node types optional (e.g.
`GEO_NODE_MESH_TO_CURVE`). Instead, only the `idname` is used as a stable
identifier for node types. So there is less redundancy for now.
This change helps with the decentralized definition of nodes and reduces the
number minimum number of files that need to be changed for a new node from 5 to
4. It especially helps when multiple nodes are worked on at the same time,
because the legacy type definition was very prone to have merge conflicts.
For compatibility reasons and because it's still used by existing code, the
`legacy_type` is not removed. All existing nodes keep their current
`legacy_type`. New nodes will receive an auto-incremented legacy type. It's
still necessary to give nodes unique legacy types, because some code checks if
two nodes have the same type by comparing their `legacy_type`. These types only
have to be unique at run-time though. Some randomness is used to avoid depending
on stable generated legacy types accidentally.
Pull Request: https://projects.blender.org/blender/blender/pulls/133044
`flip_axis` is currently an enum RNA property. This makes impossible to
toggle the individual axis. Now fixed by converting the property to
boolean. UI drawing code is same as done for mirror modifier.
New enum values are introduced for each axis
Resolves#70237
Pull Request: https://projects.blender.org/blender/blender/pulls/132849
A pass at cleaning up / improving the code documentation for the layered action
C++ classes.
There is still more work to do here, but this should be good for an initial
first pass. I've focused on clarifying the behavior of and updating stale docs
of the methods in the action-related C++ classes.
Pull Request: https://projects.blender.org/blender/blender/pulls/131318
Main goals of this refactor:
* Make it more obvious which update function should be used.
* Make it more obvious which parameters are required by using references instead
of pointers.
* Support passing in multiple modified trees instead of just a single one.
No functional changes are expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/132862
The `bNode.type_legacy` is still used in many places to check if a node is a
specific type. However, going forward it's better to rely more on the idname
than on this legacy integer type. Some more information is available in #132858.
The added utility method can be used like so:
`node->is_type("GeometryNodeMenuSwitch")`. Previously one would have written
`node->type_legacy == GEO_NODE_MENU_SWITCH`. The `is_type` method internally
checks that the passed in string is a valid node identifier to make it more
likely that we catch typos early.
Pull Request: https://projects.blender.org/blender/blender/pulls/132863
The new description for `bNode.type_legacy`:
```
/**
* Legacy integer type for nodes. It does not uniquely identify a node type, only the `idname`
* does that. For example, all custom nodes use #NODE_CUSTOM but do have different idnames.
* This is mainly kept for compatibility reasons.
*
* Currently, this type is also used in many parts of Blender, but that should slowly be phased
* out by either relying on idnames, accessor methods like `node.is_reroute()`.
*
* A main benefit of this integer type over using idnames currently is that integer comparison is
* much cheaper than string comparison, especially if many idnames have the same prefix (e.g.
* "GeometryNode"). Eventually, we could introduce cheap-to-compare runtime identifier for node
* types. That could mean e.g. using `ustring` for idnames (where string comparison is just
* pointer comparison), or using a run-time generated integer that is automatically assigned when
* node types are registered.
*/
```
Pull Request: https://projects.blender.org/blender/blender/pulls/132858
Make the type structs non-trivial, use new and delete for allocation and
freeing, and use std::string for most strings they contain. Also use
StringRef instead of char pointers in a few places. Mainly this improves
ergonomics when working with the strings.
Pull Request: https://projects.blender.org/blender/blender/pulls/132750
UnitSettings::scale_length was used to scale reported
values for operators (translate, shrink-fatten, voxel-size).
This isn't expected as the value isn't editable when the unit-system
is set to None.
Add BKE_unit_value_as_string_scaled utility function for clarity &
to ensure scaling is only applied when it should be.
When using clangd or running clang-tidy on headers there are
currently many errors. These are noisy in IDEs, make auto fixes
impossible, and break features like code completion, refactoring
and navigation.
This makes source/blender headers work by themselves, which is
generally the goal anyway. But #includes and forward declarations
were often incomplete.
* Add #includes and forward declarations
* Add IWYU pragma: export in a few places
* Remove some unused #includes (but there are many more)
* Tweak ShaderCreateInfo macros to work better with clangd
Some types of headers still have errors, these could be fixed or
worked around with more investigation. Mostly preprocessor
template headers like NOD_static_types.h.
Note that that disabling WITH_UNITY_BUILD is required for clangd to
work properly, otherwise compile_commands.json does not contain
the information for the relevant source files.
For more details see the developer docs:
https://developer.blender.org/docs/handbook/tooling/clangd/
Pull Request: https://projects.blender.org/blender/blender/pulls/132608
This patch redesigns the Glare node to improve the user experience. The
improvements are as follows.
Two new outputs were added, Glare and Highlights. The Glare output gives
the generated glare without the input, and is useful when the user wants
to adjust the glare before adding it to the image. The Highlights output
gives the areas that are considered highlights when computing the glare,
and is useful if the user wants to temporally check the highlights while
doing adjustments or wants to use those as a base for creating a custom
glare setup.
The Mix node option was removed and a new Strength single value input
was added to serve the same functionality. The Mix option had a range of
[-1, 1], where the [-1, 0] sub-range essentially controlled the strength
of the glare, 0 being full strength and -1 being zero strength. While
the [0, 1] range returned the generated glare with an attenuated version
of the image added, that is, it was useless except for the value of 1,
which returned the generate glare only.
Aside from being a very intuitive range, it also meant that the power of
glare can't be boosted beyond the full strength of, you guessed it, 0.
The newly added Strength input has a soft range of [0, 1] and can be
boosted beyond 1. If the users want the glare only, they can use the
newly provided Glare output.
The Size node option used for Bloom and Fog Glow was removed and a new
Size single value input was added. The Size node option had yet another
very intuitive range of [1, 9], and it was related exponentially to the
actual size of the Glare. For Bloom, the actual bloom size relative to
the image was 2^(Size-9), so a Size of 8 means the bloom covers half of
the image. For Fog Glow, the actual bloom size in pixels is 2^Size, so
the glare size is not relative to the image size and would thus change
as the image resolution change. Furthermore, the maximum possible glare
size was 512 pixels, and the user couldn't make fine adjustments to the
size.
The newly added Size input has a range [0, 1], where 1 means the glare
covers the entire image, 0.5 means it covers half the image, and so on.
That means it is consistent between Bloom and Fog Glow, it is relative
to the image size, it allows as large of a glare as possible, it is
continuous for Fog Glow, but not for Bloom because that requires an
algorithmic change that will be implemented separately.
The Threshold, Streaks, Streaks Angle, Iterations, Fade, and Color
Modulation node option was turned into a single value node input to
allow the option to be used in node groups.
---
Versioning was added to transfer node options into sockets, but it is
not all 1:1 versioning, since the old Size option was not relative to
the image size, so it depends on runtime information of the input size.
As a guess, we assume the render size in that case. Versioning the
[0, 1] range of the Mix option intentionally omits the attenuation of
the image input, because that is almost certainly not what the user
wants and was probably done thinking it controls the strength.
Glare code now sets the alpha channel to 1, that's because it was
already ignored in the mixing step, but now that we expose the Glare
output, we need to set it to 1. So this is not a functional change.
The get_glare_size() method was renamed for clarity since it now
conflicts with the newly added Size input.
---
This is a partial implementation of #124176 to address #131325. In
particular, it adjust existing functionality, it doesn't add any new
ones. Those will be added in separate patches.
Pull Request: https://projects.blender.org/blender/blender/pulls/132499
This renames the struct `Sequence` to `Strip`.
While the motivation for this partially comes from
the "Sequence Design" #131329, it seems like this
is a good refactor whether the design gets implemented
or not.
The `Sequence` represents what users see as strips in the
VSE. Many places in the code already refere to a `Sequence`
as "strip". It's the C-style "base class" of all strip types.
This also renames the python RNA type `bpy.types.Sequence`
to `bpy.types.Strip` which means that this technically breaks
the python API.
Pull Request: https://projects.blender.org/blender/blender/pulls/132179
Move the `ID_TAG_ID_LINK_PLACEHOLDER` bit of `id->tag` to
`id->runtime.readfile_data->tags.is_id_link_placeholder`. It also
introduces the necessary stucts and allocation/freeing code.
Old code:
```cpp
if (id_tag & ID_TAG_ID_LINK_PLACEHOLDER) {
```
New code:
```cpp
if (readfile_id_runtime_tags(id).is_id_link_placeholder) {
```
where `readfile_id_runtime_tags(id)` is a getter for
`id->runtime.readfile_data->tags` that is null-safe for
`id->runtime.readfile_data`. The `readfile_data` is not allocated in
these cases:
1. When reading undo steps, because that doesn't have to deal with
versioning or linking (which are the sole purposes for this
struct).
2. When linking from another file (for example from the 'Link...'
operator). The just-linked IDs will have the `readfile_data`
struct, but already-loaded IDs will already have had those freed.
No functional changes intended.
Pull Request: https://projects.blender.org/blender/blender/pulls/132169
Design Task: #131695
This commit exposes the "Quality" option of the Open Image Denoiser
to the user for the denoise node in the compositor.
There are a few quality modes:
- High - Highest quality, but takes the longest to process.
- Balanced - Slightly lower quality, but usually halves
the processing time compared to High.
- Fast - Further reduce the quality, for a small increase in
speed over Balanced.
Along with that there is a `Follow Scene` option which will use the
quality set in the scene settings.
This allows users that have multiple denoise nodes
(E.g. For multi-pass denoising), to quickly switch all nodes between
different quality modes.
Performance (denoising time):
High: 13 seconds
Balanced: 6 seconds
Fast: 5 seconds
Test setup:
CPU: AMD Ryzen 9 5950X
Denoising a 3840x2160 render
---
Follow ups:
Ideally the "Denoise Nodes" UI panel in the render properties panel
would be hidden if the compositor setup does not contain any
denoise nodes.
However implementing this efficiently can be difficult and so it was
decided this task was outside the scope of this commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/130252
The `socket->index_in_tree()` method provides a unique index for that socket
in the node tree (it's a cached runtime value). By construction, all input/output
sockets of a node have consecutive numbers, but this (sometimes useful) fact
is currently not exposed in the API.
This patch adds new `input_socket_indices_in_tree` and
`output_socket_indices_in_tree` methods to get the range of indices for all
inputs or outputs of a node.
