Files
test2/source/blender/nodes/NOD_partial_eval.hh
Jacques Lucke 24dc9a21b1 Geometry Nodes: support attaching gizmos to input values
This adds support for attaching gizmos for input values. The goal is to make it
easier for users to set input values intuitively in the 3D viewport.

We went through multiple different possible designs until we settled on the one
implemented here. We picked it for it's flexibility and ease of use when using
geometry node assets. The core principle in the design is that **gizmos are
attached to existing input values instead of being the input value themselves**.
This actually fits the existing concept of gizmos in Blender well, but may be a
bit unintutitive in a node setup at first. The attachment is done using links in
the node editor.

The most basic usage of the node is to link a Value node to the new Linear Gizmo
node. This attaches the gizmo to the input value and allows you to change it
from the 3D view. The attachment is indicated by the gizmo icon in the sockets
which are controlled by a gizmo as well as the back-link (notice the double
link) when the gizmo is active.

The core principle makes it straight forward to control the same node setup from
the 3D view with gizmos, or by manually changing input values, or by driving the
input values procedurally.

If the input value is controlled indirectly by other inputs, it's often possible
to **automatically propagate** the gizmo to the actual input.

Backpropagation does not work for all nodes, although more nodes can be
supported over time.

This patch adds the first three gizmo nodes which cover common use cases:
* **Linear Gizmo**: Creates a gizmo that controls a float or integer value using
  a linear movement of e.g. an arrow in the 3D viewport.
* **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be
  rotated to change the attached angle input.
* **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale.

In the future, more built-in gizmos and potentially the ability for custom
gizmos could be added.

All gizmo nodes have a **Transform** geometry output. Using it is optional but
it is recommended when the gizmo is used to control inputs that affect a
geometry. When it is used, Blender will automatically transform the gizmos
together with the geometry that they control. To achieve this, the output should
be merged with the generated geometry using the *Join Geometry* node. The data
contained in *Transform* output is not visible geometry, but just internal
information that helps Blender to give a better user experience when using
gizmos.

The gizmo nodes have a multi-input socket. This allows **controlling multiple
values** with the same gizmo.

Only a small set of **gizmo shapes** is supported initially. It might be
extended in the future but one goal is to give the gizmos used by different node
group assets a familiar look and feel. A similar constraint exists for
**colors**. Currently, one can choose from a fixed set of colors which can be
modified in the theme settings.

The set of **visible gizmos** is determined by a multiple factors because it's
not really feasible to show all possible gizmos at all times. To see any of the
geometry nodes gizmos, the "Active Modifier" option has to be enabled in the
"Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of
the following is true:
* The gizmo controls an input of the active modifier of the active object.
* The gizmo controls a value in a selected node in an open node editor.
* The gizmo controls a pinned value in an open node editor. Pinning works by
  clicking the gizmo icon next to the value.

Pull Request: https://projects.blender.org/blender/blender/pulls/112677
2024-07-10 16:18:47 +02:00

95 lines
4.5 KiB
C++

/* SPDX-FileCopyrightText: 2024 Blender Authors
*
* SPDX-License-Identifier: GPL-2.0-or-later */
#pragma once
#include "NOD_node_in_compute_context.hh"
#include "BLI_function_ref.hh"
#include "BLI_resource_scope.hh"
#include "BLI_set.hh"
#include "DNA_node_types.h"
/**
* This header provides functionality that makes it relatively straight forward to evaluate parts
* of a node tree. The evaluator is designed to be flexible and simple to use in different
* contexts. It's not designed to be highly efficient and parallel. However, it has a lower
* start-up cost compared to e.g. the lazy-function evaluation for geometry nodes, which needs to
* convert the entire node graph into a lazy-function graph first. So it can be more efficient when
* only very few nodes of a larger graph have to be evaluated and those nodes are cheap.
*
* The evaluator does not use recursion, so it can be used on node graphs of every size and depth.
*/
namespace blender::nodes::partial_eval {
/**
* Evaluating part of a node tree from left-to-right. The part that's evaluated starts at
* the given sockets and is propagated downstream step-by-step. The caller is responsible for
* storing the socket values (a value per #SocketInContext).
*
* \note This handles node groups transparently, but does not handle e.g. repeat zones yet.
*
* \param initial_sockets: Sockets where the evaluation should start.
* \param scope: Is used to construct compute contexts which the caller may want to outlive the
* entire evaluation.
* \param evaluate_node_fn: Is called when all (relevant) upstream nodes are already evaluated and
* evaluates the given node. This should updated the values the caller stores for the output
* sockets.
* \param propagate_value_fn: Should copy the value stored for one socket to the other socket. This
* may have to do type conversions. The return value indicates success. False indicates that the
* value was not propagated and as such the target node also shouldn't be evaluated (unless there
* are other reasons to evaluate it).
*/
void eval_downstream(
const Span<SocketInContext> initial_sockets,
ResourceScope &scope,
FunctionRef<void(const NodeInContext &ctx_node,
Vector<const bNodeSocket *> &r_outputs_to_propagate)> evaluate_node_fn,
FunctionRef<bool(const SocketInContext &ctx_from, const SocketInContext &ctx_to)>
propagate_value_fn);
struct UpstreamEvalTargets {
Set<SocketInContext> sockets;
Set<NodeInContext> value_nodes;
Set<SocketInContext> group_inputs;
};
/**
* Evaluates part of a node tree from right-to-left (inverse direction). The caller is responsible
* for storing the socket values (a value per #SocketInContext). Evaluation in the upstream
* direction is not always well defined, because output sockets may be linked to multiple inputs
* and nodes may not always have an inverse evaluation function. The caller is responsible for
* handling these cases gracefully in the given callbacks.
*
* \note This handles node groups transparently, but does not handle e.g. repeat zones yet.
*
* \param initial_sockets: Sockets where the evaluation should start.
* \param scope: Is used to construct compute contexts which the caller may want to outlive the
* entire evaluation.
* \param evaluate_node_fn: Called to evaluate the node in reverse, i.e. it's outputs are computed
* first, and the node evaluation computes the inputs.
* \param propagate_value_fn: Should copy the value from one socket to another, while optionally
* doing type conversions. This has to handle the case when multiple values are propagated to the
* same socket. Returning false indicates that no value was propagated.
* \param get_inputs_to_propagate_fn: Gathers a list of input sockets that should be propagated
* further.
*
* \return Places in the node tree that have gotten new values that can't be propagated further in
* the node tree.
*/
UpstreamEvalTargets eval_upstream(
const Span<SocketInContext> initial_sockets,
ResourceScope &scope,
FunctionRef<void(const NodeInContext &ctx_node,
Vector<const bNodeSocket *> &r_modified_inputs)> evaluate_node_fn,
FunctionRef<bool(const SocketInContext &ctx_from, const SocketInContext &ctx_to)>
propagate_value_fn,
FunctionRef<void(const NodeInContext &ctx_node, Vector<const bNodeSocket *> &r_sockets)>
get_inputs_to_propagate_fn);
bool is_supported_value_node(const bNode &node);
} // namespace blender::nodes::partial_eval