The USD importer was still creating legacy Actions, which are no longer
supported in Blender 4.4. This commit updates the code to produce
slotted Actions instead.
This also avoids the need to create F-Curves "from scratch", but rather
uses the available functionality. This makes the code somewhat easier to
maintain.
Pull Request: https://projects.blender.org/blender/blender/pulls/134866
Blender crashes when using the Denoise node. That's because the code
assumes normal input would have 4-channels, while this may not be the
case. To fix this, use the channels count from the result or the GPU
texture directly.
When source reference image is a single image type, selecting "sequence"
mode for tracing image into grease pencil will result in a crash in
`trace_end_job` because it's trying to finalize more frames than traced,
now ensures tracing mode to be `Single` when reference image is single
image type even when tracing mode selector is set to sequence.
Pull Request: https://projects.blender.org/blender/blender/pulls/134981
Layer had their opacity reset whenever a modifier was applied.
This was due to the property not being transferred when a new GreasePencil
object was created in `geometry::merge_layers` function. This PR makes sure
to transfer the Layer opacity (similar to other layer properties).
Pull Request: https://projects.blender.org/blender/blender/pulls/135006
This was caused by 91de4a50ab refactor which replaced
the evaluator cache singleton by local variable.
It was unknown that the evaluators in the cache
are actually referenced by the modifier data.
To fix this and fix the thread-unsafety of the global
variable, a mutex is introced around a reduced critical
section inside `draw_subdiv_create_requested_buffers`.
The global evaluator cache is now also refcounted to allow
freeing of the cache when no evaluator is referenced
anymore.
Pull Request: https://projects.blender.org/blender/blender/pulls/134926
This was partially fixed in ef844bad but left some unhandled corner cases with
uninitialized memory.
The core problem is that the `dst_curve_mask` used by the interpolation
functions can contain indices that don't actually exist in either the "from" or
"to" source drawings. Specifically when the "from" drawing has more curves, the
indices are still used but the supplemental `to_curve_indices` array contains
`-1` entries, indicating that only the "from" curve should be used.
The main copy code for positions takes this into account, but the generic copy
of attributes below that does not! It passes the `dst_curve_mask` straight into
the `array_utils` functions and that causes crashes. The original fix in
ef844bad was to clamp the size of the index mask, but the way this was done
could lead to empty index masks, leaving attribute values uninitialized.
The correct solution is to use index masks that exclude invalid entries for the
respective source curves. The new masks are non-overlapping, so the full set of
destination curves can be filled by combining these masks.
Pull Request: https://projects.blender.org/blender/blender/pulls/134865
Some passes are now interpreted as vectors by the compositor Image node.
This is because it assumes 3-channel passes are always vector, but this
is not the case for passes that are RGB without an alpha channel. To fix
this, we also consider channel IDs to disambiguate the type of the pass.
Was reported for alt-editing, thats the same code though.
Previously ( da1038c768 ), the check for "matching" nodes was based on
the `legacy_type`.
This does not uniquely identify a node type, only the `idname` does.
By "matching", I mean having the same properties (so later setting
values can happen on all selected nodes).
If we allow "non-matching" nodes into our list in
`UI_context_copy_to_selected_list`, setting values on non-existent
properties later can act up (throwing `AttributeError` , also
`RNA_property_boolean_set` would actually try to create an equally named
IDP).
Better to exclude these as soon as possible, now remove nodes from
"selected_nodes" based on the `idname` (rather than `legacy_type`), this
way we can be sure properties match.
Pull Request: https://projects.blender.org/blender/blender/pulls/134930
with #133413 the intent was that VSE Text strips would not use the
fallback font stack if using a custom (non-default) font. However this
determination was done by comparing the font id. This was very weak as
the id can vary quite a bit within the first few fonts. This PR instead
adds a BLF function (BLF_is_builtin) that uses BLF_DEFAULT font flag
instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/135014
Text characters in the CO Controls range, 0-31, are not meant to have
any displayable representation. For most Blender code this hasn't
mattered since we usually specifically exclude this range in text
processing. But for times when we don't we need to avoid rendering
glyphs in this range as some fonts contain blank (but not empty) items
here.
Pull Request: https://projects.blender.org/blender/blender/pulls/135013
Technically a regression in [0] since switching the pivot between
the "Median Point" and "Active Element" would previously use the
same orientation with a single face selected.
However the same issue existed when multiple faces were selected so
changing the pivot type can still change the orientation in some
situations.
Restore the previous behavior by removing logic to pick the "best"
tangent when a single face is selected.
[0]: c7104f5392
There was no convenient way for an add-on to show it's "user"
key-map items in the preferences, "user" meaning the key-map
item which is edited in the key-map editor, not the original
key-map item created in `wm.keyconfigs.addon`.
Add a method to key-maps to lookup a user key-map item from an
add-on key-map & key-map-item.
Ref !134830
Add a convenience function to find the matching key-map
from another key-configuration.
This is a more convenient alternative to expanding the
ID, space_id & region_id from the key-map, then passing these
to the "find(...)" method.
Split out of !134830.
Crash in above operation when no drawing exists at current frame. This
is due to accessing value from a nullopt optional. Not fixed with extra
condition before calling `value()`. Also moved this logic into a lambda to
avoid duplicate code.
Pull Request: https://projects.blender.org/blender/blender/pulls/134910
Mistake in a0e6e16da5
Testing of the previous commit was inadequate, it works when a brush
tool is selected and invoked via the operator search, as the
`active_vert` property will be set by the raycast. When the Mask by
Color tool is actually active, the brush cursor, and thus the function
that performs a racyast is inactive, preventing the operator from
running.
Pull Request: https://projects.blender.org/blender/blender/pulls/134960
This PR adds support for 2 additional USD Prim Shape Schemas :
* Cylinder_1
* Capsule_1
Additional tests will be added afterwards but a simple test is simply to
import the resulting file:
```python
from pxr import Usd, UsdGeom
stage = Usd.Stage.CreateNew('shapes.usda')
UsdGeom.Xform.Define(stage, '/world')
UsdGeom.Cylinder_1.Define(stage, '/world/cylinder_1')
UsdGeom.Capsule_1.Define(stage, '/world/capsule_1')
stage.GetRootLayer().Save()
```
Linked issue : https://projects.blender.org/blender/blender/issues/134138
Co-authored-by: Nig3l <nig3lpro@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/134944
USD identifiers cannot start with a digit and, like all unsupported
characters, they will be turned into an `_`. This is a bit unfortunate
since object names like "1" or "2" both become "_" in the output file.
This not only generates a naming collision, which is not currently
handled, but it needlessly loses information even when there is no
collision.
Treat leading digits separately and turn names like "1" and "2" into
"_1" and "_2" respectively. This will allow us to eventually enable the
`light_tree_node_subtended_angle` render test which uses such names for
the lights. Another recent test required investigation and then rework
due to the same problem.
Pull Request: https://projects.blender.org/blender/blender/pulls/134595
* Slightly changes naming to be more explicit in some places
* Updates comments
* Adds const where possible
* Reduces scope of variables
* Uses references where possible
Pull Request: https://projects.blender.org/blender/blender/pulls/134891
This shared state between original data and depsgraphs was added in
98a0bcd425. Other physics systems also share
the pointcache, but not the simulation state to this extent, which leads
to this kind of crash.
The mutex lock is not a great solution, you don't really want both render and viewport to be filling the same cache in parallel. However
this kind of problem also exists in other physics systems, and solving
that is certainly beyond the scope of 4.4, and probably needs to wait
for a bigger physics rewrite. In general the recommendation is to bake
everything before rendering.
Pull Request: https://projects.blender.org/blender/blender/pulls/134779
The issue was that in the macro used, the wrong ID was passed into
the rename function. Since nodetrees are a separate embedded ID,
the rename function couldn't resolve the RNA path and thus failed.
This broke keys and drivers when renaming nodes.
Not only for the compositor, but all node trees.
This was caused by 1c7c1829b6
Pull Request: https://projects.blender.org/blender/blender/pulls/134936
The previous fix 8f00f068ad
doesn't work as the printf buffer gets recreated.
Ensure render boundaries at lower level and do the printf
flush manually.
Subdivision shaders currently fail to compile using Metal as it doesn't recognize
packed_float3 as an internal data type. This PR includes packed_float3 as an
internal data type.
Without this `blender --debug-gpu-compile-shaders` will fail as it includes a namespace.
```
ERROR (gpu.shader): subdiv_normals_accumulate Compute Shader:
|
| source/blender/gpu/metal/mtl_shader_generator.mm:971:9: Error: no type named 'packed_float3' in 'MTLShaderComputeImpl'; did you mean simply 'packed_float3'?
|
| device MTLShaderComputeImpl::packed_float3* normals[[buffer(MTL_storage_buffer_base_index+4)]],
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| packed_float3
|
| /System/Library/PrivateFrameworks/GPUCompiler.framework/Versions/32023/Libraries/lib/clang/32023.196/include/metal/metal_packed_vector:145:58: Note: 'packed_float3' declared here
|
| typedef __attribute__((__packed_vector_type__(3))) float packed_float3;
| ^
```
Pull Request: https://projects.blender.org/blender/blender/pulls/134925
This adds three new functions to find the first 0 or 1 bit in an arbitrarily
long bit span:
```cpp
blender::bits::find_first_0_index(BitSpan) -> std::optional<int64_t>
blender::bits::find_first_1_index(BitSpan) -> std::optional<int64_t>
blender::bits::find_first_1_index_expr(Expr, BitSpans...) -> std::optional<int64_t>
```
The two first ones are implemented in terms of the third. The `*_expr` variant
allows e.g. finding the first set bit when ORing two bit spans together without
computing the entire intermediate result first. Or it can be used to find the
first index where two bit spans are different.
Pull Request: https://projects.blender.org/blender/blender/pulls/134923
