This turns the embedded group into a pointer.
Note: Older files will not load the grease pencil v3 object properly after this.
The objects will not have any layers in them.
Pull Request: https://projects.blender.org/blender/blender/pulls/110007
Code in charge of fixing invalid liboverride hierarchy roots would be
too agressive in re-assigning new root in replacement of old one. When
the invalid initial case was a 'low-level' type of ID (like a nodetree
e.g.), it could 'contaminate' many valid data (objects etc.) and force
them into its own local hierarchy.
This commit fixes the issue by storing all 'processed as valid' IDs into
a set, and ensuring that once an ID has been put into that set, its
hierarchy root is not changed anymore.
in other words, it changes the old behavior of 'last encountered hierarchy
wins' to 'first encountered hierarchy wins'. Since higher-level types of
IDs (like collections or objects) are processed first, this is the
most logical behavior too.
In some cases we store temporary region data that doesn't require
freeing. Code shouldn't expect the data pointer to be unset in this
case, so don't print an error.
Move the node previews to the overlay region, atop each node.
It allows nodes to keep the same size when the preview is toggled,
which is more convenient for large nodes and large nodetrees.
The preview has to be drawn from `node_draw_extra_info_panel`
because there could be overlapping between info text and the preview.
When the node is out of the view, it also has to make sure that the
preview is also out of the view before exiting the draw function.
Pull Request: https://projects.blender.org/blender/blender/pulls/108001
This formats code that is disabled using `#if 0`. Formatting was achieved
by temporarily changing `#if 0` to `#if 1 /*something*/`, then formatting,
and then changing it back to `#if 0`.
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.
