When using the MapUV node for certain NPR workflows (for example palette
based remapping of colors) it can be useful to not use the default
anisotropic filtering.
In preparation of potentially adding more filter modes at a later stage
and to keep things consistent with the 'transform' node we use the full
set of interpolation modes in the enum, but expose only the implemented
ones in RNA..
The GPU Cryptomatte node fails when the source is a multi-layer image.
This is because the check that compares the Cryptomatte Type Name with
the layer name was reversed.
The Defocus node produces an empty output when the max blur is less than
1. This patch fixes that by passing the image through in that case,
since it is identity in this case.
The Plane Deform mask output retains the original alpha of the input
image, while it should be a binary mask. This patch ignores the alpha of
the image and uses a binary mask instead.
This has been broken since 2.8.
The highlevel reason for this is that the "info file" (saved as frame
zero) was not written anymore.
Reason for that in turn is that when calling `BKE_ptcache_write` outside
the bake job, the `PTCacheID` `calldata` (a psys in our case) is not the
evaluated particle system, causing a check for `totpoint` to fail (these
were always zero).
Deeper reasoning is unclear, no further investigations were done as to
why/when this happened.
The solution proposed here is using the evaluated psys when writing the
info frame (and this is isolated to just this spot). File then gets
written and can/will be read when using this as an external disk cache
in another file.
Pull Request: https://projects.blender.org/blender/blender/pulls/117291
This was caused by the introduction of the generic `SocketValueVariant` type.
Now it's not enough to simply default-construct the value anymore, but it has
to be constructed with the correct type.
Previously, panels without headers were always skipped in the code
that opens and closes panels because they could not be closed.
Now they can contain layout panels that can be closed even if the root
panel can not be closed.
The issue was caused by light and shadow linking runtime data not
evaluated first time for lights linked to scene indirectly.
Simple solution is to hook up shading component to the instance
operation, so that visibility flag is properly propagated to the
shading component, and the light linking is evaluated.
Do it as non-flushing operation to prevent possible unwanted
re-evaluated of instancers.
Pull Request: https://projects.blender.org/blender/blender/pulls/117301
Instead of having a set of hardcoded rules in the collection and
object instance collection builder introduce new node on object's
INSTANCING component which is to be hooked up to the node which is
duplicating the object.
Should be no functional changes.
Currently there is no functional changes.
In the future it allows to more easily hook the shading component
to other nodes to ensure the visibility flow.
Note that since the operation is not used by any relation it will
appear disconnected in the graphviz debugger. This is due to the
current behavior of deg_graph_remove_unused_noops().
This allows modifiers to have cache pointers that are preserved over undo steps.
I intend to use this for the baked data cache for the geometry nodes modifier.
Pull Request: https://projects.blender.org/blender/blender/pulls/117307
The name `offset_in_ID` is very misleading since it does not have to be an offset at all,
it just has to be some unique value. Often it's also a hash or a constant value depending
on the use.
Pull Request: https://projects.blender.org/blender/blender/pulls/117306
Sometimes a frame node can't be behind another because of parenting.
Comparing the two nodes with `compare_node_depth` would give that
result too, but sometimes every combination of frame node isn't tested.
In that case, the existing values of `ui_order` matter, and we should start
the sort there. So first sort based on the existing order, then do a stable
sort to fulfill the constrains coming from selection and parenting.
Caused by 29f3af9527, exposed by bff51ae66c.
The problem was that a `uiBut` pointer was being passed to a function
and then dereferenced as a `PanelType`. In the past, the button used to
just have zeros where the pointer was then read from, but after the
changes in the second commit, this was no longer the case.
Fix by being more explicit about the argument type, and changing the
argument from a button to the panel type for one callback. It's a bit
complex because the panel type and panel type idname are stored in
different places depending on the button type.
Mesh shape key data elements are always of the `ShapeKeyPoint` type and
only have a `.co` property which is stored contiguously. However, the
`.data` collection property's elements are dynamically typed because
Legacy Curve shape key data elements use a mix of `ShapeKeyCurvePoint`
and `ShapeKeyBezierPoint` elements. The necessary support for handling
the dynamic/mixed typing of the shape key data elements disables raw
access to the collection and its elements which makes `foreach_get`/
`foreach_set` slower.
`ShapeKey.points` is a new collection property whose element type is
fixed as `ShapeKeyPoint` and uses the `#rna_iterator_array_next` and
`#rna_iterator_array_get` collection functions which enable raw access
to the collection.
To complete the raw access to Mesh shape key data, the `.co` property of
`ShapeKeyPoint` also needs raw access. To accomplish this, the RNA
definition for `ShapeKeyPoint` now uses the `#vec3f` DNA struct and its
`.co` property is set to start from the `x` field of the `#vec3f` DNA
struct.
Lattice shape keys also use `ShapeKeyPoint` and also benefit from using
`.points` instead of `.data`, though Lattice objects typically have far
fewer data, such that performance is of minimal concern.
On shape keys belonging to Legacy Curves (`bpy.types.Curve`/
`bpy.types.SurfaceCurve`), `.points` will simply always be empty because
they do not have `ShapeKeyPoint` elements.
---
**Performance**
The increase in performance is specifically for foreach_get/foreach_set,
there is no noticeable performance difference to iterating through or
accessing individual elements of `.points` directly through Python, e.g.
`.points[0].co` vs `.data[0].co`.
`foreach_get` with a Python list is about 2.8 times faster.
`foreach_get` with an incompatible buffer (NumPy ndarray with np.double
dtype) is about 1.4 times faster.
`foreach_get` with a compatible buffer now scales better with larger
collections, so it is about 11.7 times faster at 100 elements and about
200.0 times faster at 100000 elements, dropping off to about 65 times faster for much larger collections.
The increase in `foreach_set` performance is slightly better than in
each `foreach_get` case, but scales the same overall.
`foreach_set` with a Python list is about 3.8 times faster.
`foreach_set` with an incompatible buffer (NumPy ndarray with np.double
dtype) is about 1.45 times faster.
`foreach_set` with a compatible buffer now scales better with larger
collections, so it is about 13.4 times faster at 100 elements and about
220.0 times faster at 100000 elements, dropping off to about 70 times faster for much larger collections.
The performance drop-off might be to do with hardware/OS specifics of `memcpy`. The drop-off occurs for me on Windows 10 with my AMD Ryzen 7 3800X at just above 1.5MiB of data copied (1572888B copied -> 200x faster, 1572900B copied -> 75x faster).
Pull Request: https://projects.blender.org/blender/blender/pulls/116637
No functional changes.
In #116823 the function `remap_driver_frame` was moved,
but the name doesn't exactly correspond to what the function is doing.
Since it evaluates the driver, with different parameters, it is now called
`evaluate_driver_from_rna_pointer`.
We could maybe remove the function because it is only called once.
Pull Request: https://projects.blender.org/blender/blender/pulls/117294
Exceptions:
* Links to personal wiki pages
* Pages that are not in the new developer docs yet (like Human Interface Guidelines)
* tools\check_wiki\check_wiki_file_structure.py needs a refactor
No functional changes expected.
Before this PR the keyframing code was aware of driver specifics
and changed the frame where a key is inserted to the current driver value.
This is now changed so that the calling code needs to know where on the
FCurve the key should be inserted. This removes the need for the
`INSERTKEY_DRIVER` flag.
Pull Request: https://projects.blender.org/blender/blender/pulls/116823
The GPU Directional Blur node distorts the inputs if the resolution is
not square. This is because rotation is performed on normalized
coordinates. This patch performs the normalization at the texture
evaluation.
When there is no default color attribute yet, when creating a new color
attribute with the store named attribute node, set the default. Though
we generally try to avoid this more magical behavior, there's little
downside in this case, and it's probably what users expect.
Don't set the active attribute though, since that's UI data that generally
shouldn't be changed procedurally. It's okay if there's no active color
attribute.
Pull Request: https://projects.blender.org/blender/blender/pulls/117249
It is very common for graphical editors with layers to support
locking individual layers to protect them from accidental edits due
to misclicks. Blender itself already supports locking vertex groups.
This adds lock toggles for shape keys, with lock/unlock all operators.
The flags are checked by sculpt brushes, edit mode transform tools,
and Smooth, Propagate and Blend From Shape operators. This selection
aims to cover operations that only deform the mesh, where the shape
key selection matters.
Topology changing operations always apply to all keys, and thus
incorrect shape key selection is less impactful. Excluding them
from the new feature greatly reduces the patch size.
Pull Request: https://projects.blender.org/blender/blender/pulls/104463
