Since 427bdc8dcf there is some trickery going on to make the underlying
view-item button slightly bigger, but that unintentionally also scaled
up the layout drawn on top of it. This would be visible whenever the
background is drawn, e.g. by using a different emboss type or when an
animated property was displayed.
Animation state of any property is not colored in tree-view structure.
This is due to wrong emboss value. `widget_color_blend_from_flags`
returns correct theme value if emboss is not `UI_EMBOSS_NONE`.
`UI_EMBOSS_NONE_OR_STATUS` is preferred for animating properties.
Pull Request: https://projects.blender.org/blender/blender/pulls/120298
This adds two functions to the `Drawing` class: `fill_colors()`
and `fill_colors_for_write()`.
In places where the attribute API was used directly, these
functions are now used instead.
This is part of #119080. The point is that developers
shouldn't need to remember the name, type, default value,
and domain of built-in attributes (e.g. used by the renderer).
Pull Request: https://projects.blender.org/blender/blender/pulls/120296
e64b3c821252fc8707b4 worked to complete a transition started during 2.8
development to avoid dynamically re-evaluating objects outside of the
dependency graph's control. However, that behavior was used to make
sure the original index mapping was available for the texture paint
sample operator.
Conceptually, sampling a texture on an arbitrary evaluated mesh should
not require original indices at all. All we need to know is the UV map
value under the mouse. This commit changes from using GPU index textures
to a BVH tree raycast. This significantly simplifies the code and makes
it work with GPU subdivision too. Though it may be slower to build the
BVH tree, that should be okay because it's cached and only needs to be
built once, and that's something we're want to optimize anyway.
Removing the reliance on original indices also means we could paint
textures on completely procedurally generated meshes, which may be
an interesting feature in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/120259
Instead of using `short key_type`, use `eBezTriple_KeyframeType key_type`,
so that it's clear which type it is, and so that a `switch()` can cause
compiler warnings when it's incomplete.
This also adds missing `case`s to `switch`es where necessary, in a way
that doesn't affect the outcome. There is one change that looks like it
is a functional change, but it should provide the same result:
```diff
- size -= 0.8f * key_type;
+ size *= 0.8f;
```
Since `size = 12` and in this case `key_type = 3`, the numerical values
are the same, but now the code is consistently multiplying and thus should
scale properly.
Furthermore some overly obvious comments are removed and some missing
`const` keywords have been added.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/120178
The Vector Blur implementation slightly differs between CPU and GPU due
to different precision in the sqrt2 constant, so use the float variant
in CPU to make it closer to GPU.
This is a regression in 4.1, caused by 36e603c430.
For unbiased MIS weight in light tree, we should use sd->N for
mis_origin_n, since sc->N is not available in NEE.
The change also makes it so we do not sample lights below sd->N even
when bump map correction is disabled. This diverges from the original
idea of giving full control to artists, but ensures the internal math
is happy.
Pull Request: https://projects.blender.org/blender/blender/pulls/120216
From what I can tell, this was fixed a long time ago already in 42057481fbb0c7ed3.
See the change from `(Library *)(bheadlib+1)` to `read_struct(fd, bheadlib, "Library")`.
The warning was added 5 months before that in f1a217c5f9f05045.
Pull Request: https://projects.blender.org/blender/blender/pulls/120272
This patch ports the GPU Vector Blur node to the CPU, which is in turn
ported from EEVEE. This is a breaking change since it produces different
motion blur results that are more similar to EEVEE's motion blur.
Further, the Curved, Minimum, and Maximum options were removed on the
user level since they are not used in the new implementation.
There are no significant changes to the code, except in the max velocity
computation as well as the velocity dilation passes. The GPU code uses
atomic indirection buffers, while the CPU runs single threaded for the
dilation pass, since it is a fast pass anyways. However, we impose
artificial constraints on the precision of the dilation process for
compatibility with the atomic implementation.
There are still tiny differences between CPU and GPU that I haven't been
able to solve, but I shall solve them in a later patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/120135
This reverts commit 14500953ed5a6ecbdc5842c9f86c557b1f6af5e1.
The commit has introduced multiple drawing regressions in xray mode and
was already reverted in 4.1. A different solution has to be found or
the current one should make sure these regressions are fixed.
Finding the correct solution isn't priority.
* #120208
* #119527
Pull Request: https://projects.blender.org/blender/blender/pulls/120285
The MTLWriter was using a BLI_assert to check user-provided data, which
is incorrect and would only work in Debug builds. Release builds would
end up using too small of a buffer and would needlessly fail to append
the `.mtl` extension in some cases.
Instead, we now allow the path manipulation code to just use the full
max size available to it.
Pull Request: https://projects.blender.org/blender/blender/pulls/120275
The root of the issue, as identified by Jake-Faulkner in his PR
(!120099), was that after changes in commit 195bb4f8f5,
`BKE_libblock_ensure_unique_name` would not always correctly set
`bmain->is_memfile_undo_written` to false when an ID name was actually
modified.
However, after analyzing a bit more the code in ID renaming, it appeared
that `BKE_libblock_ensure_unique_name` was not needed and only made
things more confusing. Some ID renaming code (from RNA, the Outliner,
and some do_version areas) would then do some manual ID renaming
operations and then call it, instead of simply using the existing 'all
in one' `BKE_libblock_rename` function.
This commit removes `BKE_libblock_ensure_unique_name` and all of its
usages, and simplify all code previously using it by calling
`BKE_libblock_rename` instead.
NOTE: The only non-trivial (not-so-nice) aspect of this commit is the
changes needed in the Outliner renaming code, since here the name of the
ID is directly edited, before calling the rename function, so this edit
needs to be undone to allow calling the generic ID rename API.
Pull Request: https://projects.blender.org/blender/blender/pulls/120196
While calling into scripts with an empty `Main` shouldn't be possible
under normal circumstances, I ran into this during development.
This situation is meant to print an error, add a null check so it works
as expected.
Making arguments call into Python was impractical because Python
is only initialized for ARG_PASS_FINAL.
Replace "--command" specific logic with a general method of arguments
requesting to be executed once all sub-systems have been initialized.
Without this, the `main()` function needs hard coded logic to support
any time an argument needs to use Python internally.
We call UpdateWindow very early in our window creation, before we get
an openGl surface and before our message queue is ready. This results
in WM_ACTIVATE, WM_SIZE, WM_MOVE, and WM_PAINT messages sent to us
at a time when GetMessageTime() returns zero. This makes our event
message times have a gap between the fourth and fifth messages, equal
to the time since system start. There is no downside to not calling
this at this time.
Pull Request: https://projects.blender.org/blender/blender/pulls/117965
Because normals are calcualted lazily for all cases "depends_on_normals"
except for BMesh original normals, this is mostly unnecessary. It's actually
probably not necessary at all, because in practice there is always a separate
positions array stored in `EditMeshData` during mesh edit mode modifier
evaluation, bringing us back to the lazy calculation. But anyway, removing
the usage for topology-changing modifiers and modifiers which don't
accept BMesh as input anyway simplifies things.
Pull Request: https://projects.blender.org/blender/blender/pulls/120274
This was an oversight. It was working when adding refraction
which made the check pass.
But this only allows raytracing using screen tracing with
raytraced refraction turned on.
Horizon Scan is still not compatible with transmission.
This operator also exists in legacy edit mode and allows changing
whether the curve is cyclic. If all curves are non-cyclic, the attribute
is removed because it does not contain any useful information.
Pull Request: https://projects.blender.org/blender/blender/pulls/120266
Sometime when baking during an animation blender could crash.
WM_set_locked_interface(job->wm, true) was inside the wm thread.
This caused a race condition between the check and the lock.
Pull Request: https://projects.blender.org/blender/blender/pulls/120258
This resolves#120220.
The `parent_group()` and `parent_node()` functions would be
callable on `const` instances but return a non-`const` pointer/reference.
This introduces `const` and non-`const` variants of these
methods.
Pull Request: https://projects.blender.org/blender/blender/pulls/120261
When an object uses linked mesh data and the object and the modifier
node group are made local after versioning runs for the first time,
a new modifier is added every time the file is opened. An obvious
fix is to check whether there is already a modifier with the versioning
node group. In that case we can skip the object.
This doesn't fully fix the scenario from #120030; it requires that
the node group is made local so it doesn't leave a reference to
a non-existent library data-block.
The issue from the bug report mentions that the `Limit Rotation` constraint snaps
back to 0 when reaching 180 degrees with a min and max of 0 / 180.
The root cause of this goes a bit deeper though. Because the following also snaps back to 0.
* min max of 0 / 360
* angle of 185
The reason for this is that the clamping logic in the constraint was very simple.
It just took the matrix, decomposed it to euler and clamped the values directly.
However in that process, the euler angles are bound to a range of -180 / 180,
which means that any angle >= 180 would snap back to the min.
Pull Request: https://projects.blender.org/blender/blender/pulls/118502
Tune Metal compilation parameters for horizon scan
shaders for optimal performance. Selectively unrolling
loops and modifying compilation heuristics results in a
~25% uplift in tracing shader performance, due to
improved latency management.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/119737
The GPv3 tint modifier will give incorrect result in fill tint due to
two reasons: 1) The material index being wrong; 2) The default value
for `fill_color` attribute needs to be explicitly assigned as
`ColorGeometry4f(float4(0.0f))` to ensure correct color mixing and
switching between fill/material color in the tint modifier.
Pull Request: https://projects.blender.org/blender/blender/pulls/120249
Blend files with compositor node trees saves in 4.2 do not work in older
version. This is because 4.2 removed the chunk size property of the node
tree, so it is set to zero, which is invalid in older versions. To fix
this, we add it again as a deprecated DNA member, and set it to default
value upon write.
Pull Request: https://projects.blender.org/blender/blender/pulls/120246
The File Output node always has inputs of type Color regardless of the
type of the connected socket. This is because the socket type update
mechanism no longer works, so the default socket type persisted.
This is a regression due to 4a4916db45, where the RNA set function no
longer allows editing socket types for built-in nodes, and the File
Output node utilized the RNA set function. To fix this, we avoid the RNA
route and set the type directly.
This fix is related to #120175 and partially fixes it, though another
fix is still necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/120199
The File Output node produces wrong output when the output is set to BW.
This is because the image saving logic assumes float buffers always have
4 channels and ignores the image buffer channels member. So for single
channel images, the code weighted sum neighbouring pixels and asigned
them as a single pixel, producing bleeding at best and crashes at worst.
To fix this, we skip Color to BW conversion if the image is already BW.
And, we fix the functions that assume 4 channels for float buffers.
Pull Request: https://projects.blender.org/blender/blender/pulls/120206
