The node add menu contains assets. The position of an asset in the menu
is determined by the catalog it's in. Submenus are generated automatically.
This works by having a context dependent menu (`NODE_MT_node_add_catalog_assets`).
The current catalog path is passed in as context. If the menu has submenus,
the sub-catalog paths are passed as context into those.
This generally works fine when using the menu. However, menu-search (F3)
does not support context dependent menus yet, so those menu entries are
just skipped. With this patch, the previously skipped context dependent menu
entries are also taken into account.
Note, when opening the search directly after opening Blender, the assets might
still be loading and therefor don't show up in the search.
Pull Request: https://projects.blender.org/blender/blender/pulls/111752
Generally the context store is owned by `uiBlock`. Other pointers
to the store (in `bContext` and other operator data) shouldn't change
it, so those variables are now const. One exception is the pointer in
`uiLayout`, but that has a clearly short lifetime, so that's okay.
Remove the need for `CTX_store_copy` and `CTX_store_free` by using
C++ copy constructors, unique pointers, and `std::optional`. A few types
are made non-trivial to support this.
Essentially calls `BKE_lib_override_library_resync`, with either to
current ID as resync root for a partial resync, or the actual hierarchy
root for a complete resync of the whole hierarchy.
Goals of the refactor:
* Internal support for baking individual simulation zones (not exposed in the UI yet).
* More well-defined access to simulation data in geometry nodes. Especially, it
should be more obvious where data is modified. A similar approach should also
work for the Bake node.
Previously, there were a bunch of simulation specific properties in `GeoNodesModifierData`
and then the simulation input and output nodes would have to figure out what to do with that
data. Now, there is a new `GeoNodesSimulationParams` which controls the behavior of
simulation zones. Contrary to before, different simulation zones can now be handled
independently, even if that is not really used yet. `GeoNodesSimulationParams` has to be
subclassed by a user of the geometry nodes API. The subclass controls what each simulation
input and output node does. This some of the logic that was part of the node before, into
the modifier.
The way we store simulation data is "transposed". Previously, we stored zone data per
frame, but now we store frame data per zone. This allows different zones to be more
independent. Consequently, the way the simulation cache is accessed changed. I kept
things simpler for now, avoiding many of the methods we had before, and directly
accessing the data more often which is often simple enough. This change also makes
it theoretically possible to store baked data for separate zones independently.
A downside of this is, that existing baked data can't be read anymore. We don't really
have compatibility guarantees for this format yet, so it's ok. Users will have to bake again.
The bake folder for the modifier now contains an extra subfolder for every zone.
Drawing the cached/baked frames in the timeline is less straight forward now. Currently,
it just draws the state of one of the zones, which usually is identical to that of all other
zones. This will change in the future though, and then the timeline drawing also needs
some new UI work.
Pull Request: https://projects.blender.org/blender/blender/pulls/111623
Bone collection added by default along with the armature is not marked
as active. Visually this looks active but actually it's not (hover over the
properties like remove/move)
Also, when a new collection is added, mark that collection active.
Pull Request: https://projects.blender.org/blender/blender/pulls/111733
Add three cached topology maps to `Mesh`, to avoid computations when
mesh data isn't changed. Choosing the right maps to cache is a bit
arbitrary, but generally we have to start somewhere. The limiting
factor is memory usage (all the new caches combined have a
comparable footprint to a UV map).
For now, the caches added are:
- Vertex to face corner
- Vertex to face
- Face corner to face
These caches are used in quite a few places already;
- Face corner normal calculation
- UV value merging
- Setting sharp edges from face angles
- Data transfer modifier
- Voxel remesh attribute remapping
- Sculpt mode painting
- Sculpt mode normal calculation
- Vertex paint mode
- Split edges geometry node
- Mesh topology geometry nodes
Caching topology maps means they don't have to be rebuilt every time
they're used. Meshes copied but without topology changes can share
the cache, further reducing re-computations. For example, FPS with a
large mesh using the "Corners of Vertex" node went from 1.8 to 2.3.
Entering sculpt mode is slightly faster too.
There is some obvious work for future commits:
- Use caches in attribute domain interpolation
- More multithreading of second phase of map building
- Update/build caches eagerly in some geometry nodes
Pull Request: https://projects.blender.org/blender/blender/pulls/107816
The sound equalizer is using the Audaspace FFT Convolver.
The blender part creates an array of descriptions of power per "band"
and orders the creation of Equalizer (ISound) in the Audaspace.
Modifier can be created on sound strips. It lets you define
amplification or attenuation over frequency range from 30Hz to 20 kHz.
The power is limited to -30 db - 30 db. This is done using curve
mapping widget.
Co-authored-by: menda <alguien@aqui.es>
Co-authored-by: Richard Antalik <richardantalik@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/105613
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.
