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
The function for retrieving a shape key by its index is named
somewhat confusingly, and effectively reimplements BLI_findlink.
However, more importantly, for some reason it is coded to return
null for the index 0 instead of the basis shape key. This severely
limits its usability in some cases.
This refactor replaces the function with a simple strongly typed
wrapper around BLI_findlink, using a different name, and updating
the call sites to check that the index is not 0 where necessary.
The old implementation was a simple rounding operation and was not
implemented for full-frame compositor.
The issue with the old implementation is that it will not give
satisfactory results for images with high frequency details,
including cases when is used for a preview on Cycles render with
low number of samples. Additionally, when applied on animated
footage it produces very noisy result.
The new algorithm uses an explicit pixel size setting, which allows
the node to be used on its own, without need to have scale-down and
scale-up nodes. It also uses neighbour averaging, which produces
better looking result during animation and noisy input images.
The old tiled compositor setup will render without changes with
this change. This commit does not include modifications in the GPU
compositor implementation.
Ref #88150
Pull Request: https://projects.blender.org/blender/blender/pulls/117223
Increase performance when drawing scenes that don't have blended materials. This should
save some CPU and GPU cycles as parts (or the whole pipeline) can be skipped.
Mostly it ensures that the hiz isn't tagged dirty and has a chance that it is being reused
by other areas. Shadows and irradiance caches aren't forced to be updated.
Mac Studio M1 Ultra
- space_raceship.blend went from 27 fps to 33 fps (10%-20% improvement).
This is a common scenario to optimize as by default materials are not blended and require
user action to set them up. When using compositing/renderpasses, blended materials aren't
supported and most likely not being used.
Pull Request: https://projects.blender.org/blender/blender/pulls/117269
An assert that ensures the GPU compositor executes in a non main thread
wrongly fires in background mode, that's because in background mode,
rendering happens in the main thread. So add a condition for background
mode.
When enabling the "Only Show Errors" option in the Dope Sheet/Graph Editor,
it might not show anything even though there are FCurves with errors.
The issue is that the flag `FCURVE_DISABLED` is set by the drawing code,
which means the channels have to be visible first.
This creates a workflow issue where you want to filter down to only the
curves with problems, but you need to find them first...
This PR fixes the issue by validating all FCurves whenever the option
is enabled.
Pull Request: https://projects.blender.org/blender/blender/pulls/116815
The FPS menu was using a cached value which wasn't being refreshed
when translation changed.
Add `bpy.app.handlers.translation_update_post` handler which runs
when translation changes, this can be used to clear any cached UI
values.
Ref !117049
Change the behavior of UI_but_string_info_get to fill in shortcuts
when requested.
Previously shortcuts were ignored for menus, because showing shortcuts
in tool-tips which are already displayed in the menu isn't needed.
Move this logic to tool-tip creation so other the shortcuts may be
accessed in other contexts.
