This uses Spherical Harmonics to store the indirect lighting and
distant lighting visibility.
We can then reuse this information for each closure which divide
the cost of it by 2 or 3 in many cases, doing the scanning once.
The storage cost is higher than previous method, so we split the
resolution scaling to be independant of raytracing.
The spatial filtering has been split to its own pass for performance
reason. Upsampling now only uses 4 bilinearly interpolated samples
(instead of 9) using bilateral weights to avoid bleeding.
This also add a missing dot product (which soften the lighting
around corners) and fixes the blocky artifacts seen at lower
resolution.
Pull Request: https://projects.blender.org/blender/blender/pulls/118924
For historical reasons, the `multi_input_socket_index` was actually reversed
(large index comes first). This patch renames it to `multi_input_sort_id` and
adds a comment. This new name makes it less confusing that the id is reversed.
Pull Request: https://projects.blender.org/blender/blender/pulls/119652
Fix a crash when inserting a key with tweak mode enabled, but where
`AnimData::actstrip` was NULL.
The root cause of this is that two pointers in the `AnimData` struct
(`act_track` and `actstrip`) are expected to be set when NLA tweak mode
is enabled, BUT these are not exposed to RNA and thus invisible to the
library overrides system. As such, they are NULL when loading from disk,
while the `ADT_NLA_EDIT_ON` flag still indicates they are to be used.
Rather than adding a NULL pointer check (and having to add that in many
more places), I used this two-pronged approach:
- Extend the 'NLA tweakmode' override apply code, to set the `act_track`
and `actstrip` pointers when they are incorrectly NULL. This is done
by lookup of the track and strip by name.
- Add versioning code to exit out of tweak mode whenever the
`ADT_NLA_EDIT_ON` flag is set, but those two pointers are still NULL.
The last step was necessary with the example file attached to the bug
report, as that was saved with a buggy blender version. New saves work
just fine.
Pull Request: https://projects.blender.org/blender/blender/pulls/119632
Bring back the `INSERTKEY_XYZ_TO_RGB` enum item for the
`keyframe_insert()` function (it was removed in 30b0c5b225). This way
any Python code that targets Blender 4.x can safely pass this flag,
without having to check specific Blender versions.
Note that the flag is implemented as a no-op, as the behaviour change
introduced in 30b0c5b225 (just looking at the user preference) is still
retained. The purpose of this commit is simply to avoid the `ValueError`
exception that would otherwise be raised.
This should also fix Rigify report blender/blender-addons#105241.
Pull Request: https://projects.blender.org/blender/blender/pulls/119625
Experimental flag for "Extensions Development Utilities" that can be
enabled separately from "Extensions". Note this PR does not enable the
use of this flag (coming later) as uses are in addons-contrib. This
flag is requested in #119521
Pull Request: https://projects.blender.org/blender/blender/pulls/119562
This adds a "Solver" option to the geo boolean node, with the options
Exact and Float.
The current geo boolean node only uses the Exact solver.
This adds the ability to use the faster original floating point boolean solver.
The float solver has issues with coplanar and other coincident geometry,
but is generally much faster than the Exact solver, and users have asked
for this option (which is available in the Boolean Modifier and edit mode
boolean tool).
Like the modifier, the Float solver needs to convert the Mesh to BMesh,
do the operation, and then convert back to Mesh. It also has to do it
iteratively if more than two operands are supplied.
This is the first of a planned series of commits that will add a
new exact boolean solver, based on the Ember paper, as a solver option.
Ember will be much faster than the current exact solver, but may still not
be as fast as float, and also will not handle some non-volume-enclosing
inputs as well as Float, so it is likely that the Float solver will always remain.
We may eventually retire the old Exact Solver, however.
This commit also prepares for more sensible code in the future by
changing the internal enum names for the solvers to better reflect the
algorithms used: Fast -> Float, and Exact -> Mesh_Arr (which means
"Mesh Arrangments, the name of the paper upon which the current
exact solver is based).
Co-authored-by: Howard Trickey <trickey@google.com>
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/119294
This fixes an issue where the `use_masks` functions on layers
and groups returned the wrong value.
The issue was that the root group doesn't have this flag set
which then propagates to all the layers and groups.
To fix this we invert the `GP_LAYER_TREE_NODE_USE_MASKS` flag (now called `GP_LAYER_TREE_NODE_HIDE_MASKS`).
The API still uses the `use_masks` function.
Layer masks were partly already there. This PR completes the implementation and expose them through the UI.
This also adds three operators to:
- add a layer mask
- remove a layer mask
- reorder layer masks
Note: These are not used by the renderer yet. Will be done in a following PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/119433
This adds the `viewlayername` property to grease pencil v3 layers.
It's exposed as `viewlayer_render` in python.
Note: this is not used in the renderer yet. Will be used in a following PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/119422
The core of the issue was that `sculpt_flag` was used by three different enums (`eGP_Sculpt_Flag`, `eGP_Sculpt_Mode_Flag`, and `eBrushFlags`). This resulted in the flag getting overriden because `ENUM_OPERATORS` expected the maximum value of `eGP_Sculpt_Flag` to be `(1 << 3)` which it wasn't.
The `sculpt_flag` was exposed through python as `"direction"`.
In the UI this meant that it was effectively used as `brush.direction`. This fix replaces `brush.gpencil_settings.direction` with `brush.direction`.
It also makes sure `sculpt_flag` is only ever used with values from `eGP_Sculpt_Flag`.
Pull Request: https://projects.blender.org/blender/blender/pulls/119373
For various reasons, the animation system can't properly update the node tree
so that the socket availability caused by changing node enum properties
propagates completely. So animating node properties that affect
socket visibility to change isn't possible without issues like crashes.
Unfortunately that wasn't disallowed before. In this commit there is
a balance of disabling animation on sockets that could reasonably expected
to affect socket visibility, and minimizing breaking changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/119221
This fixes the following name collisions:
* Compositor Box/Ellipse Mask node: `width` -> `mask_width`
(also renamed the `height` property accordingly)
* Shader AOV Output node: `name` -> `aov_name`
* Geometry Color node: `color` -> `value`.
Those are breaking changes unfortunately, because looking up those property
names yielded the node-specific and not the common property. Therefore, this is
targeted at `main` instead of `4.1`.
Pull Request: https://projects.blender.org/blender/blender/pulls/119284
This patch implements the GPU Bloom glare for the CPU compositor, and
adds a new option for it, leaving the Fog Glow option unimplemented once
again for the GPU compositor.
Pull Request: https://projects.blender.org/blender/blender/pulls/119128
Add two snapping increment options: a regular value
(activated with Ctrl) and a precise value (activated with Ctrl+Shift).
These values are separate for 2D and 3D views.
Ref !118760
"Own" (the adjective) cannot be used on its own. It should be combined
with something like "its own", "our own", "her own", or "the object's own".
It also isn't used separately to mean something like "separate".
Also, "its own" is correct instead of "it's own" which is a misues of the verb.
Introduce new DNA for the `Animation` data-block and its sub-data.
This includes the blenkernel code for reading & writing to blend files,
and for memory management (freeing, duplicating). Minimal C++ wrappers
are included, with just the functionality needed for blenkernel to do
its job.
The Outliner code is extended so that it knows about the new data-type,
nothing more.
For more info, see issue #113594.
Pull Request: https://projects.blender.org/blender/blender/pulls/119077
When in mesh editmode, skin_vertices point to bmesh customdata, the
skin_vertices data is empty since custom data is stored per element
instead of a single array there (same es UVs etc.).
Fix similar to 3e2619b3e7, 5179b8236b (basically disallowing the
access in editmode).
Pull Request: https://projects.blender.org/blender/blender/pulls/119149
* Only works on machines with a Qualcomm Snapdragon 8cx Gen3 or above.
Older generation devices are not and will not be supported due to
some driver issues
* Requires VS2022 for building.
* Uses new MSVC preprocessor for sse2neon compatibility.
* SIMD is not enabled, waiting on conversion of blenlib to C++.
Ref #119126
Pull Request: https://projects.blender.org/blender/blender/pulls/117036
Regression in 427eed292d.
Root of the issue was that animation system was using a single same
check to decide if an F-Curve/driver was valid to use to animate some
data, and whether user can create/edit animation for that data.
Both cases are actually different, since e.g. linked data is not
user-editable, but it can still be animated (either by related linked
Actions, drivers defined in the linked data, or some more hackish
changes like py API/RNA scripting).
This commit now defines two checks:
* `RNA_property_animateable`: whether a RNA pointer & propoerty is
animateable, based on their types and definition.
* `RNA_property_anim_editable`: whether a specific data referenced by
the RNA pointer and property is effectively user-editable.
The new `driveable` check added by 427eed292d is also renamed to
`RNA_property_driver_editable` (since the basic type-based
`RNA_property_animateable` is also valid for drivers currently).
Pull Request: https://projects.blender.org/blender/blender/pulls/119089
Regression from 427eed292d, in IDProperty case the 'ensured' PropertyRNA
pointer is some sort of empty template, and cannot be used for many
things.
Instead of calling `rna_ensure_property` twice for each call to
`RNA_property_animateable`, rather add an optional parameter to static
helper `rna_property_editable_do`, and call it directly from
`RNA_property_animateable`.
Although rare (and not recommended!), it can happen that a same exact
RNA path points to a different type of data.
This can come from an update of the code itself, but this is very
unlikely and discouraged.
However, geometry nodes and their 'modifiers' interface have made it way
more easy to create such conflicting situation, since users are free to
re-arrange and edit the nodes and their 'public' interface as they
want...
Found out while investigating some unrelated issues in some studio Gold
production files (namely,
`pro/shots/090_joining_whale/090_0130/090_0130-anim.blend` r2110
exhibits such issue for `OBGEO-mika-body`
`modifiers["RIG-GN-mask-clothing"]["Socket_3"]`, where the RNA type
changes from integer to bool).