Update VertexWeighEdit modifier Group Add / Remove threshold to be inclusive.
Additionally, add 3.6 backwards compatibility (4.0 versioning) to slightly offset Group Add / Remove threshold property value to make exclusive.
Pull Request: https://projects.blender.org/blender/blender/pulls/108286
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`.
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.
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
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
Also fix some incorrect usages of `N_` macro instead of `TIP_` one
(these error messages typically need to get translated explicitely, not
only marked for extraction).
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
The merging behavior of the Array, Mirror, Screw modifiers has changed
since 4369627e71.
Before, only the customdata of the destination vertex was kept. Source
vertices were completely removed.
With 4369627e71, all vertices in the merge group (whether source or
destination) now have their customdata interpolated.
But this can cause problems for example with the root vertex customdata
of the skin modifier, where if only one of the vertices of the group of
vertices has this flag, the resulting one will also have it.
This commit restores the behavior for the vertices customdata and does
not interpolate it if `do_mix_vert_data` is false.
Pull Request: https://projects.blender.org/blender/blender/pulls/109627
a8a454287a which moved edge creases out of `MEdge` only
retrieved the result data array if the mesh had vertex creases. Before
the processing always happened though. So process the result creases
if the input has edge creases too, and try to retrieve an existing array
instead of always adding a new one.
This utility counts the number of occurrences of each index in an array.
This is used for building mesh topology maps offsets, or for counting
the number of connected elements. Some users are geometry nodes,
the subdivision draw cache, and mesh to curve conversion.
See #109628
After some recent changes BLI_math_base got (indirectly) included
from DNA file, causing defines conflict in Cycles: Cycles wants the
default fast behavior of square root, and BLI color wants it to be
more preciese.
Proposed solution is to move the SSE block away from the math_base
closer to code which uses it. The initial intent was to make those
functions reusable, but for a long long time the color utilities
are the only users of those functions.
This change does not prevent the error from re-occurring in the
future if some code includes sse2neon and BLI color utilities, but
it makes such conflict situation much less likely to happen, for
now.
The downside of this change is that the code now need to include
BLI_simd.h explicitly to access BLI_HAVE_SSE2 instead of relying
on it being included indirectly with math headers. The mitigation
for this is to change semantic of the BLI_HAVE_SSE2: now it is
defined to 1 if SSE2 is supported and to 0 otherwise. This makes
it so the code needs to check if using `#if BLI_HAVE_SSE2` and
if the BLI_simd.h is not included it will generate warning when
using GCC or Clang.
This change in semantic is is something the current patches would
need to ensure is handled correctly.
Pull Request: https://projects.blender.org/blender/blender/pulls/109664
Replace `typedef struct X {} X;` with `struct X {};`
In some cases the first and last name didn't match although this
is rarely useful, even a typo in some cases, e.g. TrachPathPoint.
The simulation state used by simulation nodes is owned by the modifier. Since a
geometry nodes setup can contain an arbitrary number of simulations, the modifier
has a mapping from `SimulationZoneID` to `SimulationZoneState`. This patch changes
what is used as `SimulationZoneID`.
Previously, the `SimulationZoneID` contained a list of `bNode::identifier` that described
the path from the root node tree to the simulation output node. This works ok in many
cases, but also has a significant problem: The `SimulationZoneID` changes when moving
the simulation zone into or out of a node group. This implies that any of these operations
loses the mapping from zone to simulation state, invalidating the cache or even baked data.
The goal of this patch is to introduce a single-integer ID that identifies a (nested) simulation
zone and is stable even when grouping and un-grouping. The ID should be stable even if the
node group containing the (nested) simulation zone is in a separate linked .blend file and
that linked file is changed.
In the future, the same kind of ID can be used to store e.g. checkpoint/baked/frozen data
in the modifier.
To achieve the described goal, node trees can now store an arbitrary number of nested node
references (an array of `bNestedNodeRef`). Each nested node reference has an ID that is
unique within the current node tree. The node tree does not store the entire path to the
nested node. Instead it only know which group node the nested node is in, and what the
nested node ID of the node is within that group. Grouping and un-grouping operations
have to update the nested node references to keep the IDs stable. Importantly though,
these operations only have to care about the two node groups that are affected. IDs in
higher level node groups remain unchanged by design.
A consequence of this design is that every `bNodeTree` now has a `bNestedNodeRef`
for every (nested) simulation zone. Two instances of the same simulation zone (because
a node group is reused) are referenced by two separate `bNestedNodeRef`. This is
important to keep in mind, because it also means that this solution doesn't scale well if
we wanted to use it to keep stable references to *all* nested nodes. I can't think of a
solution that fulfills the described requirements but scales better with more nodes. For
that reason, this solution should only be used when we want to store data for each
referenced nested node at the top level (like we do for simulations).
This is not a replacement for `ViewerPath` which can store a path to data in a node tree
without changing the node tree. Also `ViewerPath` can contain information like the loop
iteration that should be viewed (#109164). `bNestedNodeRef` can't differentiate between
different iterations of a loop. This also means that simulations can't be used inside of a
loop (loops inside of a simulation work fine though).
When baking, the new stable ID is now written to disk, which means that baked data is
not invalidated by grouping/un-grouping operations. Backward compatibility for baked
data is provided, but only works as long as the simulation zone has not been moved to
a different node group yet. Forward compatibility for the baked data is not provided
(so older versions can't load the data baked with a newer version of Blender).
Pull Request: https://projects.blender.org/blender/blender/pulls/109444
Also see #103343.
There was one unusual complication due to `openvdb` here. The `BKE_volume.h`
header included `openvdb` but that would not link correctly in rna code. I'm not entirely
sure why any of the openvdb code is actually instantiated, may be an issue in the
`openvdb` headers. The solution is to create a new header that gives access to the
underlying `openvdb` data structure for a `Volume` geometry. This header can't be
included in rna for now, until the linking issues are resolved.
Pull Request: https://projects.blender.org/blender/blender/pulls/109508
This brings back the `Fill Volume` and `Exterior Bandwidth` inputs in
the Mesh to Volume node and modifier. Those existed in Blender 3.5 but
were removed in 700d168a5c because the way they were
implemented did not use the openvdb api in the right way.
While it's rare that people turned off the `Fill Volume` option, the
exterior bandwidth was used more and can have significant impact on
the result. Furthermore, there is no clear replacement for the
functionality.
Therefore, we decided to roll back the changes in 3.6 to avoid breaking
compatibility. We intend to keep the changes in 4.0 for now, but need
to work on a more clear short term replacement for the removed
functionality.
Pull Request: https://projects.blender.org/blender/blender/pulls/109297
This brings back the `Fill Volume` and `Exterior Bandwidth` inputs in
the Mesh to Volume node and modifier. Those existed in Blender 3.5 but
were removed in 700d168a5c because the way they were
implemented did not use the openvdb api in the right way.
While it's rare that people turned off the `Fill Volume` option, the
exterior bandwidth was used more and can have significant impact on
the result. Furthermore, there is no clear replacement for the
functionality.
Therefore, we decided to roll back the changes in 3.6 to avoid breaking
compatibility. We intend to keep the changes in 4.0 for now, but need
to work on a more clear short term replacement for the removed
functionality.
Pull Request: https://projects.blender.org/blender/blender/pulls/109297
This affected only vector and color inputs. The issue was that those were
expected to be stored as float-array properties. However, when setting them
from python using `modifier["Input_X"] = [1, 2, 3]` the array type becomes
either `int` or `double`, but not `float`. A workaround was to use
`modifier["Input_X"][:] = [1, 2, 3]` as this changes the property inplace.
Now `int` and `double` arrays are also understood by the modifier.
Pull Request: https://projects.blender.org/blender/blender/pulls/109203
This refactors how a geometry nodes node tree is converted to a lazy-function
graph. Previously, all nodes were inserted into a single graph. This was fine
because every node was evaluated at most once per node group evaluation.
However, loops (#108896) break this assumption since now nodes may be
evaluated multiple times and thus a single flat graph does not work anymore.
Now, a separate lazy-function is build for every zone which gives us much
more flexibility for what can happen in a zone. Right now, the change only
applies to simulation zones since that's the only kind of zone we have.
Technically, those zones could be inlined, but turning them into a separate
lazy-function also does not hurt and makes it possible to test this refactor
without implementing loops first. Also, having them as separate functions
might help in the future if we integrate a substep loop directly into the
simulation zone.
The most tricky part here is to just link everything up correctly, especially
with respect to deterministic anonymous attribute lifetimes. Fortunately,
correctness can be checked visually by looking at the generated graphs.
The logging/viewer system also had to be refactored a bit, because now there
can be multiple different `ComputeContext` in a single node tree. Each zone
is in a separate `ComputeContext`. To make it work, the `ViewerPath` system
now explicitly supports zones and drawing code will look up the right logger
for showing inspection data.
No functional changes are expected, except that the spreadsheet now shows
"Simulation Zone" in the context path if the viewer is in a simulation.
More consistently return geometry bounds with the `Bounds` type that
holds the min and max in one variable. This simplifies some code and
reduces the need to initialize separate min and max variables first.
Meshes now use the same `bounds_min_max()` function as curves and
point clouds, though the wrapper mesh isn't affected yet.
The motivation is to make some of the changes for #96968 simpler.
Move `GeometrySet` and `GeometryComponent` and subclasses
to the `blender::bke` namespace. This wasn't done earlier since
these were one of the first C++ classes used throughout Blender,
but now it is common.
Also remove the now-unnecessary C-header, since all users of
the geometry set header are now in C++.
Pull Request: https://projects.blender.org/blender/blender/pulls/109020
Duplicating will otherwise keep the same bake directory, which causes
a path conflict and requires manual fixing by users. Clearing the path
on copy makes it so the default path is generated on baking.
This does not change the path when doing internal copies, like
- Depsgraph "evaluated" object vs "original"
- Appending or linking objects
- Making a linked object local
Pull Request: https://projects.blender.org/blender/blender/pulls/109014
