Previously we'd just allocate extra space for additional data for the
deferred loading, and then do pointer arithmetic to access that data.
This is cryptic and not type safe.
Instead, use an internal type deriving from `PreviewImage`, and manage
that internally. This ensures type safety, while keeping this as
implementation detail (not visible outside of the preview image API) and
keeping internals easy to understand.
Some code did shallow copies of preview images, making ownership
unclear. That made things a bit tricky, but I've made support for
shallow copies explicit now and noted this in comments.
The problem was that there was a cyclic nesting dependency that was not detected
correctly, which led to problems further down the line. See the PR for details.
Right now, the zones just disappear when there is an error. This has to be improved
at some point, but it outside of the scope of this patch.
A regression test that covers this case is added as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/111689
Part 3/3 of #109135, #110272
Switch to new node group interfaces and deprecate old DNA and API.
This completes support for panels in node drawing and in node group
interface declarations in particular.
The new node group interface DNA and RNA code has been added in parts
1 and 2 (#110885, #110952) but has not be enabled yet. This commit
completes the integration by
* enabling the new RNA API
* using the new API in UI
* read/write new interfaces from blend files
* add versioning for backward compatibility
* add forward-compatible writing code to reconstruct old interfaces
All places accessing node group interface declarations should now be
using the new API. A runtime cache has been added that allows simple
linear access to socket inputs and outputs even when a panel hierarchy
is used.
Old DNA has been deprecated and should only be accessed for versioning
(inputs/outputs renamed to inputs_legacy/outputs_legacy to catch
errors). Versioning code ensures both backward and forward
compatibility of existing files.
The API for old interfaces is removed. The new API is very similar but
is defined on the `ntree.interface` instead of the `ntree` directly.
Breaking change notifications and detailed instructions for migrating
will be added.
A python test has been added for the node group API functions. This
includes new functionality such as creating panels and moving items
between different levels.
This patch does not yet contain panel representations in the modifier
UI. This has been tested in a separate branch and will be added with a
later PR (#108565).
Pull Request: https://projects.blender.org/blender/blender/pulls/111348
When the final curve point indices are in the same order as the input
points, and there are many curves, avoid copying point domain
attributes, by generalizing the existing check from the mesh
to curve conversion node.
Pull Request: https://projects.blender.org/blender/blender/pulls/111662
`LayerTypeInfo` can define a `layers_max()` function which determines the
maximum allowed number of layers.
Upon merging, this limit was respected from the source, but not on the
destination, so it was possible to exceed the max (if there were layers
on the destination already).
NOTE: `layers_max()` is currently only defined for legacy CD_MTFACE, but
we might want to enforce this for UVs / CD_PROP_FLOAT2 again.
This came up in #111608.
Pull Request: https://projects.blender.org/blender/blender/pulls/111609
Since the normals are stored in a shared cache, tagging them dirty
recreated the cache from scratch when it was shared. Instead,
add a function that updates the cache in the same call as tagging
it dirty. This keeps the old state of the cache around even if it was
shared, and reflects the way that it's really the PBVH and sculpt
mode managing the dirty status of normals while sculpt mode
is active.
One consequence is that the BVH cache and the triangulation
cache need to be tagged dirty manually. I'd like to avoid abstracting
this more than necessary, because I'm hoping in the long term
different caching abstractions like a more global cache that takes
implicit sharing versions into account will make this complexity
unnecessary.
Fixes#111628, #111563
Pull Request: https://projects.blender.org/blender/blender/pulls/111641
The `EdgeHash` and `EdgeSet` data structures are designed specifically
as a hash of an order agnostic pair of integers. This specialization can
be achieved much more easily with the templated C++ data structures,
which gives improved performance, readability, and type safety.
This PR removes the older data structures and replaces their use with
`Map`, `Set`, or `VectorSet` depending on the situation. The changes
are mostly straightforward, but there are a few places where the old
API made the goals of the code confusing.
The last time these removed data structures were significantly changed,
they were already moving closer to the implementation of the newer
C++ data structures (aa63a87d37).
Pull Request: https://projects.blender.org/blender/blender/pulls/111391
New node to converts groups of points to curves. Groups
of points defined as `Curve Group ID` attribute. `Weight` in curve
is used for sort points in each group. Points of result curves
propagate attributes from original points. Implicit conversion
of other geometry types is not supported currently.
Pull Request: https://projects.blender.org/blender/blender/pulls/109610
- Multiple issues in the Data Transfer modifier error messages:
- "None" -> "none", this word in the middle of a sentence, no need
for upper case.
- "amount of <element>" -> "number", more appropriate for discrete
counts.
- "doesn't" -> "does not", to respect Blender's style guide.
- "The grease pencil object need an Armature modifier" -> "needs",
grammar.
- "Armature modifier is not valid or wrong defined" -> "is invalid".
Unclear what "wrong defined" means.
- The "Recent Reports" text block has not been used since 2.81.
- "Not valid subdivisions found to rebuild lower levels" -> "No
valid...", typo.
- "extensions repository" -> "extension repository": typo.
- "... , but loose correct blending..." -> "lose": typo.
- "True when multiple enums ": trailing whitespace.
- "Number of ray per pixel" -> "rays": typo.
- "Curve Parameter node" -> "Spline ...": this is the actual name of
the node after its rename in 1cd9fcd98d.
Pull Request: https://projects.blender.org/blender/blender/pulls/111145
Armature layers (the 32 little dots) and bone groups are replaced with
Bone Collections:
- Bone collections are stored on the armature, and have a name that is
unique within that armature.
- An armature can have an arbitrary number of bone collections (instead
of the fixed 32 layers).
- Bones can be assigned to zero or more bone collections.
- Bone collections have a visibility setting, just like objects in scene
collections.
- When a bone is in at least one collection, and all its collections in
are hidden, the bone is hidden. In other cases (in any visible
collection, or in no collection at all), the bone visibility is
determined by its own 'hidden' flag.
- For now, bone collections cannot be nested; they are a flat list just
like bone groups were. Nestability of bone collections is intended to
be implemented in a later 4.x release.
- Since bone collections are defined on the armature, they can be used
from both pose mode and edit mode.
Versioning converts bone groups and armature layers to new bone
collections. Layers that do not contain any bones are skipped. The old
data structures remain in DNA and are unaltered, for limited forward
compatibility. That way at least a save with Blender 4.0 will not
immediately erase the bone group and armature layers and their bone
assignments.
Shortcuts:
- M/Shift+M in pose/edit mode: move to collection (M) and add to
collection (shift+M). This works similar to the M/Shift+M menus for
objects & scene collections.
- Ctrl+G in pose mode shows a port of the old 'bone groups' menu. This
is likely to be removed in the near future, as the functionality
overlaps with the M/Shift+M menus.
This is the first commit of a series; the bone collections feature will
be improved before the Blender 4.0 release. See #108941 for more info.
Pull request: https://projects.blender.org/blender/blender/pulls/109976
Move control over the color of bones from bone groups to the bones
themselves. Instead of using bone groups (which are defined on the pose,
and thus owned by the object), the color is stored on:
- the bone (`struct Bone`, or RNA `armature.bones['bone_name'].color`)
- a possible override on the pose bone (`struct bPoseChannel`, or RNA
`ob.pose.bones['bone_name'].color`).
When the pose bone is set to its default color, the color is determined
by the armature bone. In armature edit mode, the armature bone colors
are always used, as then the pose data is unavailable.
Versioning code converts bone group colors to bone colors. If the
Armature has a single user, the group color is stored on the bones
directly. If it has multiple users, the group colors will be stored on
the pose bones instead.
The bone group color is not removed from DNA for forward compatibility,
that is, to avoid immediate dataloss when saving a 3.6 file with 4.0.
This is part of the replacement of bone groups & armature layers with
bone collections. See the design task at #108941.
Pull request: https://projects.blender.org/blender/blender/pulls/109976
4.0 files now include asset shelf regions in 3D views. This region type is not
known to older Blender versions. So far, in such cases we would just change
the region type to be the first known region type and keep the region storage
otherwise. This was arbitrary, and in fact unsafe: the reused settings may
violate invariants/assumptions for a region type and worse, the
`ARegion.regiondata` can only be interpreted and correctly written to files
if the region type is known.
Make sure all invalid regions (regions where the type cannot be restored) are
removed on file read.
Committed to 3.6 release branch as e2d4403497.
Pull Request: https://projects.blender.org/blender/blender/pulls/111483
Although I don't like the idea of using owning raw pointers in new APIs
like this (violates fundamental C++ good practises), this type is mostly
meant for writing to files via DNA. So we have to use Blender's memory
management via the guarded allocator here.
Considered making this an alternative function, but then we'd have to
duplicate logif or duplicate memory or so. Not worth it to me.
Move Auto-Offset toggle from Node Editor View menu
into the Editing > Node Editor section of User Preferences,
to reflect its use as a workflow option not configured
per editor or per file.
Pull Request: https://projects.blender.org/blender/blender/pulls/111589
Change the algorithm to make better use of multiple CPU cores. First
offsets are created by counting the number of elements using each
vertex. Those offsets are used during the next phase that adds indices
to each group in parallel. Atomic increments are used to add elements
to each group. Since the order in each group is non-deterministic,
they are sorted in parallel afterwards.
The performance improvement depends on the number of cores, CPU caches,
memory bandwidth, single threaded performance, and mesh topology. In
our tests, performance improved by 3-4.5x for large grid-like meshes.
See [1] for investigation of this algorithm and potential alternatives.
1. https://hackmd.io/@s0TMIS4lTAGwHVO20ECwpw/build_edge_to_loop_map_tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/110707
Since vertex and face normals can be calculated separately, it simplifies
things to further separate the two caches. This makes it easier to use
`SharedCache` to avoid recalculating normals when copying meshes.
Sharing vertex normal caches with meshes with the same positions and
topology allows completely skipping recomputation as meshes are
copied. The effects are similar to e8f4010611, but normals are much
more expensive, so the benefit is larger.
In a simple test changing a large grid's generic attribute with geometry
nodes, I observed a performance improvement from 12 to 17 FPS.
Most real world situations will have smaller changes though.
Completely splitting face and vertex calculation is slightly slower
when face normals aren't already calculated, so I kept the option
to recalculate them together as well.
This simplifies investigating the changes in #105920 which resolve
non-determinism in the vertex normal calculation. If we can make the
topology map creation fast enough, that might allow simplifying this
code more in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/110479
This was hard coded to 8, which can still result in a number that
jitters making the overall FPS difficult to measure.
The default is still 8, but this is now a preference that can be
increased for values that don't jitter as much.
The situation at this stage of readfile process is now sane enough, that
the regular Pose freeing code can be called, avoiding potential
memleaks.
Note that this whole 'non-Empty object with NULL obdata' case should now
be very hypothetical, since in case a linked obdata goes missing,
Blender will generate and empty place-holder for it at read time.
Tested by artificially setting all Armature objects' obdata pointer to
null in read_data code, and loading some complex production files from
Pets Project.
Keeping a mutable reference to vertex normals for the entire lifetime
of the PBVH structure makes caching the normals and sharing the cache
harder than it should be. Generally code is safer when we reduce the
number of mutable references to data.
Currently the normals are modified in two places. First is the sculpt
mesh normal recalculation. There we can just retrieve the normals from
the mesh each time. Second is the restore from an undo step. That is
unnecessary because the normals are marked for recalculation anyway.
It doesn't even make much sense to store the normals in an undo step
when we can easily recalculate them based on new positions.
This change helps with #110479. These were also the last place that
kept a mutable reference to normals. I tested undo and redo after
sculpting, and it works well for each PBVH type.
Pull Request: https://projects.blender.org/blender/blender/pulls/111470
The `lib_link` callback cannot always be fully replaced/removed, as in
some case it is also doing some validation checks, or data editing based
on the result of lib_linking internal ID pointers.
The callback has been renamed for that purpose, from `read_lib` to
`read_after_liblink`. It is now called after all ID pointers have been
fully lib-linked for the current ID, but still before the call to
`do_versions_after_linking`.
This change should not have any behavioral effect. Although in theory
the side-effect of this commit (to split lib linking itself, and the
validation/further processing code) into two completely separated steps
could have some effects, in practice none are expected, and tests did
not show any changes in behavior either..
Part of implementing #105134: Removal of readfile's lib_link & expand code.
This PR adds an initial set of nodes using the new rotation socket.
6 nodes build rotations or convert them to other formats, a 7th rotates
a vector with a rotation, and the last inverts rotations.
The design task #109965 describes the choice to use separate nodes
for the rotation construction and separation operations. In the future,
a "Switch Node" operator (#111438) will help to make working with
these separated nodes faster.
- **Axis Angle to Rotation**
- **Rotation to Axis Angle**
- **Combine Quaternion**
- **Separate Quaternion**
- **Euler to Rotation**
- **Rotation to Euler**
- **Rotate Vector**
- **Invert Rotation**
See #92967
Pull Request: https://projects.blender.org/blender/blender/pulls/109030
After undoing a visibility change, the visibility is propagated from
multires grids to mesh faces and vertices. This progress was completely
single threaded and more complicated than necessary. Simplify it
using newer C++ data structures and APIs.
The `expand` callback is 'trivial' to replace, since it is only iterating
over ID pointers and calling a callback.
The only change in behavior here is that some pointers that were not
processed previously will now be.
In practice this is not expected to have any real effect (usually
the IDs used by these pointers would have been expanded through other
usages anyway). But it may solve a few corner cases, undocumented issues
though.
Part of implementing #105134: Removal of readfile's lib_link & expand code.
There are actually cases where you do not want to access the original
ID pointers, even though the callback will not modify them. One example
is the incoming generic 'expand' readfile callback, which will replace the
dedicated one for all ID types.
Related to #105134: Removal of readfile's lib_link & expand code.
In readfile context, some ID pointers have to be ignored: typically the
'owner_id' pointers of embedded data.
Currently unused, but required for replacing `blend_read_lib`/
`blend_read_expand` by `foreach_id` (#105666).
Call functions directly in lambdas rather than passing their
arguments in a separate void * argument. This can be changed
more in the future to move callback arguments out of smaller
structs.
This commit adds a new option flag to the lib_query foreach_id code,
which will make deprecated ID pointers to be processed as well.
NOTE: Currently there is no report to the callbakcs about the fact that
it is processing a deprecated ID. This can be easily added later if it
becomes necessary.
Part of implementing #105134: Removal of readfile's lib_link & expand code.
This is in prevision of EEVEE panoramic projection support.
EEVEE-Next is planned to add support for these parameters.
Not having these parameters in Blender DNA will make Cycles
and EEVEE not share the same parameters and will be confusing
for the user.
We handle forward compatibility by still writing the parameters
as ID properties as previous cycles versions expect.
Since this change will break the API compatibility it is crucial
to make it for the 4.0 release.
Related Task #109639
Pull Request: https://projects.blender.org/blender/blender/pulls/111310
Blender's C++ data structures have configurable inline buffers used to
avoid allocation when the needed size is small. Use them in multires
code instead of an uglier C solution.
Pull Request: https://projects.blender.org/blender/blender/pulls/111070
The only acceptable case to handle internal data in 'lib_link' code is
when it depends on other IDs info. Otherwise, it should be done in
'read_data' code (and versioning if relevant).
Implements the paper [A Microfacet-based Hair Scattering
Model](https://onlinelibrary.wiley.com/doi/full/10.1111/cgf.14588) by
Weizhen Huang, Matthias B. Hullin and Johannes Hanika.
### Features:
- This is a far-field model, as opposed to the previous near-field
Principled Hair BSDF model. The hair is expected to be less noisy, but
lower roughness values takes longer to render due to numerical
integration along the hair width. The hair also appears to be flat when
viewed up-close.
- The longitudinal width of the scattering lobe differs along the
azimuth, providing a higher contrast compared to the evenly spread
scattering in the near-field Principled Hair BSDF model. For a more
detailed comparison, please refer to the original paper.
- Supports elliptical cross-sections, adding more realism as human hairs
are usually elliptical. The orientation of the cross-section is aligned
with the curve normal, which can be adjusted using geometry nodes.
Default is minimal twist. During sampling, light rays that hit outside
the hair width will continue propogating as if the material is
transparent.
- There is non-physical modulation factors for the first three
lobes (Reflection, Transmission, Secondary Reflection).
### Missing:
- A good default for cross-section orientation. There was an
attempt (9039f76928) to default the orientation to align with the curve
normal in the mathematical sense, but the stability (when animated) is
unclear and it would be a hassle to generalise to all curve types. After
the model is in main, we could experiment with the geometry nodes team
to see what works the best as a default.
Co-authored-by: Lukas Stockner <lukas.stockner@freenet.de>
Pull Request: https://projects.blender.org/blender/blender/pulls/105600
Partially reverts b14a0ee57e.
Instead of renaming the DNA field, use namespaces in C++ to resolve
name collisions (which is the reason this change was done
in the first place).
The potential data already read in `instance_weights` listbase needs to
be freed, instead of just clearing the listbase.
Also move some (very old!) versioning code out of Particle's 'lib_link'
code into proper versioning code.
Not sure how bad that was in practice, was likely harmless. But
foreach_id logic should never decide to not process an ID pointer
because its value is NULL. Callback code is expected to handle NULL
pointers appropriately.
Unfortunately, relying only on the 'embedded' flag of the collection ID
pointer to detect the LayerCollection of a Scene embedded collection is
not enough, since this info may not always be available.
So add an extra explicit 'is_master' to the recursive code processing
all LayerCollections ID pointerrs, and double-check with an assert that
this info is coherent with the Collection's embedded flag, when
possible.
In a few cases (IPO conversion, Proxy conversion, ...), versioning
implies creating or removing IDs, and/or needs access to the whole Main
data-base.
So far this was done ad-hoc by adding some code at the end of
`setup_app_data`.
This commit formalizes this process by adding a BLO call
(`BLO_read_do_version_after_setup`) that will encapsulate all such
complex versioning code.
NOTE: This commit does not address the existing issue that this
versioning code is never performmed when linking new data (outside of
the 'opening a blendfile' context). This topic would require its own
design task.
NOTE: This commit does not fix the few current evil cases of ID creation in
regular versioning code. This will be addressed separately.
Although this commit does modifies slightly some logic in this specific
versioning process, no behavioral changes are expected here.
Pull Request: https://projects.blender.org/blender/blender/pulls/111147
Some functionality of `Layer`s and `LayerGroup`s can be shared. This is why the `TreeNode` class exists. It encapsulates all the common methods both `Layer`s and `LayerGroup`s should have.
Up until now, the usage of `TreeNode` was not consistent and often the layers would just access the base c-struct directly.
This refactor makes it so that all of the functions affecting only the `TreeNode` are moved to the `TreeNode` class and only implemented there.
For example, renaming a layer is really just renaming the node. Therefor there shouldn't even be a `rename_layer` and `rename_layer_group` function. These were combined into a `rename_node` function.
Pull Request: https://projects.blender.org/blender/blender/pulls/111177
Not sure how bad that was in practice, was likely harmless. But
foreach_id logic should never decide to not process an ID pointer
because its value is NULL. Callback code is expected to handle NULL
pointers appropriately.
Include counts of some headers while making full blender build:
- BLI_color.hh 1771 -> 1718
- BLI_math_color.h 1828 -> 1783
- BLI_math_vector.hh 496 -> 405
- BLI_index_mask.hh 1341 -> 1267
- BLI_task.hh 958 -> 903
- BLI_generic_virtual_array.hh 509 -> 435
- IMB_colormanagement.h 437 -> 130
- GPU_texture.h 806 -> 780
- FN_multi_function.hh 331 -> 257
Note: DNA_node_tree_interface_types.h needs color include only
for the currently unused (but soon to be used) socket_color function.
Future step is to figure out how to include
DNA_node_tree_interface_types.h less.
Pull Request: #111113
The recent change to header copyrights [0] unintentionally changed
"Blender Foundation" to "Blender Authors" for the WIN32 file path
which blender is installed into.
Revert lines changed that aren't related to copyright text.
[0]: e955c94ed3
Including <iostream> or similar headers is quite expensive, since it
also pulls in things like <locale> and so on. In many BLI headers,
iostreams are only used to implement some sort of "debug print",
or an operator<< for ostream.
Change some of the commonly used places to instead include <iosfwd>,
which is the standard way of forward-declaring iostreams related
classes, and move the actual debug-print / operator<< implementations
into .cc files.
This is not done for templated classes though (it would be possible
to provide explicit operator<< instantiations somewhere in the
source file, but that would lead to hard-to-figure-out linker error
whenever someone would add a different template type). There, where
possible, I changed from full <iostream> include to only the needed
<ostream> part.
For Span<T>, I just removed print_as_lines since it's not used by
anything. It could be moved into a .cc file using a similar approach
as above if needed.
Doing full blender build changes include counts this way:
- <iostream> 1986 -> 978
- <sstream> 2880 -> 925
It does not affect the total build time much though, mostly because
towards the end of it there's just several CPU cores finishing
compiling OpenVDB related source files.
Pull Request: https://projects.blender.org/blender/blender/pulls/111046
This PR adds the Lacunarity and Normalize inputs to the Noise node
similar to the Voronoi node.
The Lacunarity input controls the scale factor by which each
successive Perlin noise octave is scaled. Which was previously hard
coded to a factor of 2.
The Noise node normalizes its output to the [0, 1] range by default.
The Normalize option makes it possible for the user to disable that.
To keep the behavior consistent with past versions it is enabled by
default.
To make the aforementioned normalization control easer to implement,
the fractal noise code now accumulates signed noise and remaps the
final sum, as opposed to accumulating positive [0, 1] noise.
Pull Request: https://projects.blender.org/blender/blender/pulls/110839
This makes it so the `GreasePencil` geometry gets updated on a time
change.
The frame at which the object gets evaluated is stored in runtime as
`eval_frame`. This is for example used to calculate the bounding box
of the geometry as well as invalidating the batch cache for different
frames.
Pull Request: https://projects.blender.org/blender/blender/pulls/111137
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
Changes to internal private data of an ID has _nothing_ to do into its
'lib_link' reading code (unless in the extremely rare case where it
would have hard dependency on its ID having valid ID pointers).
In that case, `BKE_paint_runtime_init` was already called in
`BKE_paint_blend_read_data` anyway, so the only actual change was
setting `p->paint_cursor`... *sigh*
`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
Add support in the UI for the edit mode of curves, mesh, and point
cloud objects. It's possible to control for which mode sand object
types the asset is available with a dropdown in the node header.
To make this per-mode filtering possible, the static asset tree
cache is now unique per context mode.
See #101778
Pull Request: https://projects.blender.org/blender/blender/pulls/109526
Show node group inputs in the redo panel, including the
"use attribute" toggle. There are a few limitations that will
be solved separately:
- The redo panel is _always_ drawn, there is no way to show it conditionally yet
- There is no way to add the operator name to the redo panel title yet
- Attribute search is still missing for attribute inputs
Pull Request: https://projects.blender.org/blender/blender/pulls/109975
Remove the "_for_read" suffix from methods to get geometry and geometry
components. That should be considered the default, so the suffix just
adds unnecessary text. This is consistent with the attribute API and
various implicit sharing data access methods.
Use "from_mesh" instead of "create_with_mesh". This is consistent with
the recently used naming for the `IndexMask` API.
Pull Request: https://projects.blender.org/blender/blender/pulls/110738
No user visible changes expected, except of new experimental feature
option.
------------------------------------------------------------------------------
This introduces asset shelves as a new standard UI element for accessing
assets. Based on the current context (like the active mode and/or tool), they
can provide assets for specific workflows/tasks. As such they are more limited
in functionality than the asset browser, but a lot more efficient for certain
tasks.
The asset shelf is developed as part of the brush assets project (see #101895),
but is also meant to replace the current pose library UI.
Support for asset shelves can quite easily be added to different editor types,
the following commit will add support for the 3D View. If an editor type
supports asset shelves, add-ons can chose to register an asset shelf type for
an editor with just a few lines of Python.
It should be possible to entirely remove `UILayout.asset_view_template()` once
asset shelves are non-experimental.
Some changes are to be expected still, see #107881.
Task: #102879
Brush asset workflow blog post: https://code.blender.org/2022/12/brush-assets-workflow/
Initial technical documentation: https://developer.blender.org/docs/asset_system/user_interface/asset_shelf/
Pull Request: #104831
Implement capture point bias. This offsets the capture
points to reduce the amount bad capture locations (i.e.:
inside objects, near walls etc...).
Two new parameters are added:
- Capture Surface Bias: Ensure a minimum distance between
capture points and surrounding geometry. This is expressed as the
relative distance between two capture point. Requires re-bake
to take effect.
- Capture Escape Bias: Moves capture points enclosed inside
objects above the nearest surface. This bias defines how far a
capture point can be moved for escaping the object. This is
expressed as the relative distance between two capture point.
Requires re-bake to take effect.
This is called virtual offset in the reference material.
A quick prepass runs before the baking to offset the samples away
from any surface that could potentially make bad samples.
In order to speedup the process, we create cluster list of surfels
near each irradiance grid point. This allow access to neighboring
surfels that can contribute to the virtual offset which should
never be more than half a cell wide.
Pull Request: https://projects.blender.org/blender/blender/pulls/110355
A few places already calculated vertex normals with better contextual
information to improve performance. To allow changing the storage of
vertex normals more (mostly for improved caching), change some code
from "get normals, set values, clear dirty flag" to "make vertex
normals data, give to mesh". This makes the API less awkward too,
since previously the "get for write" and "clear dirty" calls always
had to be separated.
Pull Request: https://projects.blender.org/blender/blender/pulls/110754
Implement invalid sample points filling. Improves invalid regions
but introduce light leak.
Grid sample points are considered invalid if they have a ratio of
front-face ray hit under the given threshold. This is a post-processing
pass on the baked lighting that fills dark regions produced by
invalid sample location (e.g.: inside walls) with valid neighbor
samples data.
Two new parameters are added:
- Dilation Threshold: Validity threshold under which grid samples are
considered invalid. Invalid samples will gather valid lighting data
from valid neighbors inside the dilation radius.
- Dilation Radius: Radius of the dilation process. Expressed in grid
sample distance.
The validity of each point is progressively refined just like the
lighting data during the baking process.
The dilation process is implemented as a post-processing pass during
the loading of the grid data into the irradiance atlas. This allows
live tweaking the dilation parameters.
Pull Request: https://projects.blender.org/blender/blender/pulls/110386
Recently a user expressed interest in exporting baked animation
with B-Bone segments. Currently the python API already exposes
segment matrices via a PoseBone method, but there is no access
to the mapping of vertices to the segments.
Although currently the math is simple and easy to re-implement,
forcing Python add-ons to do that would cause a maintenance issue
if the mapping is ever changed later (it's quite dumb, ignoring
the rest pose curve, and there definitely is room for improvement).
This patch extracts the relevant math into a BKE function, and
exposes it in the python API as a new PoseBone method.
Pull Request: https://projects.blender.org/blender/blender/pulls/105419
`NLASTRIP_TYPE_TRANSITION` was being used incorrectly as a flag, having
`NLASTRIP_TYPE_TRANSITION=1` and `NLASTRIP_TYPE_SOUND=3` in the enum
`eNlaStrip_Type`, when evaluating `NLASTRIP_TYPE_SOUND &
NLASTRIP_TYPE_TRANSITION` gives a invalid truish value.
Also `strips` that can't be placed were freed, but no removed from the
`strips list`, this will cause a error if the `strip` is at begin
or end of the list.
Pull Request: https://projects.blender.org/blender/blender/pulls/110605
In `Layer::remove_frame` there is a case where the frame is not removed,
but overridden by a null-frame. In this case, the frames map was not
tagged, when it should have been.
Changing the frames map would lead to a crash later in undo.
This was because the `frames_storage` was not written to file corectly.
When the `frames_storage` was tagged dirty, it recreated the
`frames_storage.num` as well as the `keys` and `values` pointers.
The `keys` and `values` pointers were written after the update, but
since the `num` is just an `int` in the embeded struct, it was written
before being updated. This lead to an out-of-sync state and later
to the crash.
The fix makes sure we write the struct *after* updating it.
This was because the `ob->runtime.geometry_set_eval` was populated
with the new `GreasePencilComponent` but
`GeometrySet::compute_boundbox_without_instances()` did not compute
the bounding box of the grease pencil geometry.
Thus the bounding box was not correctly set and the object not
correctly rendered.
Whenever `grow_array` in
`blender/source/blender/blenkernel/intern/grease_pencil.cc` was called,
it would not free the original array after relocating the data to the
newly allocated memory. This fixes the memory leak.
Adaptation of the operator `ACTION_OT_keyframe_insert` to take into account grease pencil channels.
Grease pencil keyframes can now be inserted in blank mode, or in additive mode (duplicate the current frame in the new keyframe).
Two API functions were added :
* `add_duplicate_drawings` which copies the data of a drawing to creates a duplicate, and
* `insert_duplicate_frame` which creates a duplicate frame of an existing one either by copy or instance.
The additive mode option is also added to the UI.
The Layer method `frame_key_at` previously private was set to public.
Pull Request: https://projects.blender.org/blender/blender/pulls/110649
Replace `BKE_mesh_face_flip_ex()` with `bke::mesh_flip_faces()`.
This gives better performance since it avoids custom data name
lookups for every face index, and processes data in a more cache
friendly way. Also remove the `CustomData_swap` API function
as mentioned in 09b6eac5c4.
Flipping 16 million faces, I observed a 3.25x speedup, from 760 to 230 ms.
Pull Request: https://projects.blender.org/blender/blender/pulls/110702
Caused by 91b27ab637, which caused the final position
arrays to be returned in more situations (in this case, when the final
result is a non-wrapper mesh). Instead, use the cage mesh, which
is more correct anyway-- it just wasn't always available before.
Each of the four algorithms is different, and not all of them will
parallelize linearly, but for large meshes these "flushing" operations
begin to become noticeable compared to other multithreaded code.
For example, flushing visibility to vertices and edges after a change
to faces became 3.75x faster, from 90 to 24 ms.
Also avoid duplicating selection interpolation logic, use the attribute
API instead.
The aim is to replace the `BKE_mesh_faces_flip` functions with
this newer C++ function using the attribute API. But that is must
be called by RNA, so move this to blenkernel to avoid a circular
dependency between the geometry module and RNA.
Instead of the default `add` and `remove` functions for the frames map,
use `add_new` and `remove_contained` for when it is known that a value
is or isn't in the map already. This should be slightly more efficient
(and just better practice overall).
Adds a user count to drawings to track how many frames use the drawing.
If the user count hits `0` the drawing should be deleted.
Also adds a function to delete a frame in a layer. This will
decrement the user count of the drawing and delete it if there are no
users left. This is consistent with the way GPv2 worked.
Pull Request: https://projects.blender.org/blender/blender/pulls/110579
Support configurations where there is no dedicated None display
and try to use Raw view of the default display.
This allows to preserve compatibility with old files and the new
upcoming AgX configuration.
Ref #110685
Pull Request: https://projects.blender.org/blender/blender/pulls/110581
Historically, the OCIO based color management implementation in Blender
had exceptions to treat specific configurations differently. It was a
compatibility with the legacy "No color management" option.
With time and more development in the area there are better ways of
achieving this goal, if needed.
This commit removes the named-based exception, which also solves confusion
about why certain similar configurations (from OCIO stand point) give
different results. As well as allows to create a cleaner plate for an
upcoming additions in the OCIO configuration such as AgX.
Quite simple and technical change which constant-folds the check for
whether the scene color management enabled or not with "true" value.
Ref #110685
Pull Request: https://projects.blender.org/blender/blender/pulls/110580
The issue was that `CustomData_swap` modifies all layers, but does not ensure
that the layers are actually mutable. This resulted in it modifying shared layers.
Now it ensures that the layers are mutable first (which copies the layers if they
are shared).
Longer term, it would be good to remove `CustomData_swap` since it's not a
good API performance wise, but that is outside of the scope of this patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/110678
Julian Eisel
Hans Goudey
Jacques Lucke
Lukas Tönne
Campbell Barton
Philipp Oeser
Iliya Katueshenock
Damien Picard
Nathan Vegdahl
Sybren A. Stüvel
Julian Eisel
Rawalanche
Iliya Katueshenock
Bastien Montagne
Pratik Borhade
Clément Foucault
Jesse Yurkovich
Harley Acheson
Amelie Fondevilla
Falk David
RedMser
Weizhen Huang
Aras Pranckevicius
Hoshinova
Sergey Sharybin
Colin Marmond
Alexander Gavrilov
Ray Molenkamp
Guillermo