Function flow visualization #91563

New Issue

Dalai Felinto · 2021-09-21T12:51:11+02:00

Dalai Felinto commented

2021-09-21 12:51:11 +02:00

Design Task: #90869

Other related task: #91215

We need to be able to draw some of the noodles (function flow) dashed.

This problem has two parts:

How to draw curved dashed lines.
How to set the function flow lines to use this style.

Reference commit: https://developer.blender.org/rBc27ef1e9e8e663e02173e518c1e669e9845b3d1f

{F10572628, size=full}

Design Task: #90869 Other related task: #91215 ----- We need to be able to draw some of the noodles (function flow) dashed. This problem has two parts: 1. How to draw curved dashed lines. 2. How to set the function flow lines to use this style. Reference commit: https://developer.blender.org/rBc27ef1e9e8e663e02173e518c1e669e9845b3d1f ----- {[F10572628](https://archive.blender.org/developer/F10572628/fields.png), size=full}

Dalai Felinto commented

2021-09-21 12:51:11 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Dalai Felinto commented

2021-09-21 12:51:11 +02:00

Added subscribers: @dfelinto, @pablovazquez

Paul Larson commented

2021-09-21 18:47:25 +02:00

Added subscriber: @GeorgiaPacific

Dalai Felinto commented

2021-09-22 16:03:59 +02:00

Added subscriber: @Jeroen-Bakker

Ludvik Koutny commented

2021-09-23 11:08:44 +02:00

Added subscriber: @Rawalanche

Ludvik Koutny commented

2021-09-23 11:08:44 +02:00

When it comes to distinguishing function flow from execution flow, here's what I propose:

Make execution flow sockets truly distinct. Not just different color / shape but also a bit larger in size
Make the execution flow node links width simply be a multiplier of node links width. So for example the execution flow node link thickness would always be 1.5x the size of data flow node links
Make the execution flow node links have always higher opacity than the data flow links, so that for example, the execution flow node links have always alpha of 0.9 while data flow links have alpha of 0.5.

When it comes to distinguishing function flow from execution flow, here's what I propose: 1. Make execution flow sockets truly distinct. Not just different color / shape but also a bit larger in size 2. Make the execution flow node links width simply be a multiplier of node links width. So for example the execution flow node link thickness would always be 1.5x the size of data flow node links 3. Make the execution flow node links have always higher opacity than the data flow links, so that for example, the execution flow node links have always alpha of 0.9 while data flow links have alpha of 0.5. ![image.png](https://archive.blender.org/developer/F10557525/image.png)

Aaron Carlisle commented

2021-09-23 13:58:21 +02:00

Added subscriber: @Blendify

Aaron Carlisle commented

2021-09-23 13:58:22 +02:00

I like @Rawalanche idea here I think what's new with the geometry nodes is the idea of execution. Other existing node types are function flow based. Ie manipulating some part of an image. I would say that perhaps shader sockets could also be considered execution flow?

For the above proposal a new socket shape is needed. And a check to draw the line thicker if drawn between two executive node socket shapes.

I like @Rawalanche idea here I think what's new with the geometry nodes is the idea of execution. Other existing node types are function flow based. Ie manipulating some part of an image. I would say that perhaps shader sockets could also be considered execution flow? For the above proposal a new socket shape is needed. And a check to draw the line thicker if drawn between two executive node socket shapes.

Dalai Felinto commented

2021-09-23 17:45:44 +02:00

The link between Value and the Multiply nodes is also data-flow, this is missing in your mockup.

The link between `Value` and the `Multiply` nodes is also data-flow, this is missing in your mockup.

Ludvik Koutny commented

2021-09-23 18:51:34 +02:00

In #91563#1224729, @dfelinto wrote:
The link between Value and the Multiply nodes is also data-flow, this is missing in your mockup.

Eh? What is the difference between data flow and execution flow then? I expect the execution flow to be the links between the nodes that actually operate on geometry, while data flow to be the the links which generate data to supply those "operator" nodes with. To me, a constant, such as value node, and a field, such as normal input, both seem like a data. At least in a sense that I am not sure it's that important to visually distinguish them for the end users.

Otherwise, if that's the case, then I suppose you'd need 3 different styles for connection links, because I am having a very hard time interpreting the execution flow between the nodes operating on the geometry, and a flow between nodes doing math operation using a field and a constant value, as the same class of node connection. If that was really the case, then the visual distinction would just confuse users, not make them more aware of what's happening.

In my simple mockup above, the normal field multiplied by the value constant can be thought of as looping over an array of 3D vectors and multiplying all dimensions of each vector in the array by a constant float value. That is just conceptually very different to actual program execution flow, which the top level operator nodes (with white triangle sockets) do.

Isn't there already some existing proposal which proposes to distinguish fields and constants by different node socket shapes? Wouldn't that be sufficient?

> In #91563#1224729, @dfelinto wrote: > The link between `Value` and the `Multiply` nodes is also data-flow, this is missing in your mockup. Eh? What is the difference between data flow and execution flow then? I expect the execution flow to be the links between the nodes that actually operate on geometry, while data flow to be the the links which generate data to supply those "operator" nodes with. To me, a constant, such as value node, and a field, such as normal input, both seem like a data. At least in a sense that I am not sure it's that important to visually distinguish them for the end users. Otherwise, if that's the case, then I suppose you'd need 3 different styles for connection links, because I am having a very hard time interpreting the execution flow between the nodes operating on the geometry, and a flow between nodes doing math operation using a field and a constant value, as the same class of node connection. If that was really the case, then the visual distinction would just confuse users, not make them more aware of what's happening. In my simple mockup above, the normal field multiplied by the value constant can be thought of as looping over an array of 3D vectors and multiplying all dimensions of each vector in the array by a constant float value. That is just conceptually very different to actual program execution flow, which the top level operator nodes (with white triangle sockets) do. Isn't there already some existing proposal which proposes to distinguish fields and constants by different node socket shapes? Wouldn't that be sufficient?

Máté Kerekes commented

2021-09-24 18:40:02 +02:00

Added subscriber: @elfoglalt

Máté Kerekes commented

2021-09-24 18:40:02 +02:00

I don't think dashed lines are a good representation for connections in a node tree. My first associations are broken, temporary or disabled connections. They are also rather noisy visually, making the graph layout difficult to follow (especially in combination with the default grid background).

I also agree with @rawalanche. I think the whole "function-flow" vs "data-flow" differentiation is currently being designed backwards. From a user's perspective "function-flow" is how most, if not all, the of the existing node trees work in blender, and it should be represented by the default noodles. The way math nodes operate in the shader editor for example, is identical to the function flow concept. Whether if these connections are implemented in the same way is an implementation detail that the users don't need to know.

Geometry connections do deserve a highlighted representation, but not because they represent data or functions, but rather because modifying geometries have side effects that are not directly apparent just by looking at a node graph. This is however probably a conversation for a whole devtalk thread because it touches things a lot larger than this single design task.

I don't think dashed lines are a good representation for connections in a node tree. My first associations are broken, temporary or disabled connections. They are also rather noisy visually, making the graph layout difficult to follow (especially in combination with the default grid background). I also agree with @rawalanche. I think the whole "function-flow" vs "data-flow" differentiation is currently being designed backwards. From a user's perspective "function-flow" is how most, if not all, the of the existing node trees work in blender, and it should be represented by the default noodles. The way math nodes operate in the shader editor for example, is identical to the function flow concept. Whether if these connections are implemented in the same way is an *implementation detail* that the users don't need to know. Geometry connections do deserve a highlighted representation, but not because they represent data or functions, but rather because modifying geometries have side effects that are not directly apparent just by looking at a node graph. This is however probably a conversation for a whole devtalk thread because it touches things a lot larger than this single design task.

blender-admin commented

2021-09-27 15:10:28 +02:00

This issue was referenced by 2bd0205215

This issue was referenced by 2bd020521578549eb47c58c7984c9a35b7c35cd8

Zijun Zhou commented

2021-09-27 18:13:13 +02:00

Added subscriber: @Eary

Zijun Zhou commented

2021-09-27 18:13:13 +02:00

I don't quite understand why the link between value and multiply would be data flow. The value node is not taking geometry source data, is it? The number it outputs is open to interpretation, when it's multiplied with Position it means this, when it multiplies with Normal it means something else. I think it should be part of the function flow. Because In my understanding this is the function (or expression) Ludvik was composing:
normal * 0
The zero should be part of the function, right? The zero is not geometry data from any source geometry, but simply a constant value with no particular meaning. The value node itself is also out-of-context on its own

I don't quite understand why the link between value and multiply would be data flow. The value node is not taking geometry source data, is it? The number it outputs is open to interpretation, when it's multiplied with `Position` it means this, when it multiplies with `Normal` it means something else. I think it should be part of the function flow. Because In my understanding this is the function (or expression) Ludvik was composing: `normal * 0` The zero should be part of the function, right? The zero is not geometry data from any source geometry, but simply a constant value with no particular meaning. The value node itself is also out-of-context on its own

Leon Schittek commented

2021-09-28 12:46:21 +02:00

Added subscriber: @lone_noel

Leon Schittek commented

2021-09-28 12:46:21 +02:00

In #91563#1225521, @elfoglalt wrote:
I think the whole "function-flow" vs "data-flow" differentiation is currently being designed backwards. From a user's perspective "function-flow" is how most, if not all, the of the existing node trees work in blender, and it should be represented by the default noodles. The way math nodes operate in the shader editor for example, is identical to the function flow concept.

I think this is a very good point. The new concept introduced isn't really the field flow, but the data flow. Both the shader and the compositor are "fields" in the broad sense the term is used in geometry nodes.
So however the function flow will be represented, I think it should be consistent between fields, the shader and the compositor. As an example: Both the shader and geometry nodes setup in the following screenshot do the same thing. It would be weird, if they looked very different.

I saw double lines being proposed a couple times and I think that could work great, but I would prefer using double lines for data flow rather than function flow. That way there could be single links for functions to indicate a "functional" or "logical" connection and a double line for data (as a metaphor: You could see it as a "tube" transporting data from one node to the other ;) ). This would keep fields, shader and compositor the way they are and consistent with each other.

I prototyped this and I think it looks quite nice:
{F10649053, size=full}

I also like that this would keep dashed lines as an option to potentially represent some kind of list type, if that ever gets introduced to geometry nodes, which would feel like a more natural fit.

> In #91563#1225521, @elfoglalt wrote: > I think the whole "function-flow" vs "data-flow" differentiation is currently being designed backwards. From a user's perspective "function-flow" is how most, if not all, the of the existing node trees work in blender, and it should be represented by the default noodles. The way math nodes operate in the shader editor for example, is identical to the function flow concept. I think this is a very good point. The new concept introduced isn't really the field flow, but the data flow. Both the shader and the compositor are "fields" in the broad sense the term is used in geometry nodes. So however the function flow will be represented, I think it should be consistent between fields, the shader and the compositor. As an example: Both the shader and geometry nodes setup in the following screenshot do the same thing. It would be weird, if they looked very different. ![shader-field-comparison.jpg](https://archive.blender.org/developer/F10585586/shader-field-comparison.jpg) I saw double lines being proposed a couple times and I think that could work great, but I would prefer using double lines for __data__ flow rather than function flow. That way there could be single links for functions to indicate a "functional" or "logical" connection and a double line for data (as a metaphor: You could see it as a "tube" transporting data from one node to the other ;) ). This would keep fields, shader and compositor the way they are and consistent with each other. I prototyped this and I think it looks quite nice: {[F10649053](https://archive.blender.org/developer/F10649053/double-line-data-flow.png), size=full} I also like that this would keep dashed lines as an option to potentially represent some kind of list type, if that ever gets introduced to geometry nodes, which would feel like a more natural fit.

blender-admin commented

2021-09-28 17:02:47 +02:00

This issue was referenced by ff7e67afd5

This issue was referenced by ff7e67afd5de2d0ce6614ecfda9a70735a2479ba

Dalai Felinto commented

2021-09-28 17:13:05 +02:00

Added subscriber: @SimonThommes

Dalai Felinto commented

2021-09-28 17:13:05 +02:00

Hi, I tried a bit with double-line for the function flow (this was the original design even). But it doesn't work so well. In the end I adjusted the dash size (based on feedback by @SimonThommes ) and committed the dashed lines in master.

For the records, this is the double-line patch: P2451

Thanks everyone for the feedbacks

Hi, I tried a bit with double-line for the function flow (this was the original design even). But it doesn't work so well. In the end I adjusted the dash size (based on feedback by @SimonThommes ) and committed the dashed lines in master. For the records, this is the double-line patch: [P2451](https://archive.blender.org/developer/P2451.txt) Thanks everyone for the feedbacks

Cartesian Caramel commented

2021-10-01 16:43:44 +02:00

Added subscriber: @Bbbn19

Cartesian Caramel commented

2021-10-01 16:43:44 +02:00

One issue I've been running into is that the dashed lines add quite a bit of noise to the node setup. Comparing the solid line with the dashed line it is harder to tell what is happening quickly. A compromise could be having the ability to go back to the solid line view in the user preferences.

One issue I've been running into is that the dashed lines add quite a bit of noise to the node setup. Comparing the solid line ![Solid Line.PNG](https://archive.blender.org/developer/F10714403/Solid_Line.PNG) with the dashed line ![Dashed Line.PNG](https://archive.blender.org/developer/F10714405/Dashed_Line.PNG) it is harder to tell what is happening quickly. A compromise could be having the ability to go back to the solid line view in the user preferences.

Hadrien Brissaud commented

2021-10-02 14:00:43 +02:00

Added subscriber: @hadrien

Hadrien Brissaud commented

2021-10-02 14:00:43 +02:00

I think I agree with Ludvik Koutny here : distinguishing single values from fields doesn't actually matter that much for the end user. What's the difference, after all ? one uses a single value (or a single vector, etc) whereas the other uses a bunch of values that vary over the mesh. Compare it to Cycles nodes : it's the same as using an input variable (such as the "normal" output from the "geometry" node) versus using a constant vector. The particularity of fields is entirely technical, and the socket change already communicates the fact that it's carrying many values instead of just one -which is a distinction that was never even brought up for Cycles nodes.

On the other hand, distinguishing the geometry flow from the rest of the connections seems important to me.

I think I agree with Ludvik Koutny here : distinguishing single values from fields doesn't actually matter that much for the end user. What's the difference, after all ? one uses a single value (or a single vector, etc) whereas the other uses a bunch of values that vary over the mesh. Compare it to Cycles nodes : it's the same as using an input variable (such as the "normal" output from the "geometry" node) versus using a constant vector. The particularity of fields is entirely technical, and the socket change already communicates the fact that it's carrying many values instead of just one -which is a distinction that was never even brought up for Cycles nodes. On the other hand, distinguishing the geometry flow from the rest of the connections seems important to me.

Juan Gea commented

2021-10-05 19:41:26 +02:00

Added subscriber: @juang3d

Juan Gea commented

2021-10-05 19:41:26 +02:00

I agree here, dashed lines add a lot of visual noise.

IMHO just a simple color change could have work, unless there are other plans for color in lines, a color is way more informative and easier to follow, no need to fancy things out with double lines or dashed lines.

I agree here, dashed lines add a lot of visual noise. IMHO just a simple color change could have work, unless there are other plans for color in lines, a color is way more informative and easier to follow, no need to fancy things out with double lines or dashed lines.

Jacques Lucke commented

2021-10-15 15:14:57 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Jacques Lucke closed this issue

2021-10-15 15:14:57 +02:00

Jacques Lucke self-assigned this 2021-10-15 15:14:57 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Function flow visualization #91563