Store temporrary tooltip text as `std::string` instead of
manually allocated C strings. Use `fmt` to format instead
of our own formatting utilities that return an allocated C
string.
Instead of a single function with variadic arguments, a special enum
type containing which string to request, and a special struct to
contain the request and the result, just use separate functions for
each request, and return a std::string by value. Also change the enum
item string access to just give access to the enum item itself and add
const in a few places as necessary.
The callers of the API function get much clearer this way, and it's
much easier to see which information is used to create certain tooltip
strings.
Previously, `frame_key_at` would return `-1` for when it couldn't find
a key for the given frame.
This could lead to issues though, because `-1` is a valid key (it is a valid scene frame number).
This changes the API to return an optional instead. This makes it very clear
when no key was found, and should make it less error prone.
Possibly also fixes write past array boundaries.
Happens with the mikassa-shading.blend file, by simply opening
the file in debug mode. The fix is suggested by Jacques.
Pull Request: https://projects.blender.org/blender/blender/pulls/117331
The term `PIL` stands for "platform independent library." It exists since the `Initial Revision`
commit from 2002. Nowadays, we generally just use the `BLI` (blenlib) prefix for such code
and the `PIL` prefix feels more confusing then useful. Therefore, this patch renames the
`PIL` to `BLI`.
Pull Request: https://projects.blender.org/blender/blender/pulls/117325
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
