When calculating the cavity factor, it is possible for the relative
distance of all traversed connected vertices to be zero. This results in
a division by zero which does not get clamped correctly to the expected
[0.0, 1.0] bounds. Prior to 4.2, this would have had no effect, as the
processing of this vertex would be have been skipped entirely. Due to
changes during the brush refactor, this flaw in the existing code was
exposed.
Pull Request: https://projects.blender.org/blender/blender/pulls/140168
Usually, this enum should only ever be compared with `==`.
Confusingly, however, to check if a strip is an effect, one must
'bitwise-and' it instead. This can backfire if e.g. one tries to do
(strip->type & STRIP_TYPE_IMAGE) which doesn't work.
Make sure we only ever 'and' against the type enum when checking if
it is an effect. There was only this one case that didn't adhere.
Partial revert of 5102880f51. That commit decreased pen tablet drag
threshold as pressure is added. Unfortunately, although this allowed a
quicker response to start of drag, this also increased the difficultly
of initiating a press when both actions are available. With numerical
inputs for example, although dragging is more responsive clicking into
the input to edit was more difficult.
Pull Request: https://projects.blender.org/blender/blender/pulls/140066
Introduced with 23951e1b12
The multiplane scrape brush uses two separate distances, one in world
space and the other in local brush space. Both need to be filtered on
for determining the brush strength.
Pull Request: https://projects.blender.org/blender/blender/pulls/140143
Similar to the recent fix 457cccd964.
There was another code path which could pass in the wrong time into USD
for certain Mesh Sequence Cache scenarios.
I was not able to craft a faulty scenario by hand to observe a real
problem though. The scenario begins by importing a USD file needing a
Mesh Sequence Cache modifier and then attaching a particle system (like
Hair) to the object. This will trigger the specific check calling into
`can_use_mesh_for_orco_evaluation` with the wrong time.
This makes the code path more explicit and passes in the correct time to
USD regardless now e.g. frame 28 vs time 1.166666666666667 (24fps)
Pull Request: https://projects.blender.org/blender/blender/pulls/140092
Prevent race conditions caused by calling `GPUWorker::wake_up` when the
worker is not waiting.
Found to be an issue in #139627, since `wake_up` is likely to be called
before the thread has fully started.
Pull Request: https://projects.blender.org/blender/blender/pulls/139842
When pressing Ctrl to snap the playhead while scrubbing,
Blender could crash while trying to snap to the first key.
This would happen if the current frame was higher than the
left keyframe, but the difference was less than the `BEZT_BINARYSEARCH_THRESH`.
Pull Request: https://projects.blender.org/blender/blender/pulls/140122
In Grease Pencil, when using the tools in Sculpt Mode and Vertex Paint
mode, the check on editable layers wasn't entirely accurate. There was
a strict check on an editable _active_ layer, but since the tools work
on _all_ editable layers, the check should be wider: if there is _any_
editable layer, the tool can work.
That is fixed in this PR. Now the tools can be used when, for example,
a layer group is active or when the active layer is hidden, but there
are other editable layers present.
In Vertex Paint mode there was an additional issue: with Auto Keying
enabled, a new keyframe was created for the active layer only. A new
keyframe should be created for _every_ editable layer. As is the case
now with this PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/140119
By definition, Bounds for single points (size zero) are empty (this
matches BLI_rct behavior), so doing an intersect will actually fail.
So to resolve, use the existing `is_point_inside_bounds` for single-
point-curves.
Pull Request: https://projects.blender.org/blender/blender/pulls/140124
Code selecting objects in collections that have been instanced was only
handling objects directly owned by the collection, not the objects in
the hierarchy of children collections.
The objects from the whole hierarchy need to be hanlded here, since
children collections will not be processed (as they are already
instanced by their parent one).
Pull Request: https://projects.blender.org/blender/blender/pulls/140068
Previous implementation allows to move VKBuffers, but didn't do a
proper std::move. On second thought it is a bad idea to be able to move
GPU resources. This PR removes the ability to move the buffer and
replace the usages with a unique ptr.
Pull Request: https://projects.blender.org/blender/blender/pulls/140103
The color picking reads 3 channels from a 4 channel texture. In the
common case the data conversion is required. Data conversion happens on
all 4 channels, but the backed memory only has 3 channels.
This is a workaround as the actual solution needs to work in many
different situations. Previous solution had to many issues that we
reverted the solution. This PR adds a local workaround specific to color
picking.
In Blender 5.0 we want to add test cases for all situations and
implement a solution that works better.
Pull Request: https://projects.blender.org/blender/blender/pulls/140101
Currently, we are forced to use `reinterpret_cast` (or c-style-casts) when
converting between `ID` and the actual data-block types like `Object` and
`Mesh`. While `reinterpret_cast` does preserve constness, it does nothing to
make sure that a cast is actually valid. This patch adds `blender::id_cast`
which can be used as a drop-in replacement of `reinterpret_cast` in supported
cases.
It supports a couple of cases (using `Object` as example for all data-block
types):
* Convert `ID *` to `Object *`. This asserts that the conversion is valid at
run-time if the pointer is not null.
* Convert `ID &` to `Object &`. This always asserts that the conversion is valid
at run-time.
* Convert `Object *` to `ID *`. This is preferred over `&object->id` even if the
result is the same because the latter results in ASAN warnings if `object` is
null.
* Convert `Object &` to `ID &`. Added for good measure. There isn't really much
of a benefit of this over using `object.id` except for maybe in generic code
where the source type can be an `Object &` or `ID &`.
* Identity cast identical id types (e.g. `Object *` to `Object *`). Not really
necessary to add a cast in such a case but may be useful in generic code where
the input can be an `Object *` or `ID *`.
Some additional notes:
* Const-correctness is preserved with this cast.
* When attempting to do a non-id-cast, the function triggers a `static_assert`.
* The data-block types must not be just forward declarations because the actual
type information is necessary.
* Casting to and from `void *` is not supported because that can't provide any
additional type-safety over `static_cast`.
* Casting between different data-block types like `Object` and `Mesh` is not
allowed.
* It does not support casting double-pointer types currently (e.g. `ID **` to
`Object **`).
The new cast is added in `DNA_ID.h`. As part of this patch, I also sprinkled in
a couple of `id_cast` in various places for testing (it's surprisingly tricky to
have the type checks working for all the different combinations of
pointer/referenced/constness/etc.). Replacing more existing `reinterpret_cast`
can be done separately afterwards.
It's nice that `blender::id_cast` has exactly the same length as
`reinterpret_cast`. So formatting should never change when using it in global
scope. Using just `id_cast` when inside of the `blender::` namespace is
preferable of course.
Pull Request: https://projects.blender.org/blender/blender/pulls/139820
The Ellipse/Box Mask nodes recently got their size clamped by their soft
limit, which was not previously the case, breaking compatibility and
limiting the node's use in some setups. The same goes for their
position. We fix this by allowing any size and position.
There have been a number of commits that have introduced regressions
in Sculpt mode where NaN begins to be propagated. While it is visually
very obvious that this is happening, this commit adds an assert so that
any automated testing with asserts on will also catch this issue.
Related to 23951e1b12
Pull Request: https://projects.blender.org/blender/blender/pulls/133992
Introduced with 23951e1b12
The paint brush uses either absolute or local distance values, mapping
this distance to a brush strength requires using different values for
`BKE_brush_calc_curve_factors` and cannot just use
`calc_brush_strength_factors`. To fix this, use the more generic method
instead to allow passing the correct radius.
Pull Request: https://projects.blender.org/blender/blender/pulls/140084
Introduced with 23951e1b12.
When using brushes that use a cube distance, some distances are set to
be float::max(). This breaks assumptions made inside the previously
linked commit, as the operations inside `BKE_brush_calc_curve_factors`
can easily cause this distance value to become infinity, which when
multiplied with the factor value of 0 results in NaN propagation in the
mesh.
To fix this, set the max distance in `calc_cube_distance` to 1.0f.
Pull Request: https://projects.blender.org/blender/blender/pulls/139965
On the Windows platform if you select "Automatic" for language, it
won't actually select correctly for the Chinese languages. This is
because our Windows code returns a locale like ""zh_CN" or "zh_TW",
not the "zh_HANS" and "zh_HANT" expected. This PR checks for language
code "zh" and will then will append "_HANT" if your 2-letter region
is TW (Taiwan), HK (Hong Kong), or MO (Macau), and "_HANS" for other
regions (like China, Malaysia, Singapore, etc).
Pull Request: https://projects.blender.org/blender/blender/pulls/140027
Depending on things like order or processing etc., appending
liboverrides data could generate error message in the console regarding
invalid override hierarchy data.
While this could probably be solved, it feels fairly brittle and risky
to directly make linked liboverride hierarchies locale anyway, so just
alsways make local copies of these on append.
Currently, there is the general rule that outputs must be above inputs in any
given panel. Since internally a panel toggle input is part of the panel that it
toggles and has to be the first item in a panel, it was not possible to have a
panel toggle for a panel with outputs.
This patch relaxes the rule for ordering of inputs and outputs for the special
case of panel toggles.
Pull Request: https://projects.blender.org/blender/blender/pulls/140054
Not only depend on the camera position but also on the other camera parameters.
This is important because otherwise Geometry Nodes won't be updated when e.g.
the focal length changes which is important when implementing e.g. camera
culling.
This already works when depending on a specific camera directly, but not when
depending on the active camera.
Pull Request: https://projects.blender.org/blender/blender/pulls/140046
To make this work, I had to add a new rna callback to get the default value for
an enum property at run-time. The same exists for other property types like
float and bool already.
Pull Request: https://projects.blender.org/blender/blender/pulls/140050
This fix make it so that the brush cursor is always the same size as
the drawn strokes.
The code logic is modified from `pixel_radius_to_world_space_radius`
in `grease_pencil_utils.cc`
Co-authored-by: Falk David <falk@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/139964
This allows to reduce the waiting time caused by
shader compilation on some GPU-driver combo.
A new settings in the User Preferences make it
possible to override the default amount of worker
threads and optionally use subprocesses.
We still use only one worker thread in cases where
there is no benefit with adding more workers
(like AMD pro driver and Intel windows).
It doesn't scale as much as subprocesses for material
shader compilation but that is for other reasons
explained in #139818.
Add some heuristic to avoid too much memory usage
and / or too many stalls.
Also add some heuristic to the default number of subprocess for
the platform that shows scalling.
Historically, multithreaded compilation was prevented by the
need of context per thread inside `DRWShader` module.
Also there was no good scaling at that time. But
nowadays numbers shows different results with
good scaling with reasonable amount of threads on many
platforms.
Even if we are going for vulkan in the next release
most of the legacy hardware will still use OpenGL for
a few other releases. So it is relevant to make this
easy improvement.
See pull request for measurements.
Pull Request: https://projects.blender.org/blender/blender/pulls/139821
Baking and storing simulation state within loops or closures is not supported.
Previously, attempting to use the bake node or simulation zone in such a zone
would just silently fail. Now there is an error on the node and the bake
settings are grayed out.
Pull Request: https://projects.blender.org/blender/blender/pulls/140041
Also unifies the min/default/max width of all group nodes. The minimum width
has been increased from 40 to 60 for Geometry Nodes because there was is
an assert when the node was that thin already. The other group nodes already
used 60 as min width.
From what I know, we don't really have a good way to detect whether a material
index is non-sensical in the right places. That's because the same material
index on a mesh may not make sense on one object but can still make sense on
another. This is the issue we fixed in the first place when the regression was
introduced.
What we can do though is to check which exact material indices a mesh is
actually using (not just the maximum). This allows us to skip a lot of work for
unused material indices. This doesn't help when a mesh has thousands of unique
non-sensical material indices, but it should be an improvement in the majority
of cases.
This patch adds a cache of used material indices to `Mesh`. The drawing code
requests that cache if the maximum material index is above some threshold (16
currently). We don't want to compute it all the time, because it requires
iterating over the mesh (at least once, then it is cached). So it's only worth
the extra cost of the there is at least one large material index. The threshold
also ensure that the large majority of scenes is not affected by this patch
performance wise.
Pull Request: https://projects.blender.org/blender/blender/pulls/139781
After 9e4c26574a, `relations_invalidate_cache()` for sound strips
returns without doing anything, but VSE code relied on this function to
tag scene to update `ID_RECALC_SEQUENCER_STRIPS` which is mostly audio
related. Since the name of this enum value is not very descriptive,
clarifying comment was added.
Pull Request: https://projects.blender.org/blender/blender/pulls/139991
Restore the BM_vert_is_edge_pair(v) check that was present prior to
!134017. In that PR, the edge pair check was moved up, to a previous
iteration pass, that checked the angle thresholds. However, even though
pairs were checked before, the process of performing edge merges might
change a neighboring vert such that it is no longer an edge pair.
Therefore it is necessary to check a second time.
Resolves regression in [0].
[0]: e418f7b1f1
A bug that was introduced in !131645 where the number of verts eligible
for dissolve was reduced, to prevent dissolving unrelated verts.
That PR changed the code to only do the dissolve check on verts at the
ends of selected edges, which solved bug #109765. However, this didn't
properly account for dissolving only one edge in a chain in a face pair.
This could result in cases where one of the vertices should be checked
but wasn't - if it wasn't selected.
Now when an edge is dissolved, each of its verts is checked,
and if it's in a chain, the VERT_MARK tag is moved down the
chain until it finds its natural endpoint.
Ref !139959.
When constant falloff is used, `BKE_brush_calc_curve_factors` doesn't do
any extra filtering of the given distances. The Plane brush previously
didn't filter the distances, leading to incorrect deformations when the
constant falloff was used.
To fix this, this commit makes a number of changes:
* `BKE_brush_calc_curve_factors` no longer sets the factor for an
element to 0 if it is outside of the provided distance. This is
replaced with an assert.
* The Plane brush and Cloth brush have an explicit
`filter_distances_with_radius` added.
Pull Request: https://projects.blender.org/blender/blender/pulls/139851
