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
Sometimes the modifier has never been evaluated by an active depsgraph
before it is used for rendering. In this case, the baked data was never
loaded. Now also allow checking for baked data in a non-active depsgraph.
The locking that is in-place already should probably already be enough
to make this thread-safe but maybe that could be made more explicit.
With this the simulation cache pointer is copied over to the evaluated modifier.
This allows the original modifier to be removed without breaking the evaluated
modifier, which results in better decoupling. This can avoid issues when a
non-active depsgraph is evaluated in the background while the user is manipulating
the scene.
Also, it is now assumed that the simulation cache is always allocated even if
there is no simulation (similar to run-time data). This simplifies the code.
Pull Request: https://projects.blender.org/blender/blender/pulls/108976
Store subdivision surface creases in two new named float attributes:
- `crease_vert`
- `crease_edge`
This is similar to 2a56403cb0.
The attributes are naming conventions, so their data type and domain
aren't enforced, and may be interpolated when necessary. Editing tools
and the subdivision surface modifier use the hard-coded name. It might
be best if these were edited as generic attributes in the future, but
in the meantime using generic attributes helps.
The attributes are visible in the list, which is how they're now meant
to be removed. They are now interchangeable with any tool that works
with the generic attribute system-- even tools like vertex paint can
affect creases now.
This is a breaking change. Forward compatibility isn't preserved for
versions before 3.6, and the `crease` property in RNA is removed in
favor of making a smaller API surface area with just the attribute API.
`Mesh.vertex_creases` and `Mesh.edge_creases` now just return the
matching attribute if possible, and are now implemented in Python.
New functions `*ensure` and `*remove` also replace the operators to
add and remove the layers for Python.
A few extrude node test files have to be updated because of different
(now generic) attribute interpolation behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/108089
For node group operators (#101778), it helps to reuse the existing
geometry nodes execution. This commit adds a new moves most
of the geometry computation to the nodes module and gives the
modifier (and in the future the operator) a callback to setup the
execution context.
Pull Request: https://projects.blender.org/blender/blender/pulls/108482
* Provide render data, node tree and color management directly instead
of going through scene, as these may be modified by the render pipeline.
Also better for cached texture hits this way.
* Change legacy pass type to pass name.
* Skip file output node when not doing final render.
* Gracefully handle incomplete render results.
Pull Request: https://projects.blender.org/blender/blender/pulls/108629
