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.
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.
