`foreach_id` callbacks should not decide whether a given ID pointers
should be processed or not (unless maybe some extremely specific cases).
Even if an ID pointer is not currently 'used', it still needs to
increment its ID user count, be remapped to a new pointer, etc. etc.
Having this check is likely no more meaningful (it seems to have been
added ages ago), but keeping it around does not hurt either. And it
could avoid crashes in some file corruption cases e.g.
However, having it in 'lib_link' code of constraints is useless for
sure, since that data pointer may have already been accessed in the
'read_data' one. And of course, logically it belongs to 'read_data'
anyway, since it's related (and only affects) private local data, not
pointers to other IDs...
No behavioral change expected here.
There is no reason to do that in the 'lib_link' stage of blendfile
reading, whether the owner ID is linked or local is already known info
at the 'read_data' stage of the process. And it is more logical to do
that in code affecting internal private data of an ID, rather than in
code handling updates of it ID pointers.
Note that the camera's baground image case was already handled in the
'read_data' stage.
No behavioral change expected here.
There is no reason at all for each ID read/write callbacks to have to
deal with this generic, common data explicitely. Generic ID read/write
code is the place to handle such data (just like asset, liboverride,
etc. data are handled already).
Note behavioral change expected here.
This simple function just performed a null check and an array lookup.
Just writing it in the few places its used works fine too, and avoiding
the function call per triangle can improve and make the check clearer.
Also, avoiding the abstraction makes the "node fully visible" check
when building the PBVH more obvious; that has been refactored here.
Pull Request: https://projects.blender.org/blender/blender/pulls/111072
The goal is to move to more data oriented design, reducing memory
usage and simplifying code by clarifying data access, avoiding
unnecessary levels of abstraction, and reusing code.
- Simplify threading with the C++ threading API
- Pass the faces to update with an IndexMask instead of a pointer array
- IndexMask uses less memory and simplifies masking and iteration
- Store the grid to face map with indices instead of pointers
- Now this is exactly the same as `build_loop_to_face_map`
After 12ef20990b, attributes and vertex group names were checked
simultaneously to fix the name collision. But this results in crash when
new attribute is added to curve object (it searches for vertex group
list). To avoid the crash, check for supported id types in new function
`BKE_id_supports_vertex_groups`.
Pull Request: https://projects.blender.org/blender/blender/pulls/111036
For the root group, the parent is `nullptr` so calling `parent_group()`
would fail. This fixes the issue by adding a null check and returning
`nullptr` otherwise.
This patch adds layer widgets in the grease pencil layer channels of the grease pencil dopesheet.
It adds RNA + getter function for the `use_onion_skinning` at layer level.
It also sets the offset of the channel, and the color of grease pencil data-block channels.
Pull Request: https://projects.blender.org/blender/blender/pulls/110991
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
Implementation of the transform action for grease pencil frames, which enables translating and scaling grease pencil frames in the dopesheet.
This patch adds the following in the grease pencil API :
- `move_frames` to move a set of frames given a map of key transformations (with overwrite), and
- the structure `LayerTransformData` that stores in the layer runtime some useful data for the frames transformation.
Co-authored-by: Falk David <falk@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/110743
In RNA collections storing ID references, the name of the collection
item may not always be unique, when several IDs from different libraries
are present.
While rare, this situation can become deadly to liboverride, by causing
random but exponential liboverride hierarchies corruptions.
This has already been alleviated by using preferably both name and index
in items lookup (a05419f18b) and by reducing the risk of name collision
in general between liboverrides and their linked reference (b9becc47de).
This commit goes further, by ensuring that references to items of RNA
collections of IDs stored in liboverride operations become completely
unambiguous. This is achieved by storing an extra pointer to the item's
ID itself, when relevant.
Lookup then requires a complete match `name + ID` to be successful,
which is guaranteed to match at most a single item in the whole RNA
collection (since RNA collection of IDs do not allow duplicates, and
the ID pointer is always unique).
Note that this ID pointer is implemented as an `std::optional` one
(either directly in C++ code, or using an new liboverride operation `flag`
in DNA). This allows to smoothly transition from existing data to the
added ID pointer info (when needed), without needing any dedicated
versioning. This solution also preserves forward compatibility as much
as possible.
It may also provide marginal performances improvements in some cases, as
looking up for ID items in RNA collections will first check for the
ID pointer, which should be faster than a string comparision.
Implements #110421.
Pull Request: https://projects.blender.org/blender/blender/pulls/110773
Instead of removing frames one by one, the `GreasePencil::remove_frames`
function now expects a span of frame numbers, replacing the
`GreasePencil::remove_frame_at` function.
Now, when drawings need to be deleted, we shrink the array only once.
Pull Request: https://projects.blender.org/blender/blender/pulls/110957
Support name-spaced add-ons, exposed via user configurable extension
repositories.
Directories for add-ons can be added at run-time and are name-spaced to
avoid name-collisions with Python modules or add-ons from other
repositories.
This is exposed as an experimental feature "Extension Repositories".
Details:
- A `bUserExtensionRepo` type which represents a repository which is
listed in the add-ons repository.
- `JunctionModuleHandle` class to manage a package with sub-modules
which can point to arbitrary locations.
- `bpy.app.handlers._extension_repos_update_{pre/post}` internal
callbacks run before/after changes to extension repositories,
callbacks are used to sync the changes to the Python package that
exposes these to add-ons.
- The size of an add-on name has been increased so a user-defined package
prefix can be included without enforcing shorter add-on names.
- Functionality relating to package management has been left out of this
change and will be developed separately.
Further work:
- While a repository can be renamed, enabled add-ons aren't renamed.
Eventually we might want to support this although we could also
disallow renaming repositories with add-ons enabled as the name isn't
all that significant.
- Removing a repository should remove all the add-ons located in this
repository.
- Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*`
we might want to relax this to allow unicode characters (we might
still want to disallow `-` or any characters that would prevent
attribute access in code).
Ref !110869.
Reviewed By: brecht
Remove the 'SceneCollection' structure definition from DNA, and the
compatibility code converting it to the 'modern' viewlayer system.
'SceneCollection' was part at some point of the new collection system
during 2.80 development, but was never in any published Blender release.
So this code was only ensuring compatibility with a few potential
Blender files saved from in-development builds over four years ago.
Implements #110918.
Pull Request: https://projects.blender.org/blender/blender/pulls/110926
Happens on Apple M2 platform. Caused by indirectly included queue.h
via tbb, which has its own LIST_SWAP.
Rename our macro to `LISTBASE_SWAP` to avoid conflicts.
Pull Request: https://projects.blender.org/blender/blender/pulls/110943
Part 1/3 of #109135, #110272
Adds a new DNA structure for defining node group interfaces without
using `bNodeSocket` and with additional node UI item types.
Node group interfaces are organized as a hierarchy of "items", which
can be sockets or panels. Panels can contain both sockets and other
panels (although nested panels beyond the root panel may be disabled to
avoid complexity on the user level).
Sockets can be added to the interface in any order, not just the
conventional outputs..inputs order. Sockets can be marked as both input
and output, generating 2 sockets on node instances.
The C++ API in the DNA struct allows manipulating the interface
declaration by adding and removing items, moving them inside the
interface or into a different panel.
Pull Request: https://projects.blender.org/blender/blender/pulls/110885
First implementation of node previews in the shader node editor. Using
the same user interface as compositor node previews, most shader nodes
can now be previewed (except group in/output and material output).
This is currently still an experimental feature, as polishing of the
user experience and performance improvements are planned. These will
be easier to do as incremental changes on this implementation.
See #110353 for details on the work that remains to be done and known
limitations.
Implementation notes:
We take advantage of the `RenderResult` available as `ImBuf` images to
store a `Render` for every viewed nested node tree present in a
`SpaceNode`. The computation is initiated at the moment of drawing nodes
overlays.
One render is started for the current nodetree, having a `ViewLayer`
associated with each previewed node. We separate the previewed nodes in
two categories: the shader ones and the non-shader ones.
- For non-shader nodes, we use AOVs which highly speed up the rendering
process by rendering every non-shader nodes at the same time. They are
rendered in the first `ViewLayer`.
- For shader nodes, we render them each in a different `ViewLayer`, by
rerouting the node to the output of the material in the preview scene.
The preview scene takes the same aspect as the Material preview scene,
and the same preview object is used.
At the moment of drawing the node overlay, we take the `Render` of the
viewed node tree and extract the `ImBuf` of the wanted viewlayer/pass
for each previewed node.
Pull Request: https://projects.blender.org/blender/blender/pulls/110065
Naming is bad and confusing, but the 'expander' code path from readfile
can also be used outside of the reading context (see e.g.
`BKE_blendfile_write_partial` code). So code cannot assume that it is
exclusively working on data freshly read from file.
This should be renamed - but should also be probably replaced by
proper usage of the more generic 'foreach_id' code anyway, see #105134.
Found while investigating #109588.
These name collisions should be avoided with attributes, all sorts of
issues can arise from those. We already warned in the attributes
(but not the vertex groups) list if those were found.
Previously, creating a vertex group with the same name as an already
existing attribute would allow this (and give said warning), and creating
an attribute with the same name as an already existing vertex group
would silently fail (as in: not return a layer) -- and then due to an oversight
in 101d04f41f (which assumed a valid layer would always be returned
by `BKE_id_attribute_new`) would even crash.
Now name collisions between vertex groups and attributes are avoided,
unique names will be found across attributes and vertex groups if either
`BKE_id_attribute_calc_unique_name` or `BKE_object_defgroup_unique_name`
is called.
This is done by unifying the checks and callbacks for both into a single.
Pull Request: https://projects.blender.org/blender/blender/pulls/109910
Update #BKE_lib_override_library_id_unused_cleanup to also clear the
property when all its operations have been removed, even if the
property itself was not tagged as unused.
This feature is going to be replaced with a more thorough refactoring
of the node group interface UI, which has actual node drawing support
and a new API for integration of panels into nodes.
Design task: #109135
Implementation: #110272
Pull Request: https://projects.blender.org/blender/blender/pulls/110803
The goal is to get to closer to removing `NOD_static_types.h` and to define all/most
aspects of a node in the node file itself instead. Data defined in node files is not
available when rna structs are created currently, because that happens in a preprocessing
step. This patch moves part of what was defined in `rna_nodetree.cc` to `node.cc` which
makes it easier to replace when `NOD_static_types.h` is removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/110824
The overall goal is to get rid of `NOD_static_types.h`. This patch removes
one usage of it to generate the `node.type` rna enum. Not all of the data
was available on `bNodeType` already, so I had to add the missing data there.
Pull Request: https://projects.blender.org/blender/blender/pulls/110810
Add three new nodes for operations and inputs specific to
node group operators.
- **Selection** Whether elements are selected in the viewport
- **Set Selection** Sets the edit/sculpt selection, on the point,
face, or curve domains
- **3D Cursor** Gives the location and rotation of the 3D cursor,
in the local space of the modified object.
- **Face Set** The face set value from mesh sculpt mode,
and whether the attribute exists.
- **Set Face Set** Set sculpt face set values.
In the add menu and search, the nodes are only visible in the
"Tool" context of the geometry node editor. They also give
errors when executed by a modifier.
Pull Request: https://projects.blender.org/blender/blender/pulls/109517
This function is used to retrieve the index of the n'th layer of
the specified type, if it exists. Currently the way it handles
an n value that is too big is inconsistent: if there are more
layers of different types following the ones of the correct type,
and n isn't too big, it will safely detect that the corresponding
layer is of a different type and return -1. However, if the value
results in a buffer overrun, it causes an assertion or crash.
This means that safe code should currently ensure n is always
correct, making the type check in this function pointless.
Moreover, checking the range in the caller may incur more
overhead than making this code safe.
This changes the assert into a check to ensure consistent behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/110812
