This new version brings several fixes that Blender no
longer needs to patch manually. In addition, it includes
an internal change related to GPU memory management which,
together with the new API, could address several tickets
and issues currently reported in relation to Embree GPU execution.
Pull Request: https://projects.blender.org/blender/blender/pulls/138176
Embree 4.4 introduces an improvement in the Embree GPU
implementation by dropping shared memory usage in favor
of direct controllable memory transfers. This should allow
addressing several problems spotted in Blender regarding
multithreading and memory corruption when BVH and rendering
happen at the same time. However, to implement such
improvements, the API has changed for several functions, and
this commit adopts Blender code to these changes, making Blender
buildable and functional with all existing Embree 4.X
versions, before and after 4.4.
No functional changes in Blender behavior are expected if
using Embree versions below 4.4.
Pull Request: https://projects.blender.org/blender/blender/pulls/139061
In Cycles, the convention is that reflection vs. refraction are classified
based on the hemisphere defined by the *shading* normal (N).
In general, most closure code uses the shading normal for most operations,
as is expected since using the geometric normal (Ng) would break normal maps
and smooth shading.
However, there are two places that use Ng: On the one hand, BSDF sampling
functions generally reject reflections that fall below the Ng hemisphere, since
they'd intersect the geometry when tracing the bounce. This is required, and
we can't do much about it.
On the other hand, the Microfacet evaluation code also checked that the ray
is in the same hemisphere w.r.t. both shading and geometric normal.
Theoretically, this is the right thing to do, since sampling and evaluation code
are supposed to be consistent. However, doing so breaks smooth shading, since
now direct light evaluation near the terminator will sometimes be rejected.
This didn't cause problems in practice because of another inconsistency: While
the parameter of the eval functions was named Ng, the caller actually provided
N (unclear whether by mistake or as a hacky workaround to the terminator).
When this was fixed in 063a9e89, users quickly reported issues with the shadow
terminator, so it was reverted to the hacky inconsistency in 1c50dd8b.
So, let's clean this mess up properly. If we don't want to do the Ng hemisphere
check in _eval, then instead of passing in a misleading value that ends up
making it a no-op, just remove the check. After all, the other closures don't
perform it either.
This way, we avoid the mislabeled Ng, we get rid of the special case for
microfacets, and the shadow terminator continues to be fine.
Technically, we still have the _sample vs. _eval mismatch. However, this is just
unavoidable, and is irrelevant in practice: For a strongly directional light
that makes the shadow terminator noticeable, the MIS weights will be massively
in favor of eval, to the point that it doesn't really matter what sample does.
To support this argument: You can actually reproduce a broken shadow terminator
in pretty much every Cycles version going back to 2011 by just setting up a
small intense mesh emitter, turning off MIS on it to disable _eval, and then
rendering a diffuse smooth-shaded sphere with >100000 samples so that the
fireflies resolve into somewhat consistent lighting.
If nobody has complained about this affecting all closures for 11 years,
I guess it's fine.
Pull Request: https://projects.blender.org/blender/blender/pulls/138632
Split out from #138161.
I checked with a locally built OSL (on Linux), and all tests (incl. OptiX OSL)
still pass without the Cycles-side changes in that PR, so we can merge this and
update the libs separately.
The only file that needs to be updated in the deps is `liboslexec.so`,
and probably `llvm/lib/clang/17/include/__clang_cuda_device_functions.h`
(we don't use this when building Blender, but since it's changed,
it's probably cleaner to update it anyways).
Pull Request: https://projects.blender.org/blender/blender/pulls/138788
Currently, there are some constraints on the interface of node groups:
* Sockets have to be above panels.
* Outputs have to be above inputs.
The current code that ensures these constraints wasn't able to handle the
case when there are more interface items without the same constraints.
This patch is extracted from #138747.
... for Grease Pencil & Curves
Was only moving the points relative to the origin (so only they stayed
in place, handles were still transformed along with the origin).
In order to fix this this, we now take into account curves handles in
the whole `XFormObjectData` related code (for both Grease Pencil &
Curves). There was a handly existing pair of functions
[`curves::bezier::retrieve_all_positions` &
`curves::bezier::write_all_positions`] which we can use for Curves, for
Grease Pencil this uses code from those functions (but not the functions
directly -- indices would fail there because Grease Pencil would call
this from multiple layers).
This also introduces `BKE_grease_pencil_has_curve_with_type` so we can
know in advance how many elements we need for the
`XFormObjectData_GreasePencil`.
Also corrects a typo in c1c67c918e (swapping `XFormObjectData_Curves`
with `XFormObjectData_GreasePencil`)
Pull Request: https://projects.blender.org/blender/blender/pulls/138665
- User visible rename: "Use Armature Setting" -> "Armature Defined"
(just added in 8bf73386f2)
- Internal code only: rename eArmature_Drawtype enum items to have
ARM_DRAW_TYPE_ prefix, instead of just ARM_ (just ARM_ is used in
several unrelated enums, leading to confusion)
This is re-apply of PR !138982 was backed out in cef7cb4534 due to
Win x64 buildbot failure. The error was:
```
view3d_navigate_view_all.cc(321): error C2672: 'blender::bounds::transform_bounds': no matching overloaded function found
view3d_navigate_view_all.cc(322): error C2784: 'blender::Bounds<blender::VecBase<T,3>> blender::bounds::transform_bounds(const blender::MatBase<T,Size,Size,NumCol*NumRow%4==0?4:1*sizeof(T)> &,const blender::Bounds<blender::VecBase<T,3>> &)': could not deduce template argument for 'const blender::MatBase<T,Size,Size,NumCol*NumRow%4==0?4:1*sizeof(T)> &' from 'const blender::float4x4'
```
which has nothing whatsoever to do with the PR. But something
in the PR (i.e. rename of a completely unrelated enum entries)
presumably makes this specific VS2019 compiler version not be
able to resolve template argument type. Again, in completely
unrelated file with completely unrelated types.
So "the fix" is to help VS2019 compiler in that place by explicitly
specifying the template types. What exactly in the original
change triggers the issue, remains a mystery. "It is known" that
VS2019 is quite funky in template argument deduction, maybe this
is one of these cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/138995
This commit adds a toggle functionality to the `brush.asset_activate`
operator that makes it behave similarly to the `paint.brush_select`
parameter of the same name.
When the operator has this option enabled, using the operator or
pressing the relevant key will either:
* Activate the specified brush and store it if the current brush does
not match the specified brush
* Activate the previously stored brush if it exists.
This option is exposed in the keymaps and enabled by default for the
Sculpt Mask brush.
This allows, for example, users to press 'M' to switch to the mask brush
and then press 'M' again to switch back to their previously active
brush.
Partially addresses this RCS submission: [1]
[1] https://blender.community/c/rightclickselect/1VwZ/
---
### Notes
This commit does not currently clear the `AssetWeakReference` when switching paint modes.
Pull Request: https://projects.blender.org/blender/blender/pulls/138845
Neither value was being cleared when the active vert was cleared,
leading to an invalid state where we could have no active vertex but an
active face or grid index.
Pull Request: https://projects.blender.org/blender/blender/pulls/138963
File under #138795 showed several issues, which, while investigating
them, led to also fixing some other issues.
- FBX files can contain non-bone nodes in between actual bone nodes
("fake bones" as they used to be called in Python importer). Handling
this case was missing in the new importer.
- Due to above, some armatures had what appeared like multiple
"root bones" inside them, which led to crashes while importing
animations.
- Meshes with multiple armature modifiers (multiple skin deformers
in FBX) were not handled correctly, see
https://projects.blender.org/blender/blender-addons/issues/45171
for when the same issue was fixed in the Python importer.
Extended test coverage to encompass the above.
Pull Request: https://projects.blender.org/blender/blender/pulls/138992
Similar to b51229f5fd.
The asset editing API would allow deleting any .blend file that was
linked via the same API, even if it was not created & managed by the API
itself but by the user.
All users of the API had sufficient other checks, so in practice it
wouldn't happen. Still make sure the API is safe to use without
requiring the caller to perform extra checks.
The asset editing API wouldn't check if the file it's writing to is
known to be managed by the asset editing API itself, and therefore
writable by the API. So the API could potentially lead to custom blend
files getting overridden.
To be clear, all users of the API had sufficient other checks, so in
practice it wouldn't happen. Still make sure the API is safe to use
without requiring the caller performing extra checks.
Gizmos that contain 3D wire parts, like the rounded lines of the
"Rotate" gizmo, have a fairly small hit size that make it hard to grab,
especially with tablet pens. This PR just increases the width of these
lines during the (invisible) selection process. This is done in such ability
way that it could be increased in the future for touch if needed.
Pull Request: https://projects.blender.org/blender/blender/pulls/138406
Currently, `columnselect_action_keys` gets "raw" non-NLA-mapped keyframe
data via `ANIM_fcurve_keyframes_loop` with the `bezt_to_cfraelem` callback,
so the list of `CfraElem` contains frames in "local" FCurve space.
Later, this would be (rightfully) NLA-unmapped to "local/strip" time, because
this is what `ANIM_editkeyframes_ok(BEZT_OK_FRAME)` expects, it also only
compares "raw" `BezTriple` data.
But this only makes sense if we would store "global/scene" frame data in
`CfraElem` `cfra` already.
This is what we now do, let `bezt_to_cfraelem` perform the NLATIME_CONVERT_MAP
Pull Request: https://projects.blender.org/blender/blender/pulls/138937
invert button doesn't work quite well when `filter_items()` is used in
UIList (eg. workspace, attributes list). First issue is, when search
string is empty and invert button is pressed, none item is shown. Now
fixed with extra condition of `filter_byname[0]`. Another issue is when
search string is non-empty then invert button should show elements that
doens't match with the string but it doesn't work. This occurs due to
filtering elements twice. First inside
`filter_items_by_name(reverse=true)` then `UI_list_item_index_is_filtered_visible`.
Remove `UILST_FLT_EXCLUDE` so only once the items are filtered with
invert condition.
Noticed this during !138756
Pull Request: https://projects.blender.org/blender/blender/pulls/138761
Add new rna property that sets `UILST_FLT_ITEM_NEVER_SHOW` Flag for
internal attributes. This avoids internal attributes from showing in the
list with invert button is enabled, see: `UI_list_item_index_is_filtered_visible`
Pull Request: https://projects.blender.org/blender/blender/pulls/138756
Reworks the implementation for how knots are interpreted when importing
NURBS in .obj format. It refactors each test into a separate function
and simplifies functions using a 'multiplicity sequence' which counts
repeated occurances of knot values (or their 'multiplicity'). Making
comparisons simpler, clearer, and with improved correctness.
With regard to regression tests behavior is almost the same, noticable
difference is consideration of cyclic. Allowing curves with multiplicity
at the endpoints to be cyclic (so Bezier curves can be cyclic given
one repeated point). Untested behavior may also have been 'refined'
(changed), but additional tests would be needed to identify those cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/138778
Currently the depsgraph is re-evaluated between every parent operation
when parenting multiple objects. This patch evaluates it only once and
does all the parenting after.
Since it is most of the work, this makes a big difference in large-ish
files. For example, re-parenting 400 objects in a 4000 object file goes
from 10 seconds to a few tens of milliseconds.
I'm definitely not familiar enough with blender internals and all possible
situations to know if this is actually safe or not.
Pull Request: https://projects.blender.org/blender/blender/pulls/138616
- User visible rename: "Use Armature Setting" -> "Armature Defined"
(just added in 8bf73386f2)
- Internal code only: rename eArmature_Drawtype enum items to have
ARM_DRAW_TYPE_ prefix, instead of just ARM_ (just ARM_ is used in
several unrelated enums, leading to confusion)
Pull Request: https://projects.blender.org/blender/blender/pulls/138982
Refactor `Action::slot_remove`: implemented iteration over
`strip_keyframe_data_array` and direct calling
`StripKeyFrameData::slot_data_remove()`. Also removed
`Strip::slot_data_remove()` as well as `Layer::slot_data_remove` as it
had no usages after refactoring.
Fixes: #137095
Pull Request: https://projects.blender.org/blender/blender/pulls/138343
Always show the 'Available' option in the keyframe menu, so that the
shown menu items are stable. This helps to keep hotkey assignments for
the menu items remain the same.
Note that this isn't a full guarantee yet, as the 'Active Keying Set'
option is also still conditionally added, depending on whether a
keying set was chosen or not. This will be addressed in another
commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/136952
Armature bone display mode (Octahedral, Stick, Envelope, B-Bone,
Wire) could only be set on the whole armature. This adds ability to
override the display mode per-bone (by default bones use the
same display mode as the armature).
Images in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/138445
Use the horizontal scroll wheel for panning left/right in the
3D Viewport. Similar to how it is used in 2D Views.
Also add it to the industry compatible keymap, since it is
a pretty standard/basic navigation gesture.
Pull Request: https://projects.blender.org/blender/blender/pulls/138880
No functional changes intended.
This moves the functions
* ANIM_bone_is_visible
* ANIM_bone_is_visible_ebone
* ANIM_bone_is_visible_pchan
into new files `ANIM_armature.hh`/`armature.cc`.
They were previously in `ANIM_bone_collections.hh` but don't
directly have anything to do with bone collections.
It also puts the functions into the `blender::animrig::` namespace
and removes the `ANIM_` prefix as is the standard for C++ files.
Part of #138482
Pull Request: https://projects.blender.org/blender/blender/pulls/138833
