Without boost::locale, there seems no particular reason to modify the
global locale, we can just translate strings ourselves.
Other locale facets like numeric and time are also left unchanged
from the default, which is the "C" locale. This appears to match
previous Blender behavior with boost::locale. That protects against
bugs where formatting floats for I/O unexpectedly depends on the
system language.
Pull Request: https://projects.blender.org/blender/blender/pulls/133347
This bug occurs when the user deletes the rightmost stop on a
color ramp with 2 stops. After doing this, the color ramp appears
to stop updating its results.
This bug is due to a shader optimization for color ramps. For ramps
with 2 stops or less, the first and second stops are hardcoded as
inputs to get the results of the color ramp. When deleting the
rightmost stop, the stop's data isn't actually changed. The ramp
just updates its total stop number. Because of this, the result of
the color ramp won't change.
This is fixed by only allowing this optimization when a ramp has
exactly 2 stops. This solution works well since it keeps color ramp
code neat and concise. It also makes more logical sense to only allow
this optimization to work with 2 stops since it uses 2 hardcoded values
from the color ramp. It's also unlikely this will lead to adverse
performance problems since it doesn't make sense to use a color ramp
with 1 color stop. In that case, the user should just use an RGB node.
Another possible solution for this problem would be to update the data
for the second stop in the color ramp to exactly match the first when
deleting the second stop. However, this is undesirable since the code
wouldn't make much sense to those who don't know about the color ramp
optimizations.
Pull Request: https://projects.blender.org/blender/blender/pulls/132951
`BKE_unit_value_as_string` was modified in e949ff7334
to include a `BKE_unit_value_as_string_scaled` version, some places on
the interface needs to use the scaled version to show the string, this
includes ruler gizmo length text.
Pull Request: https://projects.blender.org/blender/blender/pulls/133373
Avoid breaking with a partially initialized `highpoly` as this
could cause complications when freeing members in the future.
Also use variables for brevity.
Changes in [0] broke baking to objects with animated render visibility,
causing render visibility override not to work.
Resolve by disabling visibility optimizations.
Ref !133358
[0]: 0dcee6a386
Prior to the brush refactor in 4.3, the cavity automasking feature
had an implicit dependency on stable position values. In many cases,
such as during brush evaulation, this was upheld by the usage of the
proxy system, which meant that even if a vertex's neighbor was changed
during a stroke in paralell, these changes would not be accessed until
after a stroke finished.
With the new method of brush evaulation removing the proxy system, this
introduced subtle artifacts on BVH node boundaries, as vertices were
guaranteed to change and cause differences as there was no temporary
storage to use the "old" position data. This effect was most noticable
in 4.3 and beyond in multires sculpting, though similar artifacts can be
seen when using the mesh filter in all prior versions.
To fix these issues, instead of calculating the internal cavity factor
during a stroke or during deformations, we calculate it ahead of time
based on the affected nodes of a stroke. This has the benefit of now
behaving consistently for a given mesh and given brush or filter
application.
From a performance perspective, this change should have no noticeable
impact, as each BVH node, and by extension each vertex, only has its
corresponding cavity factor calculated once, when the stroke would
affect the node.
Related: #102745
Pull Request: https://projects.blender.org/blender/blender/pulls/133224
This can be useful when going from a selection of curves to the corresponding
selection of points.
The simple implementation given here should work quite well in the majority of
cases. There is still optimization potential for some cases involving masks with
many gaps. The implementation is also single threaded for now. Using
multi-threading is possible, but should ideally be done in some way to still
lets us exploit the fact that the index ranges are already in sorted order.
Pull Request: https://projects.blender.org/blender/blender/pulls/133323
Color to grayscale conversions should take into account the colorspace,
and these are considered to be in scene linear colorspace.
Note the RBG to BW node implementation is used for implicit conversions,
so that is covered as well.
No change with the default configuration.
Pull Request: https://projects.blender.org/blender/blender/pulls/133368
Color to grayscale conversions should take into account the colorspace,
and these are considered to be in scene linear colorspace.
No change with the default configuration.
Pull Request: https://projects.blender.org/blender/blender/pulls/133368
This builds on top of 80441190c6 to gray output
unused inputs of the Mix and Mix Shader node. These nodes have unused inputs if
their mix factor is 0 or 1 (+ some special cases for non-uniform vector mixing
and blend modes).
Pull Request: https://projects.blender.org/blender/blender/pulls/133369
When there was an empty (no keyframes) track in the motion tracker's
dopesheet, Blender would crash when running the Frame All operator.
The issue was that the code computing the frame range was trying to
access non-existant data on the empty track, leading to a null pointer
dereference.
This fixes the issue by guarding that code with a nullptr check.
Pull Request: https://projects.blender.org/blender/blender/pulls/133371
The MaskLayer.invert property has "Restrict View" as its label. I
suspect this was an error during the commit that introduced the
feature. This commit simply renames it to "Invert".
Reported by Gabriel Gazzán.
Pull Request: https://projects.blender.org/blender/blender/pulls/132521
VKRenderGraphNode is 892 bytes and most of the bytes are used for
specific nodes. By storing large structs in separate vectors we can
reduce the needed memory and improve cache pre-fetching.
With this change the VKRenderGraphNode is reduced to 64 bytes.
On a (50 frames shader_balls.blend) the end user performance is improved by
2%.
| **Platform** | **Before** | **After** |
| ---------------- | ---------- | --------- |
| AMD W7700 | 1409 ms | 1383 ms |
| NVIDIA RTX 6000 | 1443 ms | 1428 ms |
Pull Request: https://projects.blender.org/blender/blender/pulls/133317
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
The interpolate tool was using a linear re-sampling of the curves, which changes
non-uniform point distributions can causes unexpected shifts in points along the
curve, even very close to an input stroke (mix factor ~0 or ~1).
This patch adds an alternative interpolation function with explicit segment
indices and fractions, which can then be computed by the interpolation tool.
The point segment factors are chosen such that each point of the input strokes
has an exact matching point in the interpolation. When the factor is close to
0 or 1 the shape of the curve thus matches the respective input exactly.
This approach is more similar to what GPv2 did, except instead of sub-dividing
each segment it simply generates a _local_ uniform sample to fit more points
into the same segment. These extra points are colinear at the extremes of the
mix factor range, so the curve matches the input curves visually.
Pull Request: https://projects.blender.org/blender/blender/pulls/130594
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
This PR adds new RNA properties that deprecate and replace any `sequence` property.
The old prooperties are still there and fully functional, but the description is changed
to indicate that these will be removed in the future and that the new properties should
be used instead.
| Deprecated property | Replacement property |
| --------------------------------- | ----------------------------------- |
| `context.active_sequence_strip` | `context.active_strip` |
| `context.selected_editable_sequences` | `context.selected_editable_strips` |
| `context.selected_sequences` | `context.selected_strips` |
| `context.sequences` | `context.strips` |
| `SequenceEditor.sequences` | `SequenceEditor.strips` |
| `SequenceEditor.sequences_all` | `SequenceEditor.strips_all` |
| `MetaStrip.sequences` | `MetaStrip.strips` |
Previously, rna paths for animation data on strips started with `sequence_editor.sequences`.
This PRadds versioning for the rna paths to make sure to use
the new naming scheme. This does mean that in previous versions of blender,
the animations don't show but the data is not lost (even if the file is saved in the older version).
Also do some cleanup of existing python scripts inside the source to use the
new properties.
Part of #132963.
Pull Request: https://projects.blender.org/blender/blender/pulls/133156
If source drawings are on different frames, operator is squashing them in
first frame on dst layer. Now fixed with corrected condition. If value
does not exist at given frame_number/key inside frames() map, add a new
frame on dst layer.
Pull Request: https://projects.blender.org/blender/blender/pulls/133361
Baking could fail to access an objects evaluated mesh data (see #107426),
while the error remains, prefer an error instead of crashing.
Since the depsgraph runs Python callbacks I don't think we can
provide a guarantee the mesh data will available, so even if #107426
is fixed, it's reasonable to have a check here.
`GPENCIL_draw_scene` uses `pd->tobjects.first == nullptr` to determine
whether to early return (draw nothing). When there's only "In Front"
grease pencil objects in scene, `tobjects.first` can be `nullptr` but
`tobjects_infront.first` is valid, in which case no grease pencil would
be drawn. Becase `gpencil_object_cache_sort` will link those two command
lists both to `tobjects` and allow `infront` ones to draw after others,
thus move it before the early return to allow drawing to proceed
normally.
Pull Request: https://projects.blender.org/blender/blender/pulls/132155
Slight displacement in mouse position triggers timer reset (pass=1).
With such condition, new redraw call to tooltip sets non zero timer
value (`r_pass_delay`) and `is_label=true` inside `ui_but_tooltip_init`.
This label boolean further skips drawing of description (for example, see:
`ui_tooltip_data_from_tool`).
To resolve this situation, inside timer_reset function keep `pass=0`
when tooltip region exists (i.e label is already visible on tooltip)
Pull Request: https://projects.blender.org/blender/blender/pulls/133258
Changes to the formatting of the OS window title for MacOS platform to
better follow their guidelines. Some refactoring, but there should be
no changes seen on other platforms.
Pull Request: https://projects.blender.org/blender/blender/pulls/132410
While the RecentFile struct itself was removed from the list of recent
files, the `filepath` field was not freed. Use the already existing
`wm_history_file_free` function to perform the cleanup.
Pull Request: https://projects.blender.org/blender/blender/pulls/133354
Previously, when evaluated on the face corner domain, the normal input
node just returned the face normals, as if the mesh was completely flat
shaded. This ignores face and edge smoothness, and custom face corner
normals. In the past couple years the expected behavior of accessing
normals has become much clearer and this behavior is clearly a mistake
in retrospect.
This commit exposes the same face corner normals used everywhere else
in Blender when the node is evaluated on the corner domain. The old
behavior is accessible with a node property in the sidebar. There is
versioning so old files have the property set and get the same results.
This is split from !132583.
Pull Request: https://projects.blender.org/blender/blender/pulls/133340
Now the output socket checks if the corresponding inline socket that it should
be aligned with is visible.
This is an alternative to #133271 which had the problem that it resulted in
`flat_item::Socket` instances for which the input and output is `nullptr`.
Pull Request: https://projects.blender.org/blender/blender/pulls/133325
Similar to `bpy.data.user_map`, it returns a mapping of IDs to all the
filepaths they use.
Fairly basic still, may need to be refined with more options to
control which filepaths are included etc.
Mainly intended to make handling of a production blendfile dependencies
more easy.
Also adds some basic testing of the new feature.
Pull Request: https://projects.blender.org/blender/blender/pulls/127252
With an asset library configured in the Preferences that had an empty
path, the catalog tree of the "Current File" asset library would be
empty. That is because the path-less library would incorrectly be
considered as containing the current file's path (`BLI_path_contains()`
returned true for the empty path).
Before slotted actions, it was only useful to stash an action once on a
data-block: that was all that was needed to keep the action's channels
associated with the data-block, and stashing it multiple times was redundant.
Therefore Blender would simply refuse to stash an action if it was already
stashed.
However, now with slotted actions the user may legitimately want to stash an
action more than one time: if the action has multiple slots, the user may want
to keep the channels of multiple slots all associated with a data-block. Doing
that requires stashing each action+slot combination separately.
This PR addresses this use case by now allowing each action+slot *combo* to be
stashed once. Stashing a given action+slot combo more than once per data-block
is still prevented, however, since that is still redundant.
Pull Request: https://projects.blender.org/blender/blender/pulls/133307
