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
Adding support for converting between Blender custom properties and
USD user-defined custom attributes. Custom attributes on Xforms, many
data types, and materials are all supported for round-tripping.
Please see the USD attributes documentation for more information on
custom attributes.
Properties are exported with a userProperties: namespace for simple
filtering in external apps. This namespace is stripped on import,
but other namespace are allowed to persist.
An "Import Attributes" parameter has been added with options "None" (do
not import attributes), "User" (import attributes in the 'userProperties'
namespace only), "All custom" (import all USD custom attributes, the
default).
An "Export Custom Properties" export option has been added.
The property conversion code handles float, double, string and bool
types, as well as tuples of size 2, 3 and 4. Note that USD quaternions
and arrays of arbitrary length are not yet supported.
There is currently no attempt to set the Blender property subtype based
on the USD type "role" (e.g., specifying Color or XYZ vector subtypes).
This can be addressed in future work.
In addition to exporting custom properties, the original Blender object
and data names are now saved as USD custom string attributes
"userProperties:blender:object_name" and "userProperties:blender:data_name",
respectively, on the corresponding USD prims. This feature is enabled
with the "Author Blender Name" export option.
If a Blender custom string property is named "displayName", it's handled
in a special way on export in that its value is used to set the USD
prim's "displayName" metadata.
Co-authored-by: kiki <charles@skeletalstudios.com>
Co-authored-by: Michael Kowalski <makowalski@nvidia.com>
Co-authored-by: Charles Wardlaw <kattkieru@users.noreply.github.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/118938
This PR implements the viewport overlay for Weight Paint mode in GPv3.
In Weight Paint mode the stroke points are colored depending on their
weights in the active vertex group.
Pull Request: https://projects.blender.org/blender/blender/pulls/118273
