Visualization of fields on the node editor #90869

New Issue

Jacques Lucke · 2021-08-23T10:47:02+02:00

Jacques Lucke commented

2021-08-23 10:47:02 +02:00

In the attribute workflow with fields some sockets/links contain data while some contain functions that only compute data later on. The goal of this task is to decide how we want to visualize different aspects of this design in the node editor.

In earlier discussions we noticed that there are numerous aspects that can be visualized. Showing all different aspects at all times will probably overload the ui. Therefore, part of this task is to prioritize it is to visualize different aspects. The most important aspects can then always be shown, while other aspects are e.g. only visible in tooltips or when creating new links.

Aspects that can be visualized:

Inputs that only allow data (includes geometry inputs).
Inputs that allow fields that are evaluated by this node.
Inputs that allow fields that are only passed through.
Outputs that are pure data.
Outputs that are fields.
Fields that only depend on built-in, named or derived attributes (those can generally be used on every geometry).
Fields that only depend on anonymous attributes (those can only be used on "downstream" geometries that contain the anonymous attribute).
Fields that depend on both.

The main things we can change for the visualization are socket shapes/colors/borders/... and link styles/colors/...
Changing node shapes has also been discussed a bit, but I don't find that very practical for this purpose. That quickly breaks down when one starts to build node groups.
We should also keep in mind that we might want to reuse the concept of fields in other node systems in the future. So if possible, we should try to avoid making the visualization too specialized for geometry processing.

Currently, my personal take on this is as follows. The two most important things to visualize are:

What sockets/links contain a (non-constant) field.
Which inputs allow a field vs. allow only data.

I would not visualize the different kinds of fields differently based on what they depend on. In the majority of cases that will probably be obvious based on where the field is coming from. Still, the exact dependencies of a field should be visible in the socket inspection. Note, the same node can sometimes output a field sometimes not (e.g. the math node) depending on the inputs, so the visualization has to be a bit dynamic.

For better learnability I like the idea of graying out sockets that you should not connect a field to (because it is not "downstream" and is missing required anonymous attributes).

In the attribute workflow with fields some sockets/links contain data while some contain functions that only compute data later on. The goal of this task is to decide how we want to visualize different aspects of this design in the node editor. In earlier discussions we noticed that there are numerous aspects that can be visualized. Showing all different aspects at all times will probably overload the ui. Therefore, part of this task is to prioritize it is to visualize different aspects. The most important aspects can then always be shown, while other aspects are e.g. only visible in tooltips or when creating new links. Aspects that can be visualized: * Inputs that only allow data (includes geometry inputs). * Inputs that allow fields that are evaluated by this node. * Inputs that allow fields that are only passed through. * Outputs that are pure data. * Outputs that are fields. * Fields that only depend on built-in, named or derived attributes (those can generally be used on every geometry). * Fields that only depend on anonymous attributes (those can only be used on "downstream" geometries that contain the anonymous attribute). * Fields that depend on both. The main things we can change for the visualization are socket shapes/colors/borders/... and link styles/colors/... Changing node shapes has also been discussed a bit, but I don't find that very practical for this purpose. That quickly breaks down when one starts to build node groups. We should also keep in mind that we might want to reuse the concept of fields in other node systems in the future. So if possible, we should try to avoid making the visualization too specialized for geometry processing. ------ Currently, my personal take on this is as follows. The two most important things to visualize are: 1. What sockets/links contain a (non-constant) field. 2. Which inputs allow a field vs. allow only data. I would not visualize the different kinds of fields differently based on what they depend on. In the majority of cases that will probably be obvious based on where the field is coming from. Still, the exact dependencies of a field should be visible in the socket inspection. Note, the same node can sometimes output a field sometimes not (e.g. the math node) depending on the inputs, so the visualization has to be a bit dynamic. For better learnability I like the idea of graying out sockets that you should not connect a field to (because it is not "downstream" and is missing required anonymous attributes).

Jacques Lucke commented

2021-08-23 10:47:02 +02:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2021-08-25 15:40:22 +02:00

I worked on a quick prototype for this yesterday. Here is a video for reference:
2021-08-25 15-32-39.mp4

It's just a simple tech demo for the visualization, so the socket shapes are temporary.

There are three different socket shapes:

Vertical bar: This socket is required to be data, not some field. This socket type propagates from right to left.
Combination of vertical bar and circle: This socket currently always contains data, but it is allowed to be a field.
Circle: This socket may be a field. This propagates from left to right.
All socket shapes can be connected to a circle.
A circle cannot be connected to a vertical bar.

I worked on a quick prototype for this yesterday. Here is a video for reference: [2021-08-25 15-32-39.mp4](https://archive.blender.org/developer/F10324952/2021-08-25_15-32-39.mp4) It's just a simple tech demo for the visualization, so the socket shapes are temporary. There are three different socket shapes: * Vertical bar: This socket is required to be data, not some field. This socket type propagates from right to left. * Combination of vertical bar and circle: This socket currently always contains data, but it is allowed to be a field. * Circle: This socket may be a field. This propagates from left to right. * All socket shapes can be connected to a circle. * A circle cannot be connected to a vertical bar.

Vladislav Macíček commented

2021-08-26 22:46:59 +02:00

Added subscriber: @Aeraglyx

Jacques Lucke commented

2021-09-13 11:44:54 +02:00

https://devtalk.blender.org/t/2021-08-09-2021-9-03-geometry-nodes-sub-module-meetings/20314

Think we have enough design for now to work on the initial implementation for the visualization. We might need a separate future task to work out some of the details.

https://devtalk.blender.org/t/2021-08-09-2021-9-03-geometry-nodes-sub-module-meetings/20314 Think we have enough design for now to work on the initial implementation for the visualization. We might need a separate future task to work out some of the details.

Jacques Lucke commented

2021-09-17 15:51:29 +02:00

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

Jacques Lucke closed this issue

2021-09-17 15:51:29 +02:00

Jacques Lucke self-assigned this 2021-09-17 15:51:29 +02:00

Paul Larson commented

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

Added subscriber: @GeorgiaPacific

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

Visualization of fields on the node editor #90869