Resolves the following error when compiling with Apple Clang:
```
lambda capture 'thickness_adjustement_factor' is not required to be captured for this use [-Wunused-lambda-capture]
```
Pull Request: https://projects.blender.org/blender/blender/pulls/121012
Currently for node tools we create and evaluate a temporary depsgraph
with all the selected object data-blocks and all data-blocks referenced
by the node tree.
Needless to say, this can be very slow when those data-blocks contain
arbitrary procedural operations. Re-evaluating all the selected objects
is particularly because it will give a slowdown even in very basic uses
of node tools.
Originally I hoped that geometry nodes could be made to work with
original as well as evaluated data-blocks. But that would require far
too many tricky changes and arguably isn't right design-wise anyway.
Instead of that, this commit makes node tools dependency graph
evaluation more fine-grained in a few ways.
1. Remove the evaluation of selected objects. These are always visible
in the viewport and part of the active depsgraph anyway. To protect
against cyclic dependencies, we now compare `orig_id` instead of the
object pointer itself.
2. Evaluate the node group and its dependencies in a separate depsgraph
used only when necessary. This allows using the original node tree
without any copies when it doesn't reference any data-blocks.
3. Evaluate IDs from node group inputs (from the redo panel) in the extra
depsgraph as well, only when necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/120723
This introduces fragment clipping for the shadow pipeline.
The fragments are culled using a sphere distance test
for sphere lights, which is then re-purposed as a simple
distance test for area lights.
However, in the case of area lights, this introduces some
light bleeding. To mitigate this, we bring the shadow origin
back towards the light center so that this artifact only
appears if using larger shadow tracing.
Fixes#119334
Pull Request: https://projects.blender.org/blender/blender/pulls/120992
This makes the read and write API functions match more closely, and adds
asserts to check that the data size is as expected.
There are still a few places remaining that use BLO_read_data_address
and similar generic functions, these should eventually be replaced as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/120994
Support for building blender with clang on windows on x64 was added
years ago but given there are no active users support has crumbled a
bit.
This PR brings the build system back into working order but upstream
patches in openVDB are still required for a successful build see PR
#120317 for details.
Blender when build with clang the classroom scenes rendered on the cpu
with cycles is seeing a 5% reduction in render time on both an
AMD 7700x and an Intel 14900k.
With the matrix socket being introduced into geometry nodes, we
are starting to deal with more complex transforms like perspective
projection. For those matrices projecting a point is not as simple
as just matrix multiplication, there has to be an additional normalization
step after. To solve that in an intuitive way consistent with how it's
typically solved in code, add a new "Project Point" node.
The canonical use case for now is in combination with the mouse
position, viewport transform, and raycast nodes, to find where the
mouse clicked on the edited geometry.
Pull Request: https://projects.blender.org/blender/blender/pulls/120597
Grease pencil runtime data stores the "current" frame in the
`eval_frame` property. This is updated before modifier evaluation, but
also used after modifiers, e.g. by the spreadsheet.
If the GeometrySet that is returned by the nodes modifier is created
during the nodes evaluation (as is the case with the Delete node) then
the resulting geometry set has `eval_frame == 0`. To fix this the
`eval_frame` is now also update _after_ modifier evaluation.
This will only set the correct `eval_frame` for the __top level__
geometry set. Other GeometrySets like instances may not have the correct
frame value. This is a more general problem with the design that is out
of scope here.
Pull Request: https://projects.blender.org/blender/blender/pulls/121022
The Separate operator uses the ubiquitous `gather_attributes` function
to fill in attributes of layers. However, it only makes sure the layer
exists _after_ calling `gather_attributes`, which crashes if the layer
does not already exist.
Pull Request: https://projects.blender.org/blender/blender/pulls/121013
Remove another use of the `BKE_pbvh_vertex_iter_begin` macro
and significantly simplify hot loops used when cancelling a brush
stroke or calculating an anchored stroke.
Avoid mixing different abstraction levels, remove the conversion
of the brush tool into `undo::Type`. Make it simpler to specialize
the implementation further for separate PBVH types later.
Also fix race condition retrieving write access to an attribute from
multiple threads at the same time, and reduce per-PBVH-node
overhead.
Design updates as per #118288:
- Tweak text labels (colors, drop shadows)
- Strip border colors, inset outlines
- Muted strips are mostly gray, and their thumbnails are faded
- Overlapping strips are not semitransparent anymore
- Locked stripes only in content area
- Missing data blocks
- Updates to meta strips w/ missing data blocks
Pull Request: https://projects.blender.org/blender/blender/pulls/118581
There are two ways the first stroke point is moved after initial
placement:
- The `process_extension_sample` overwrites the initial values of the
sample point after `process_start_sample`. It copies the _new_ sample
position, until a threshold (3 pixels) is reached and the 2nd point
is created, and the 1st point remains stationary.
- After initial placement the point may still get shifted due to the
resampling and interpolation used. Long sections between stroke
samples may get subdivided and the positions of the two samples are
linearly interpolated. However, the interpolation starts at 1/n,
meaning the first interpolated point never matches the first sample.
This is correct for later samples where the last point should not be
repeated, but it ends up moving the first curve point again when the
2nd sample is processed.
This patch fixes both issues by keeping the first generated point
stationary and never touching its position again.
Pull Request: https://projects.blender.org/blender/blender/pulls/121011
The usage for `points_in_planes` might require different epsilons set
for parallel/intersection determination. This adds those epsilon values
to the bpy function so it benefits script users.
Pull Request: https://projects.blender.org/blender/blender/pulls/120910
Both flags shared the same value, causing repeating a transform action
always recalculate the orientation matrix instead of using the value
from the initial execution. This is most noticeable when repeating a
transform that used a view matrix, where orbiting the view doesn't
use the view orientation from the original transform.
Cleans up the following issues:
- USD arrays were passed by value instead of references
- UsdGeomBasisCurves and UsdGeomNurbsCurves were potentially sliced when
assigning to their parent UsdGeomCurves object in a non-polymorphic way
- Make more parameters and functions const
- Align with how Alembic validates the curve_types and cyclic values
- Standarize CurvesGeometry naming like what was done in 5ed9c8c9dd
(Curves data-block is called "curve_id", CurvesGeometry is called
"curves")
Pull Request: https://projects.blender.org/blender/blender/pulls/120760
This was due to using a different normal than the deferred
pipeline for light facing attenuation.
Use the same heuristic as the deferred pipeline for
consistency and smoother look.
Fix#119750
During Export, we were accidentally duplicating the `velocity` attribute
data. Once inside the `write_surface_velocity` function (which was
correct) and again while writing out all "custom" attributes inside
`write_custom_data` (which was incorrect). Fixed by excluding the
"velocity" attribute inside `write_custom_data`.
During Import, we were only loading back in those "custom" primvars so
things happened to work, by accident, but only for USD files produced by
Blender. Now we import just the Velocities attribute which should work
with all files.
This should fully address #96182
Pull Request: https://projects.blender.org/blender/blender/pulls/120771
The normalization factor can divide by zero. Add a small
bias to avoid this. Since the bias is the same on both
the numerator and the denominator, the result converges
to 1 as the denominator reaches zero.
This also adds a `saturate` to avoid lighting being
weirdly increase in some part of the volume probe.
Fix#119799
