Make it harder to retrieve a mutable attribute from const a const mesh,
and use the attribute search function to check multiple domains and
colors at once.
This adds support for running a set of nodes repeatedly. The number
of iterations can be controlled dynamically as an input of the repeat
zone. The repeat zone can be added in via the search or from the
Add > Utilities menu.
The main use case is to replace long repetitive node chains with a more
flexible alternative. Technically, repeat zones can also be used for
many other use cases. However, due to their serial nature, performance
is very sub-optimal when they are used to solve problems that could
be processed in parallel. Better solutions for such use cases will
be worked on separately.
Repeat zones are similar to simulation zones. The major difference is
that they have no concept of time and are always evaluated entirely in
the current frame, while in simulations only a single iteration is
evaluated per frame.
Stopping the repetition early using a dynamic condition is not yet
supported. "Break" functionality can be implemented manually using
Switch nodes in the loop for now. It's likely that this functionality
will be built into the repeat zone in the future.
For now, things are kept more simple.
Remaining Todos after this first version:
* Improve socket inspection and viewer node support. Currently, only
the first iteration is taken into account for socket inspection
and the viewer.
* Make loop evaluation more lazy. Currently, the evaluation is eager,
meaning that it evaluates some nodes even though their output may not
be required.
Pull Request: https://projects.blender.org/blender/blender/pulls/109164
This data-block was originally added in eb4e3bbe68.
However, that original plan wasn't fully implemented, with simulations
now integrated with geometry nodes and modifiers instead of a separate
data-block. We kept the data-block around anyway since we have the
loose plan of using a similar data-block to make global simulations
connected between multiple objects. But it may be a while before we
implement that, and in the meantime having this just causes confusion.
The simulation data-block file isn't used currently, and is unrelated to
the current simulation caches. It would also be reasonable to declare
the function in MOD_nodes.hh, but I went for keeping it together
with the other more public simulation cache code.
Pull Request: https://projects.blender.org/blender/blender/pulls/109967
Name collisions can become a big issue in liboverrides when production
files gets messy (weird overrides duplicates, bad resync with heavily
changing assets, etc.).
This commit tries to alleviate a bit the problem by generating 'more
unique' names for liboverrides, when an exact match with the reference
is not possible.
So by default, in most common case, the liboverride ID will still have
the exact same name as its linked reference.
If this is not possible, then the new liboverride ID will get a name
which is unique to within the whole current Main (for its ID type). In
particular, this ensure that new override IDs are either named exactly
as their references, or have a name which is not used by any other
reference (linked) IDs.
Note that this is not a perfect solution, since changes in library data
can lead to name collisions later on. However, it should greatly reduce
the frequency of such problems.
This new namemap allows to generate new ID names which are unique in
current Main (for a given ID type), regardless of the library they
belong to.
This new feature will be used by library override to try to reduce name
collisions with its linked reference IDs when more than one override
exists. It is not intended to be used for general ID naming.
When the parent ID pointer of an object is a 'system override' (i.e.
matches hierarchy-wise the parent of the linked reference object, or
actually use the same linked object), also clear potential liboverrides
for the other related parenting properties.
This is especially critical for the parent inverse matrix, otherwise if
it ever gets out of sync, in case of re-parenting in the lib data, the
offset would remain and move the liboverride child object into random
places.
NOTE: This may break some very specific workflows where users would rely
on actually overridden parent invert matrix. Not much to be done here,
there is currently no way to support both cases. This is not expected to
be a common use case.
We need setters and getters for these two very commonly accessed attributes of grease pencil.
The code is based on the implementation of `CurvesGeometry::positions()` and `CurvesGeometry::positions_for_write()`.
Co-authored-by: Falk David <falk@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/109733
When we don't need to preserve a persistent cache, we can use
the geometry from the last frame directly rather than copying it.
Though implicit lets us avoid copying large data arrays when they
aren't changed, this can still give a large improvement for something
like particle simulation where the majority of the data was copied
every frame.
Pull Request: https://projects.blender.org/blender/blender/pulls/109742
Selecting a rigid body world collection is supposed to set up rigid
bodies for all of its mesh members (if they are not rigid bodies
already), expected result would be just the same as if `Object` > `Rigid
Body` > `Add ...` was used.
Doing it via just the world collection had the following issues though:
- calculating mass would crash on such a freshly created rigid body
objects (be1b32e4e4 falsely assumed `ob->rigidbody_object` is always
present on evaluated objects -- without tagging for depsgraph updates
this is not the case though)
- rigid body simulation would not work even on these freshly created
rigid body objects
Now tag bmain relations and object transforms for update to make both of
these work (following code in `BKE_rigidbody_add_object` that is used
when adding these through `Object` > `Rigid Body` > `Add ...`)
Pull Request: https://projects.blender.org/blender/blender/pulls/109961
The `BKE_bvhtree_from_pointcloud_get` function have requirements for
input point cloud argument and initialization of `BVHTreeFromPointCloud`
can be skipped. Due to `BVHTreeFromPointCloud` is not initialized by
default constructor, it can contains garbage data. To check if tree is
initialized field of `BVHTreeFromPointCloud`, return argument shouldn't
be ignored. `[[nodiscard]]` attributes is added.
Pull Request: https://projects.blender.org/blender/blender/pulls/109892
Doing so avoids having duplicated logic for working with pixel
data which is being passed throughout the render pipeline.
Notable changes:
- ImBug can now store GPU texture.
This is not very finished part of the API, which will be
worked further to support tiling for very-high-res images.
- Implicit sharing is removed from the image buffer, as it is
no longer needed.
There should be no functional changes on user level with this
change.
Ref #108618
Pull Request: https://projects.blender.org/blender/blender/pulls/109788
The "No Cache" simulation nodes option effectively changes the cache
to work in a "realtime mode" where there are only two states, the
current and previous frame. Whenever the current frame doesn't
increase, the previous state should reset. This didn't happen
properly, and it was hard to verify because the code was shared
with the regular "cache on" mode.
Instead, separate the caching more in the code, using a different
struct to store the two "realtime" states. Also clarify that we
don't support animation of the "No Cache" option by disabling
support for that in RNA.
Pull Request: https://projects.blender.org/blender/blender/pulls/109741
There's quite a few libraries that depend on dna_type_offsets.h
but had gotten to it by just adding the folder that contains it to
their includes INC section without declaring a dependency to
bf_dna in the LIB section.
which occasionally lead to the lib building before bf_dna and the
header being missing, while this generally gets fixed in CMake by
adding bf_dna to the LIB section of the lib, however until last
week all libraries in the LIB section were linked as INTERFACE so
adding it in there did not resolve the build issue.
To make things still build, we sprinkled add_dependencies wherever
we needed it to force a build order.
This diff :
Declares public include folders for the bf_dna target so there's
no more fudging the INC section required to get to them.
Removes all dna related paths from the INC section for all
libraries.
Adds an alias target bf:dna to signify it has been updated to
modern cmake
Declares a dependency on bf::dna for all libraries that require it
Removes (almost) all calls to add_dependencies for bf_dna
Future work:
Because of the manual dependency management that was done, there is
now some "clutter" with libs depending on bf_dna that realistically
don't. Example bf_intern_opencolorio itself has no dependency on
bf_dna at all, doesn't need it, doesn't use it. However the
dna include folder had been added to it in the past since bf_blenlib
uses dna headers in some of its public headers and
bf_intern_opencolorio does use those blenlib headers.
Given bf_blenlib now correctly declares the dependency on bf_dna
as public bf_intern_opencolorio will get the dna header directory
automatically from CMake, hence some cleanup could be done for
bf_intern_opencolorio
Because 99% of the changes in this diff have been automated, this diff
does not seek to address these issues as there is no easy way to
determine why a certain dependency is in place. A developer will have
to make a pass a this at some later point in time. As I'd rather not
mix automated and manual labour.
There are a few libraries that could not be automatically processed
(ie bf_blendthumb) that also will need this manual look-over.
Pull Request: https://projects.blender.org/blender/blender/pulls/109835
Clay strips was using it's own brush local matrix,
which wasn't quite compatible with texture matrices.
This could lead to brush textures not lining up with
the stroke dabs.
There was also a bug where the stroke was starting
20 pixels into the stroke, which is much higher than
necassary to derive the initial rake angle.
Notes:
* The clay strips brush now uses SCULPT_cube_tip_init
to calculate the local brush matrix.
* SCULPT_cube_tip_init now accepts custom brush location
and radius arguments.
* The mouse sample preroll used to calculate initial brush
rotation angle is now smaller than the update interval.
* Clay strips now supports tip_scale_x, which has also
been added to DNA defaults.
* Renamed BKE_pbvh_raycast_project_ray_root to
BKE_pbvh_clip_ray_ortho for greater
clarity.
* BKE_pbvh_clip_ray_ortho no longer strictly clips
within the input ray interval. This is not necassary
for orthographic views and was too prone to floating
point error. The function is only called to clip
brush rays for orthographic views so this is acceptable.
Minor tweaks to the API to support drag & drop management in the layer tree UI.
These changes were needed for #109826:
- Add `TreeNode.parent_group()`
- Add `LayerGroup.as_node()`
- Use `TreeNode` instead of `Layer` whenever a link is needed to link or unlink a layer.
Pull Request: https://projects.blender.org/blender/blender/pulls/109824
This introduces an alias target `bf::intern::atomic` for
`bf_intern_atomic`. This has the following benefits:
- Any target name with `::` in it will be recognized as an actual
target by cmake, rather than a library name it may not know about.
and will be validated by cmake to exist. Which means if you make
a typo in the LIB section, CMake will error out telling you it
doesn't know about this specific target rather than passing it on
to the build system, where you'll either get build or linker errors
because of said typo.
- Given there is quite a cleanup still to do in the build system,
it won't always be obvious which targets have been updated to
modern targets and which still need to be done. Having a namespaced
target name is a good indicator there.
Pull Request: https://projects.blender.org/blender/blender/pulls/109784
Instead of keeping track of a local array of positions in the modifier
stack itself, use the existing edit mode SoA "edit cache" which already
contains a contiguous array of positions. Combined with positions as a
generic attribute, this means the state is contained just in the mesh
(and the geometry set) making the code much easier to follow.
To do this we make more use of the mesh wrapper system, where we can
pass a `Mesh` that's actually stored with a `BMesh` and the extra
cached array of positions. This also resolves some confusion-- it was
weird to have the mesh wrapper system for this purpose but not use it.
Since we always created a wrapped mesh in edit mode, there's no need
for `MOD_deform_mesh_eval_get` at all anymore. That function was quite
confusing with "eval" in its name when it really retrieved the original
mesh.
Many deform modifiers had placeholder edit mode evaluation functions.
Since these didn't do anything and since the priority is node-based
deformation now, I removed these. The case is documented more in the
modifier type struct callbacks.
Pull Request: https://projects.blender.org/blender/blender/pulls/108637
