This commit adds SculptBoundaryPreview to reduce the scope of variables
that the SculptSession has access to when displaying the preview for
using the Boundary brush. Further changes in this area will be made once
more of the relevant flood_fill and boundary code is refactored.
In particular, the main algorithm does not need the edge position data.
Pull Request: https://projects.blender.org/blender/blender/pulls/124759
This fixes a few issues and clear up some confusion
in the code.
Note that this changes the behavior of render region;
they now reduce the internal render size. This is
matching the new design documentation.
- Data passes have correct accumulation.
- Adhere to naming conventions for extents, film and render pixels.
- Jitter over final pixels first before doing random sampling
in order to speed up convergence.
- Ensure enough sample to cover at least all the film pixels once.
- Always include the four neighbor pixels in case one is nearer.
- Fix projection matrix computation to align overscan pixels.
Pull Request: https://projects.blender.org/blender/blender/pulls/124735
All the arrays in the new Action DNA are named singularly (`layer_array`,
`fcurve_array` etc). `channelbags_array` was the only plural one. For
consistency, this is now also singular.
Note that this is a backward-incompatible change, and will effectively
erase all animation from layered Actions. No effort is taken to handle this
rename as the feature is still in its experimental phase.
Action and slot assignments are not affected by this change.
Apart from the lack of backward compatibility, no functional changes are
expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/124768
Was using the old, not the modified name of the brush to build the brush
asset reference, that is used to identify the active brush asset.
The new brush was actually activated, but some of the UI like the asset
shelf would display it as such.
The fix contains two parts:
1. Grease Pencil v3 now stores stroke `init_time` as a float attribute,
it's not enough precisiton for unix timestamp. Now the time value is
truncated to allow better precision. It's still stored in seconds.
2. The previous logic for calculating stroke gap time of the build
modifier isn't correct, it used to only count two starting times as
gap time. Now it's fixed with correct delta time.
Pull Request: https://projects.blender.org/blender/blender/pulls/124350
This commit removes the extra initial_pivot_position variable from
SculptBoundary as well as the PBVHVertRef in favor of a single float3.
This value is effectively const for the lifetime of the struct in the
current state, as this value is only calculated and used at the
beginning of the brush stroke.
Pull Request: https://projects.blender.org/blender/blender/pulls/124755
This commit replaces the PBVHVertRef with specific float3 positions for
the edges. To ensure data is displayed correctly, we also remove the
conditional check on updating this data when drawing the cursor to
force recaculating the edge positions on the start of every brush
stroke.
Pull Request: https://projects.blender.org/blender/blender/pulls/124754
Issue happened in very old files only (pre 2.38), where versioning would
allocate tool-settings, without calling initialize logic for painting.
This should be fine, just handle the case properly where initialization
happens later, once the paint mode is actually entered.
Also adds missing default brush setting for this corner-case, where
texture paint data gets initialized only when entering the mode.
There was a case where we wouldn't convert edit curves correctly,
specifically when the user created an edit curve
(using "Curve Editing") and then changes the stroke outside of
curve editing. This invalidates the edit curve, but does not
deallocate it.
The conversion assumed that any allocated edit curve is valid.
Now we check for the `GP_CURVE_NEEDS_STROKE_UPDATE` flag
to skip invalid edit curves (and use the stroke instead).
This commit moves generated `RNA_blender.h`, `RNA_prototype.h` and
`RNA_blender_cpp.h` headers to become C++ header files.
It also removes the now useless `RNA_EXTERN_C` defines, and just
directly use the `extern` keyword. We do not need anymore `extern "C"`
declarations here.
Pull Request: https://projects.blender.org/blender/blender/pulls/124469
This adds a new mode to the Color Balance node, which applies a white point
transformation similar to the one applied in the view transform.
Unlike the view transform, the compositor node allows specifying both the
source and the destination white point for more flexibility. Both default
to the D65 white point, so just leaving the destination alone achieves the
same behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/124110
This allows the draw tool to temporarily enable the eraser.
Adds a new `BrushStrokeMode` called `BRUSH_STROKE_ERASE`.
This is used by the keymap to enable erasing while using
the draw tool with CTRL.
Pull Request: https://projects.blender.org/blender/blender/pulls/124591
Interpolation tool for strokes ported from GPv2.
Adds a new operator that inserts a new frame with interpolated curves.
The source curves are taken from the previous/next keyframe.
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/122155
Regular sound offsets (based on VSE strip offset) only worked with
negative values even if the waveform was draw correctly. Fix so positive
frame offsets does the correct thing.
The `resolution` and `nurbs_order` attributes of curves are expected to be `>=
1`. Due to a bug, it was possible that they are initialized to zero: #124534.
This fix adds versioning code to fix the curves that have been written
incorrectly.
Pull Request: https://projects.blender.org/blender/blender/pulls/124539
Previously, it was fairly easy to create built-in attributes which have invalid
values, because attributes were generally zero-initialized. This was especially
problematic for attributes that had certain invariants that Blender relies on
and that should never be zero. For example, the curve resolution should always
be at least 1.
To reproduce the issue, add the `resolution` attribute from the attributes panel
to curves. They had a value of 0 by default. I found this while investigating
#124416.
Pull Request: https://projects.blender.org/blender/blender/pulls/124534
Since the code only does anything if both substrings are found, implement
an early-out if either of them isn't found.
This seems like a micro-optimization at first, but since the current node
socket versioning requires looping over all AnimData in the file, this adds
up to e.g. 1.9sec saved when loading the Spring benchmark file.
Centralized method to obtain ScrArea icons. Areas can add an optional
space_icon_get callback to provide an icon that differs by subtype. If
not defined then ED_area_icon will return RNA UI icon, which is correct
in cases without area subtypes.
Pull Request: https://projects.blender.org/blender/blender/pulls/124556
Centralized method to obtain ScrArea names. Areas can add an optional
space_name_get callback to provide a name that differs by subtype. If
not defined then ED_area_name will return RNA UI name, which is correct
in cases without area subtypes. This eliminates the current use of
RNA_property_enum_name_gettexted using a temporary context, which
results in the reported (hard to duplicate) error.
Pull Request: https://projects.blender.org/blender/blender/pulls/124488
This replaces two members of `BlendfileLinkAppendContext`:
* `LinkNodePair libraries` -> `Vector<BlendfileLinkAppendContextLibrary *>`
* `LinkNodePair items` -> `std::list<BlendfileLinkAppendContextItem *>`
This simplifies the code quite a bit.
Making `libraries` a `Vector` works because afaik we never iterate over the
libraries while also adding new ones (which would invalidate iterators). It's
also nice, necause we use random access in some cases.
`items` can't become a vector, because afaik more items may be added while
iterating over it. So it's still a linked list now, but with a better type that reduces
boilerplate a lot.
Pull Request: https://projects.blender.org/blender/blender/pulls/124524
This changes the type of `new_id_to_item` from `GHash` to
`Map<ID *, BlendfileLinkAppendContextItem *>` which simplifies code. For this to work
nicely, `BlendfileLinkAppendContext` had to become a non-trivial type. Since it
was allocated with `calloc` before, I gave all members
zero-default-initializers.
This also changes `BKE_blendfile_link_append_context_new` so that it uses
`MEM_new` instead of allocating the `BlendfileLinkAppendContext` as part of the
memory arena, because that's the more common way to do it, and it does not seem
like saving this one allocation here makes a difference considering how this is
used.
Pull Request: https://projects.blender.org/blender/blender/pulls/124516
The call to `GHOST_DisposeSystemPaths` was done in `WM_exit_ex` and
_some_ of the tests' 'teardown'. But some more where missing. Issue was
only reproducible when defining `WITH_CXX_GUARDEDALLOC` cmake option.
There are several layers of issues here, this commit addresses the
first, simplest one: since `BKE_appdir` API will indirectly create the
GHOST SystemPaths data, it is simpler and more logical to move the
deletion of this SystemPaths data in `BKE_appdir_exit()`. This avoids
exposing a fairly low-level implementation detail all over our codebase.
Further more, `WM_init` also does not need to explicitely call
`GHOST_CreateSystemPaths`, since it will be created automatically when
required.
Caused by a060e96103
This change restores the old behavior of pass name detection from
channel name prior to the offending commit.
The fix includes regression test based on the files from related
reports, to help catching possible issues in the future.
Being so close to the release this commit restored behavior prior
to the previous fix. Potentially this makes some files to detect
wrong pass name for some specific files, although it is not really
clear if such files exists in the wild.
Pull Request: https://projects.blender.org/blender/blender/pulls/124458
Instead of hard-coding `IDType_ID_AC.dependencies_id_types =
FILTER_ID_ALL`, which is overly broad, determine its value dynamically
in `id_type_init()` so that it's purely based on which `IDType`s
identify as 'animatable'.
This should make things like ID remapping a bit more efficient, as the
remapping code knows that an Action will only reference animatable
data-blocks.
Note that the initial value for the filter is still `FILTER_ID_ALL`,
so that in cases where (by accident) the call to `BKE_idtype_init()`
is omitted, semantically the situation is still correct. Not calling
this function is an easy to make oversight when writing unit tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/124357
We generally do not want this struct to be copied due to its size. To
assist in finding development errors earlier, disable the copy
constructor entirely, as the destructor puts its resources into an
invalid state.
Pull Request: https://projects.blender.org/blender/blender/pulls/124439
This adds support for attaching gizmos for input values. The goal is to make it
easier for users to set input values intuitively in the 3D viewport.
We went through multiple different possible designs until we settled on the one
implemented here. We picked it for it's flexibility and ease of use when using
geometry node assets. The core principle in the design is that **gizmos are
attached to existing input values instead of being the input value themselves**.
This actually fits the existing concept of gizmos in Blender well, but may be a
bit unintutitive in a node setup at first. The attachment is done using links in
the node editor.
The most basic usage of the node is to link a Value node to the new Linear Gizmo
node. This attaches the gizmo to the input value and allows you to change it
from the 3D view. The attachment is indicated by the gizmo icon in the sockets
which are controlled by a gizmo as well as the back-link (notice the double
link) when the gizmo is active.
The core principle makes it straight forward to control the same node setup from
the 3D view with gizmos, or by manually changing input values, or by driving the
input values procedurally.
If the input value is controlled indirectly by other inputs, it's often possible
to **automatically propagate** the gizmo to the actual input.
Backpropagation does not work for all nodes, although more nodes can be
supported over time.
This patch adds the first three gizmo nodes which cover common use cases:
* **Linear Gizmo**: Creates a gizmo that controls a float or integer value using
a linear movement of e.g. an arrow in the 3D viewport.
* **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be
rotated to change the attached angle input.
* **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale.
In the future, more built-in gizmos and potentially the ability for custom
gizmos could be added.
All gizmo nodes have a **Transform** geometry output. Using it is optional but
it is recommended when the gizmo is used to control inputs that affect a
geometry. When it is used, Blender will automatically transform the gizmos
together with the geometry that they control. To achieve this, the output should
be merged with the generated geometry using the *Join Geometry* node. The data
contained in *Transform* output is not visible geometry, but just internal
information that helps Blender to give a better user experience when using
gizmos.
The gizmo nodes have a multi-input socket. This allows **controlling multiple
values** with the same gizmo.
Only a small set of **gizmo shapes** is supported initially. It might be
extended in the future but one goal is to give the gizmos used by different node
group assets a familiar look and feel. A similar constraint exists for
**colors**. Currently, one can choose from a fixed set of colors which can be
modified in the theme settings.
The set of **visible gizmos** is determined by a multiple factors because it's
not really feasible to show all possible gizmos at all times. To see any of the
geometry nodes gizmos, the "Active Modifier" option has to be enabled in the
"Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of
the following is true:
* The gizmo controls an input of the active modifier of the active object.
* The gizmo controls a value in a selected node in an open node editor.
* The gizmo controls a pinned value in an open node editor. Pinning works by
clicking the gizmo icon next to the value.
Pull Request: https://projects.blender.org/blender/blender/pulls/112677
Part of #118145.
The proxy system was used to store the accumulated translation from
the deformation of multiple symmetry passes. After a brush/tool update
step, all PBVH nodes with proxies were gathered, the proxies from
each symmetry passes were accumulated, and the deformation was applied
to the evaluated mesh, then the base mesh and shape keys.
In the recently refactored brushes, the translations are immediately
applied to the base mesh and shape keys instead. That avoids the need
for storing a float vector for every affected vertex during the
deformation. Reducing memory usage and affecting the memory that is
already hot in the cache has significant performance benefits too.
Also, brushes are now more conceptually independent-- they don't
rely on a separate pass to actually apply deformations.
Finally removing the proxy system reduces the size of PBVH nodes from
728 to 416 bytes. That's helpful as part of the effort to reduce per-
node overhead in order to make nodes smaller, and helps to reduce the
responsibilities of the PBVH, to focus it on being a BVH tree instead
of "bag for storing arbitrary user-interaction data."
This adds a new `name` member to the `GeometrySet` class. This name can be set
with the new `Set Geometry Name` node. Currently, the name is only used in the
spreadsheet when displaying instances.
The main purpose of this name is to help debugging in instance trees. However, in the
future it may also be used when exporting instance trees or when creating separate
objects from them.
Note, the name is not expected to be unique, it is fully in user control.
Naming geometries is necessary to make the spreadsheet more useful for instances,
because currently the user has no information for which geometry is used by each instance.
We also want to use this name to improve the integration with grease pencil where
sometimes layers become instances with the same name.
Pull Request: https://projects.blender.org/blender/blender/pulls/114910
Also see 06be295946.
These aren't all cases, but a few that I found by addding a static
assert in `MEM_new` so that it fails for trivially constructible types.
