Since a year and a half ago we've been switching to a new way to
represent what sockets a node should have called "declarations"
that's easier to use, clearer, and more flexible for upcoming
features like dynamic socket counts or generic type sockets.
All builtin nodes with a static set of sockets have switched, but one
missing area has been group nodes and group input/output nodes. These
nodes have **dynamic** declarations which change based on their
properties or the group they're inside of. This patch addresses that,
in preparation for using the same dynamic declaration feature for
simulation nodes.
Generally there shouldn't be user-visible differences, but one benefit
is that user-created socket descriptions are now visible directly in
the node editor for group nodes and group input/output nodes.
The commit contains a few changes:
- Add a node type callback for building dynamic declarations with
different arguments
- Add an `Extend` socket declaration for the "virtual" sockets used
for connecting new links
- A similar `Custom` socket declaration is used for addon-defined socket
- Simplify the node update loop to use the declaration to build update
sockets
- Replace the "group update" functions with the declaration building
- Move the node group input/output link creation to link drag operator
- Make the field status part of group node declarations
(not for group input/output nodes though)
- Some fixes for declarations to make them update and build properly
Differential Revision: https://developer.blender.org/D16850
- `Interpolate Domain` -> `Evaluate on Domain`
- `Field at Index` -> `Evaluate at Index`
These names, discussed in recent geometry nodes submodule meetings,
describe actions rather than nouns, which is generally how nodes are
supposed to be named. The names are consistent, which is helpful
because they're similar conceptually. They also don't require knowledge
of the field concept, which we generally try to keep out of the UI in
favor of more beginner-friendly concepts.
We hope to add the ability to search for nodes with multiple
names for 3.5, so the old names can still have search items.
Since internal links are only runtime data, we have the flexibility to
allocating every link individually. Instead we can store links directly
in the node runtime vector. This allows avoiding many small allocations
when copying and changing node trees.
In the future we could use a smaller type like a pair of sockets
instead of `bNodeLink` to save memory.
Differential Revision: https://developer.blender.org/D16960
This moves all multi-function related code in the `functions` module
into a new `multi_function` namespace. This is similar to how there
is a `lazy_function` namespace.
The main benefit of this is that many types names that were prefixed
with `MF` (for "multi function") can be simplified.
There is also a common shorthand for the `multi_function` namespace: `mf`.
This is also similar to lazy-functions where the shortened namespace
is called `lf`.
- Move from blenkernel to the node editor, the only place it was used
- Use two vectors instead of ListBase
- Remove define for validating the clipboard, which shouldn't be skipped
- Comment formatting, other small cleanups to whitespace
Differential Revision: https://developer.blender.org/D16880
Add `bNode::index()` to allow accessing node indices directly without
manually de-referencing the runtime struct. Also adds some asserts to
make sure the access is valid and to check the nodes runtime vector.
Eagerly maintain the node's index in the tree so it can be accessed
without relying on the topology cache.
Differential Revision: https://developer.blender.org/D16683
The Blur Attribute node mixes values of neighboring elements in meshes and curves.
Currently it supports points, edges and faces on meshes and points on curves.
In theory, support for face corners could be added, but useful semantics are not
obvious yet.
The node calculates a weighted average of each element with its neighbors (based
on curve/mesh topology). The weight of the element itself is always 1, and the weight
of the neighbor elements is controlled by the weight input socket. In the future,
more options for how different elements are weight can be added (e.g. smoothing
groups and selection).
The node can perform multiple blurring iterations to achieve a blurrier result.
Generally, it is better to do multiple iterations in one node instead of using
multiple blur nodes because it has better performance in the current implementation.
We use the term "Blur" (instead of "Smooth") because smoothing is generally more
related to removing roughness from surfaces. When viewing the result of the
Blur Attribute node in the viewport, it looks like an image is blurred. While the
node can also be used to smooth surfaces, other/better algorithms exists for that
purpose (which e.g. don't reduce the volume of the mesh to zero with too many
iterations).
Differential Revision: https://developer.blender.org/D13952
You shouldn't be able to retrieve a mutable node from a const node tree
or a mutable socket from a const node. Use const_cast in one place in
order to correct this without duplicating the function, which is still
awkward in the C-API.
In a few places, nodes were added without updating the Identifiers and
vector. In other places nodes we removed without removing from and
rebuilding the vector. This is solved in a few ways. First I exposed
a function to rebuild the vector from scratch, and added unique ID
finding to a few places.
The changes to node group building and separating are more involved,
mostly because it was hard to see the correct behavior without some
refactoring. Now `VectorSet` is used to store nodes involved in the
operation. Some things are handled more simply with the topology
cache and by passing a span of nodes.
This patch adds an integer identifier to nodes that doesn't change when
the node name changes. This identifier can be used by different systems
to reference a node. This may be important to store caches and simulation
states per node, because otherwise those would always be invalidated
when a node name changes.
Additionally, this kind of identifier could make some things more efficient,
because with it an integer is enough to identify a node and one does not
have to store the node name.
I observed a 10% improvement in evaluation time in a file with an extreme
number of simple math nodes, due to reduced logging overhead-- from
0.226s to 0.205s.
Differential Revision: https://developer.blender.org/D15775
This cache was never written to, only "copied" between sockets in one
case, it dates back at least a decade. It doesn't make sense to store
caches on node trees directly anyway, since they can be used in
multiple places.
Change name to make navigation easier for beginner users. This should
more clearly hint at the use of this node to change the full geometry,
and not work with fields, and makes the name more consistent.
Differential Revision: https://developer.blender.org/D16396
The main goal here is to move towards more self contained node
definitions. Previously, one would have to change `blenkernel` to
add a new node which is not necessary anymore. There is no need
for all these register functions to "leak out" of the nodes module.
Differential Revision: https://developer.blender.org/D16612
This is not used for anything in practice currently. The original intention
was probably to generate different socket subtypes, but that is solved
differently now (e.g. using `NodeSocketFloatDistance`). It's possible
that an addon tried to use this but it's rather unlikely.
Differential Revision: https://developer.blender.org/D13188
This patch warns the user that the compositor setup is not fully
supported when an unsupported node is used. The warning is displayed as
an engine warning overlay and in the node header itself.
See T102353.
Differential Revision: https://developer.blender.org/D16508
Reviewed By: Clement Foucault
This patch implements the Track Position node for the realtime
compositor.
Differential Revision: https://developer.blender.org/D16387
Reviewed By: Clement Foucault
The node level was an indication of how deep the node was in the tree.
It was only used for detecting link cycles. Now that the node topology
cache from 25e307d725 exists, this calculation can be removed
completely.
The level calculation was quadratic and very slow on larger node trees.
In the mouse house file with a few thousand nodes, it took 23ms on
every single update. Another benefit is storing slightly less runtime
data, though this was only 2 bytes per node.
Differential Revision: https://developer.blender.org/D16566
Instead of generating a dependency sorted node list whenever evaluating
texture or EEVEE/viewport shader nodes, use the existing sorted array
from the topology cache. This may be more efficient because the
algorithm isn't quadratic. It's also the second-to-last place to
use `node.runtime->level`, which can be removed soon.
Differential Revision: https://developer.blender.org/D16565
* This patch just moves runtime data to the runtime struct to cleanup
the dna struct. Arguably, some of this data should not even be there
because it's very use case specific. This can be cleaned up separately.
* `miniwidth` was removed completely, because it was not used anywhere.
The corresponding rna property `width_hidden` is kept to avoid
script breakage, but does not do anything (e.g. node wrangler sets it).
* Since rna is in C, some helper functions where added to access the
C++ runtime data from rna.
* This size of `bNode` decreases from 432 to 368 bytes.
This allows for optimizations because one does not have to iterate
over all nodes anymore to find all nodes within a frame.
Differential Revision: https://developer.blender.org/D16106
This commit adds a new "Image Info" node to retrieve various
information from an image like its width, height, and whether
it has an alpha channel. It is also possible to retrieve the FPS
and frame count of video files.
Differential Revision: https://developer.blender.org/D15042
This was caused by rBc39eb09ae587e1d9. The optimization broke the case
when the socket is not in the provided node tree. Now there are two separate
functions, one that always does the slow check to see of the socket is really
in the node tree and a potentially much faster version when we are sure
that the socket is in the tree.
Use the node topology cache and avoid modifying the node tree
in a non-threadsafe way to improve the predictability of using
the helper function. Replaces the implementation from
e0d4047136.
**Problem**
Currently multiple input sockets are created when a new node group is
made from selected nodes. Some of these are linked from the same source.
It is not convenient to sort out and remove multiple input sockets that
represent the same input. These inputs usually have meaningless names
like 'value', 'x', etc.
**Solution**
Create common input sockets for each link starting from the same input.
Move links inside the new group's node tree and reroute it to connect
the common input socket to the original nodes. This is done by building
up a mapping between the incoming link sources to the input interfaces
created for them. The input interfaces are reused by the rest of the
links having the same source.
This patch also changes the way the input sockets get their names.
Output socket names of the group nodes usually are specific and are
given consciously. Use the output socket names from group nodes instead
of the inputs where the links point to.
Differential Revision: https://developer.blender.org/D15802
Rename the node to "Offset Point in Curve"
Since this was committed, more mesh and curve topology nodes have been
committed with a different naming scheme (482d431bb6). Change
the name of this node to match "Offset Corner in Face". Because the
node was only added recently, it's a full rename, including the ID,
so forward compatibility is broken.
This node allows for curves to have their evaluated normal mode changed
between MINIMUM_TWIST and Z_UP. A selection input allows for choosing
which spline in the curves object will be affected.
Differential Revision: D16118
This node allows sampling an attribute on a mesh surface based
on a UV coordinate. Internally, this has to do a "reverse uv lookup",
i.e. the node has to find the polygon that corresponds to the uv
coordinate. Therefore, the uv map of the mesh should not have
overlapping faces.
Differential Revision: https://developer.blender.org/D15440
This patch contains an initial set of nodes to access basic
mesh topology information, as explored in T100020.
The nodes allow six direct topology mappings for meshes:
- **Corner -> Face** The face a corner is in, the index in the face
- **Vertex -> Edge** Choose an edge attached to the vertex
- **Vertex -> Corner** Choose a corner attached to the vertex
- **Corner -> Edge** The next and previous edge at each face corner
- **Corner -> Vertex** The vertex associated with a corner
- **Corner -> Corner** Offset a corner index within a face
And two new topology mappings for curves:
- **Curve -> Points** Choose a point within a curve
- **Point -> Curve** The curve a point is in, the index in the curve
The idea is that some of the 16 possible mesh mappings are more
important, and that this is a useful set of nodes to start exploring
this area. For mappings with an arbitrary number of connections, we
must sort them and use an index to choose a single element, because
geometry nodes does not support list fields. Note that the sort
index has repeating behavior as it goes over the "Total" number of
connections, and negative sort indices choose from the end.
Currently which of the "start" elements is used is determined by the
field context, so the "Field at Index" and "Interpolate Domain" nodes
will be quite important. Also, currently the "Sort Index" inputs are
clamped to the number of connections.
One important feature that isn't implemented here is using the winding
order for the output elements. This can be a separate mode for some
of these nodes. It will be optional because of the performance impact.
There are several todos for separate commits after this:
- Rename "Control Point Neighbors" to be consistent with this naming
- Version away the "Vertex Neighbors" node which is fully redundant now
- Implement a special case for when no weights are used for performance
- De-duplicating some of the sorting logic between the nodes
- Improve performance and memory use of topology mappings
- Look into caching some of the mappings on meshes
Differential Revision: https://developer.blender.org/D16029
This node allows access to the indices of neighboring control points
within a curve via an offset. This includes taking into consideration
curves that are cyclic.
Differential Revision: D13373
This patch replaces the existing transfer attribute node with three
nodes, "Sample Nearest Surface", "Sample Index", and "Sample Nearest".
This follows the design in T100010, allowing for new nodes like UV
sampling in the future. There is versioning so the new nodes replace
the old ones and are relinked as necessary.
The "Sample Nearest Surface" node is meant for the more complex
sampling algorithms that only work on meshes and interpolate
values inside of faces.
The new "Sample Index" just retrieves attributes from a geometry at
specific indices. It doesn't have implicit behavior like the old
transfer mode, which should make it more predictable. In order to not
change the behavior from existing files, the node has a has a "Clamp",
which is off by default for consistency with the "Field at Index" node.
The "Sample Nearest" node returns the index of the nearest element
on a geometry. It can be combined with the "Sample Index" node for
the same functionality as the old transfer node. This node can support
curves in the future.
Backwards compatibility is handled by versioning, but old versions can
not understand these nodes. The warning from 680fa8a523 should make
this explicit in 3.3 and earlier.
Differential Revision: https://developer.blender.org/D15909
From the nodes' description: "Retrieve the object that contains
the geometry nodes modifier currently being executed". This was
discussed in the most recent geometry nodes module meeting.
Because the node allows you to retrieve the position of the modifier
object, it has to add a depsgraph relation to object transform.
Expect that modifiers will be reevaluated when moving the object.
In the future, better static analysis of node trees could make this
check smarter.
Differential Revision: https://developer.blender.org/D16037
This commit adds a node to distribute points inside of volume grids.
The "Random" mode usese OpenVDB's "point scatter" implementation, and
there is also a "Grid" mode for uniform distributions. Both methods
operate on all of the float grids in the volume, using every voxel with
a value higher than the threshold. The random method is not stable as
the input volume deforms.
Based on a patch by Angus Stanton (@abstanton), which was based on a
patch by Kenzie (@kenziemac130).
Differential Revision: https://developer.blender.org/D15375
With the recent addition of the UV unwrapping node, there is a need to
be able to create seams easily. This node does that by outputting a
selection of the boundaries between different input face sets. In the
context of UV mapping, one inputs the "patches" you want, and the node
gives you the seams needed to make those patches.
Differential Revision: https://developer.blender.org/D15423
This patch implements the Scale node for the realtime compositor.
Differential Revision: https://developer.blender.org/D15758
Reviewed By: Clement Foucault
Add a dedicated `owner_id` pointer to ID types that can be embedded
(Collections and NodeTrees), and modify slightly come code to make
handling those more safe and consistent.
This implements first part of T69169.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D15838
The previous implementation iterated over all links multiple times
recursively. Instead, use the node tree topology cache, only iterate
over all links once, and use a stack to propagate the mute upsteam
and downstream.
