Geometry Nodes: Dashed lines for function flow

Use dashes to represent the function flow (while keeping continuous
lines for the data-flow).

It is important to tell both flows apart (the data and the function
 flow). The sockets help with that, the noodles help this further.

The "data flow" is evaluated at every single node. A user can inspect
the output sockets of those nodes and have a glimpse at their values.

The "function flow" (nodes) however is only evaluated in the geometry
nodes. The noodles are not transporting data in the same sense of the
"data flow". All that can be inspected are the attributes the functions
depend on.

Having this clearly communicated should help users to inspect the
nodetrees, read and understand the different flows in the same tree.

---

Known limitations:

At the moment the dash lines are not equidistant:

* It would be nice to get the "uv.x" to be resampled for the bezier curve
so the dashes are equally distributed in the curve.

* Using distance between the P3 and P0 instead of the real bezier curve
length seems to be fine.

---

Full disclaimer:

Changes with that much of a visual impact tend to be controversial. So
far the main feedback is that dashed lines can be associated to broken
link, and that there are better ways to represent the flows (or
different information that should be visually represented).

I'm fully aware of that. However dashed lines are already used in the
viewport and outliner to indicate (hierarchical) relation. Besides,
other approaches (double-lines, having the data flow to be more
distinct, ...) didn't pan out in the end (or didn't look as good as
this).

---

Impact in other editors:

The compositor uses mostly a "data flow" nodetree, so no change is
expected there.

The shader nodetree is one that could but doesn't have to change its
visual language.

The shader nodetree uses mostly "function flow" with some "data flow" nodes.
One can argue that it should be adapted to follow the
same pattern as geometry nodes (with the new noodles and the diamond
sockets). Oh the other hand, a shader nodetree has a single context.
When a node depends on the "UV", there is only one UV at a time for the
entire nodetree. So it can also be treated as a psedo "data flow"
nodetree if we want to avoid too many changes in other parts of Blender.

Differential Revision: https://developer.blender.org/D12602

0 files changed, 0 insertions, 0 deletions