Currently, a node either supports lazyness during execution (like the Switch
node), or it doesn't. If it does support lazyness, then every input is computed
lazily. However, usually not all inputs actually have to be computed lazily.
E.g. the boolean switch input is always required, while the other inputs
should be computed lazily.
Better support for such sockets can avoid unnecessary round trips through
the node execution function.
Previously, the values passed to a multi-input socket were stored
in the order that they arrived in. Then, when the values are accessed,
they are sorted depending on the link order.
Now, the ordering is determined in the beginning before execution starts.
Every value is assigned to the right index directly, avoiding the sort
in the end. This makes the ordering more explicit.
The type conversions do not depend on other files in the nodes
module. Furthermore we want to use the conversions in the
geometry module without creating a dependency to the
nodes module there.
When a node is executed, it usually schedules other nodes.
Right now, those newly scheduled nodes are added to a
task pool so that another thread can start working on them
immediatly.
However, that leads to the situation where sometimes each
node in a simple chain is executed by another thread. That
leads to additional threading overhead and reduced cache
efficiency (for caches that are not shared between cores).
Now, when a node is executed and schedules other nodes,
the first of those newly scheduled nodes will always be
executed on the same thread once the current node is done.
If it schedules more than one other node, those will be
added to the task pool as before.
The speedup achieved by this is hard to measure. I found it
to be a couple percent faster in some extreme cases, not
much to get excited about. It's nice though that the number
of tasks added to the task pool is commonly reduced by a
factor of 4 or 5.
This is only meant to be used for development purposes for now,
not to show warnings to the user.
Differential Revision: https://developer.blender.org/D13348
Previously, there were a couple of cases where nodes were scheduled when
that was not really necessary. This change doesn't seem to have a big impact
on performance, but simplifies the code a bit.
Adds a new overlay called "Timings" to the Geometry Node editor.
This shows the node execution time in milliseconds above the node.
For group nodes and frames, the total time for all nodes inside
(recursively) is shown. Group output node shows the node tree total.
The code is prepared for easily adding new rows of information
to the box above the node in the future.
Differential Revision: https://developer.blender.org/D13256
Currently the geometry nodes evaluator always stores a field for every
type that supports it, even if it is just a single value. This results in a lot
of overhead when there are many sockets that just contain a single
value, which is often the case.
This introduces a new `ValueOrField<T>` type that is used by the geometry
nodes evaluator. Now a field will only be created when it is actually
necessary. See D13307 for more details. In extrem cases this can speed
up the evaluation 2-3x (those cases are probably never hit in practice
though, but it's good to get rid of unnecessary overhead nevertheless).
Differential Revision: https://developer.blender.org/D13307
The geometry node evaluator now has access to the entire socket path
from the node that produces a value to the node that uses it. This allows
the evaluator to make decisions about at which points in the path the
value should be converted. Multiple conversions may be necessary under
some circumstances with nested node groups.
Differential Revision: https://developer.blender.org/D13034
The leak happened when two things were true:
* Inside of a node group a socket is linked to a Group Input that has
a different type.
* The corresponding input on the parent Group node is not linked.
The conversion happened correctly, but the original value wasn't
destructed.
There were some issues when multiple inputs of the same node
were forced to be computed (e.g. for the spreadsheet), but none
of the node outputs (if existant) were used. Essentially the node
was marked as "finished" too early in this case.
This fix is necessary for the improved viewer node (T92167).
In order to address feedback that the "Stable ID" was not easy enough
to use, remove the "Stable ID" output from the distribution node and
the input from the instance on points node. Instead, the nodes write
or read a builtin named attribute called `id`. In the future we may
add more attributes like `edge_id` and `face_id`.
The downside is that more behavior is invisible, which is les
expected now that most attributes are passed around with node links.
This behavior will have to be explained in the manual.
The random value node's "ID" input that had an implicit index input
is converted to a special implicit input that uses the `id` attribute
if possible, but otherwise defaults to the index. There is no way to
tell in the UI which it uses, except by knowing that rule and checking
in the spreadsheet for the id attribute.
Because it isn't always possible to create stable randomness, this
attribute does not always exist, and it will be possible to remove it
when we have the attribute remove node back, to improve performance.
Differential Revision: https://developer.blender.org/D12903
Previously, some multi-functions were allocated in a resource scope.
This was fine as long as the multi-functions were only needed during
the current evaluation of the node tree. However, now cases arise
that require the multi-functions to be alive after the modifier is finished.
For example, we want to evaluate fields created with geometry nodes
outside of geometry nodes.
To make this work, `std::shared_ptr` has to be used in a few more places.
Realistically, this shouldn't have a noticable impact on performance.
If this does become a bottleneck in the future, we can think about ways
to make this work without using `shared_ptr` for multi-functions that
are only used once.
Instead of checking whether the socket value was hidden, use the proper
node declaration to check whether the socket has an implicit input. The
remaining larger change to make is allowing nodes to specify what their
implicit input should actually be.
This commit implements T91780, adding nodes to get and set builtin
attributes. Individual set nodes are used so that the values can be
exposed for direct editing, which is useful for attributes like shade
smooth and spline resolution. Individual input nodes are used to allow
reusing nodes for multiple components, and to allow grouping multiple
outputs conceptually in the same node in the future.
Input Nodes
- Radius
- Curve Tilt
- Curve Handle Positions
- Is Shade Smooth
- Spline Resolution
- Is Spline Cyclic
'Set' Nodes
- Curve Radius
- Point Radius
- Curve Tilt
- Curve Handle Positions
- Is Shade Smooth
- Spline Resolution
- Is Spline Cyclic
Using hardcoded categories is necessary to add separators to the node
menu.
Differential Revision: https://developer.blender.org/D12687
Add a fields-aware implementation of the attribute proximity node.
The Source position is an implicit position field, but can be
connected with a position input node with alterations before use.
The target input and mode function the same as the original node.
Patch by Johnny Matthews with edits from Hans Goudey (@HooglyBoogly).
Differential Revision: https://developer.blender.org/D12635
This enables fields as the official workflow for geometry nodes.
While many features are converted to use fields rather than the old
attribute workflow, many are not yet converted. In that case, the
unconverted nodes are still accessible with an experimental option.
In the coming weeks the rest of the nodes will be converted.
Differential Revision: https://developer.blender.org/D12672
This commit adds nodes to do direct conversion between meshes and point
clouds in geometry nodes. The conversion from mesh to points is helpful
to instance once per face, or once per edge, which was previously only
possibly with ugly work-arounds. Fields can be evaluated on the mesh
to pass them to the points with the attribute capture node.
The other conversion, point cloud to mesh vertices, is a bit less
obvious, though it is still a common request from users. It's helpful
for flexibility when passing data around, better visualization in the
viewport (and in the future, cycles), and the simplicity of points.
This is a step towards T91754, where point clouds are currently
combined with meshes when outputing to the next modifier after geometry
nodes. Since we're removing the implicit behavior for realizing
instances, it feels natural to use an explicit node to convert points
to vertices too.
Differential Revision: https://developer.blender.org/D12657
This adds a new Instance on Points node that is a replacement
for the old Point Instance node. Contrary to the old node,
it does not have a mode to instance objects or collections
directly. Instead, the node has to be used with an Object/
Collection Info to achieve the same effect.
Rotation and scale of the instances can be adjusted in the node
directly or can be controlled with a field to get some variation
between instances.
The node supports placing different instances on different points.
The user has control over which instance is placed on which point
using an Instance Index input. If that functionality is used, the
Instance Geometry has to contain multiple instances that can are
instanced separately.
Differential Revision: https://developer.blender.org/D12478
This node replaces the deprecated Attribute Randomize node, populating
a vector, float, integer or boolean field with random values. Vector,
float, and integer have min/max settings, which are also field aware.
The boolean type has a probability value for controlling what portion
of the output should be true. All four types have a field seed input
which is implicitly driven by the index, otherwise, all values would
be the same "random" value.
The Random Float node is now deprecated like other nodes, since it is
redundant with this node.
Differential Revision: https://developer.blender.org/D12603
This commit adds warning messages to "legacy" nodes that will be
removed in the future. The warning is shown in the node header, but
it is not printed in the terminal or displayed in the modifier. It is
also not propogated to node groups, but that is a more general task.
If the modifier's node tree has executed a deprecated node, it will
display a warning and a "Search" button that will select the nodes and
pan to them in the node editor. This doesn't open child node trees and
select nodes in there, because I want to keep this operator simple and
avoid wasting a lot of time perfecting this behavior.
Differential Revision: https://developer.blender.org/D12454
This change makes the Set Position node do nothing by default.
Before, the geometry would always disappear, because it all points
would be moved to (0, 0, 0).
Differential Revision: https://developer.blender.org/D12553
Since fields were committed to master, socket inspection did
not work correctly for all socket types anymore. Now the same
functionality as before is back. Furthermore, fields that depend
on some input will now show the inputs in the socket inspection.
I added support for evaluating constant fields more immediately.
This has the benefit that the same constant field is not evaluated
more than once. It also helps with making the field independent
of the multi-functions that it uses. We might still want to change
the ownership handling for the multi-functions of nodes a bit,
but that can be done separately.
Differential Revision: https://developer.blender.org/D12444
This implements the initial core framework for fields and anonymous
attributes (also see T91274).
The new functionality is hidden behind the "Geometry Nodes Fields"
feature flag. When enabled in the user preferences, the following
new nodes become available: `Position`, `Index`, `Normal`,
`Set Position` and `Attribute Capture`.
Socket inspection has not been updated to work with fields yet.
Besides these changes at the user level, this patch contains the
ground work for:
* building and evaluating fields at run-time (`FN_fields.hh`) and
* creating and accessing anonymous attributes on geometry
(`BKE_anonymous_attribute.h`).
For evaluating fields we use a new so called multi-function procedure
(`FN_multi_function_procedure.hh`). It allows composing multi-functions
in arbitrary ways and supports efficient evaluation as is required by
fields. See `FN_multi_function_procedure.hh` for more details on how
this evaluation mechanism can be used.
A new `AttributeIDRef` has been added which allows handling named
and anonymous attributes in the same way in many places.
Hans and I worked on this patch together.
Differential Revision: https://developer.blender.org/D12414
The multi-function network system was able to compose multiple
multi-functions into a new one and to evaluate that efficiently.
This functionality was heavily used by the particle nodes prototype
a year ago. However, since then we only used multi-functions
without the need to compose them in geometry nodes.
The upcoming "fields" in geometry nodes will need a way to
compose multi-functions again. Unfortunately, the code removed
in this commit was not ideal for this different kind of function
composition. I've been working on an alternative that will be added
separately when it becomes needed.
I've had to update all the function nodes, because their interface
depended on the multi-function network data structure a bit.
The actual multi-function implementations are still the same though.
Many ui features for geometry nodes need access to information generated
during evaluation:
* Node warnings.
* Attribute search.
* Viewer node.
* Socket inspection (not in master yet).
The way we logged the required information before had some disadvantages:
* Viewer node used a completely separate system from node warnings and
attribute search.
* Most of the context of logged information is lost when e.g. the same node
group is used multiple times.
* A global lock was needed every time something is logged.
This new implementation solves these problems:
* All four mentioned ui features use the same underlying logging system.
* All context information for logged values is kept intact.
* Every thread has its own local logger. The logged informatiton is combined
in the end.
Differential Revision: https://developer.blender.org/D11785
This adds a viewer node similar to the one in the compositor.
The icon in the headers of nodes is removed because it served
the same purpose and is not necessary anymore.
Node outputs can be connected to the active viewer using
ctrl+shift+LMB, just like in the compositor. Right now this collides
with the shortcut used in the node wrangler addon, which will
be changed separately.
As of now, the viewed geometry is only visible in the spreadsheet.
Viewport visualization will be added separately.
There are a couple of benefits of using a viewer node compared
to the old approach with the icon in the node header:
* Better support for nodes that have more than one geometry output.
* It's more consistent with the compositor.
* If attributes become decoupled from geometry in the future,
the viewer can have a separate input for the attribute to visualize.
* The viewer node could potentially have visualization settings.
* Allows to keep "visualization points" around by having multiple
viewer nodes.
* Less visual clutter in node headers.
Differential Revision: https://developer.blender.org/D11470
* Reduce code duplication.
* Give methods more standardized names (e.g. `move_to_initialized` -> `move_assign`).
* Support wrapping arbitrary C++ types, even those that e.g. are not copyable.
