Node Editor: Add overlay to automatically label reroute nodes #113368

Open
Leon Schittek wants to merge 22 commits from lone_noel/blender:node-editor-reroute-label-propagation into main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Member

Add an overlay option to automatically display a label on reroute nodes.

This automatic label is propagated through chained reroute nodes and
is based on the explicit label of linked reroute nodes.

The automatic label is dimmed to distinguish it from manually set ones.


This PR is split off of an old patch submitted here: https://archive.blender.org/developer/D11209

reroute_label_propagation.png

Motivation

Reroute nodes are often used to route links over longer distances.
Labeling the reroutes helps not to lose track of the source of links in
these situations, when it eventually gets out of view.

Manually labeling the reroutes has the disadvantage that the labels
can get out of sync when the tree is edited.
Propagating the label through chained reroutes as is done for the
socket type can help with that.

Add an overlay option to automatically display a label on reroute nodes. This automatic label is propagated through chained reroute nodes and is based on the explicit label of linked reroute nodes. The automatic label is dimmed to distinguish it from manually set ones. --- This PR is split off of an old patch submitted here: https://archive.blender.org/developer/D11209 ![reroute_label_propagation.png](https://projects.blender.org/attachments/a2846ec3-1af9-426a-ac2e-37376902147d) #### Motivation Reroute nodes are often used to route links over longer distances. Labeling the reroutes helps not to lose track of the source of links in these situations, when it eventually gets out of view. Manually labeling the reroutes has the disadvantage that the labels can get out of sync when the tree is edited. Propagating the label through chained reroutes as is done for the socket type can help with that.
Leon Schittek added 1 commit 2023-10-06 22:49:35 +02:00
0fc85dff87 Node Editor: Add overlay for reroute auto labels
Add an overlay option to automatically display a label on reroute nodes.
This automatic label is propagated through chained reroute nodes and
is based on the socket the reroutes are linked to. If a reroute node is
explicitly labeled, that label is propagated instead.

The automatic label is dimmed to distinguish it from manual labels.
Iliya Katushenock reviewed 2023-10-06 22:57:39 +02:00
@ -474,0 +515,4 @@
node_sock_label_clear(output);
}
static void update_reroute_node_auto_labels(bNodeTree *ntree)

It's possible that you can simply iterate over all nodes in ntree.toposort_left_to_right() and copy string ptr via node.inputs()...directly_linked_sockets()?

It's possible that you can simply iterate over all nodes in `ntree.toposort_left_to_right()` and copy string ptr via `node.inputs()...directly_linked_sockets()`?
Author
Member

Ah, cool! Looks promising. Will take a stab at that tomorrow.

Ah, cool! Looks promising. Will take a stab at that tomorrow.
lone_noel marked this conversation as resolved
Iliya Katushenock added this to the Nodes & Physics project 2023-10-06 22:58:07 +02:00
Leon Schittek added 3 commits 2023-10-07 13:52:25 +02:00
Leon Schittek added 1 commit 2023-10-07 14:15:16 +02:00

Here are few examples of use this feature in my old projects, works good.

image image
image image
image image
Here are few examples of use this feature in my old projects, works good. | | | | -- | -- | | ![image](/attachments/c5041e5e-13cd-44ba-8c7e-f2dfa7767b49) | ![image](/attachments/5c143f1b-30a2-4ca5-9765-bd2fd745cebc) | | ![image](/attachments/29945915-28dd-44b3-928d-55b022d348ff) | ![image](/attachments/a941b586-6070-4302-aa42-1158349b4765) | | ![image](/attachments/7454da18-3472-4f09-83e4-dbd63fc9960a) | ![image](/attachments/7d42708f-7198-4205-a054-992c62536ac2) |
Iliya Katushenock reviewed 2023-10-07 15:35:11 +02:00
Iliya Katushenock left a comment
Member

Just few cleanup comments

Just few cleanup comments
@ -310,6 +310,8 @@ void node_type_size_preset(bNodeType *ntype, eNodeSizePreset size);
/** \name Node Generic Functions
* \{ */
void ntree_update_auto_labels(bNodeTree *ntree);

Better to use reference instead of pointer in all functions.

Better to use reference instead of pointer in all functions.
lone_noel marked this conversation as resolved
@ -2064,0 +2064,4 @@
static void rna_Node_update_node_labels(Main *bmain, Scene *scene, PointerRNA *ptr)
{
bNodeTree *ntree = reinterpret_cast<bNodeTree *>(ptr->owner_id);
bNode *node = static_cast<bNode *>(ptr->data);

Can be const reference.

Can be const reference.
lone_noel marked this conversation as resolved
@ -474,0 +476,4 @@
ntree->ensure_topology_cache();
const blender::Span<bNode *> nodes = ntree->toposort_left_to_right();
for (bNode *reroute : nodes) {

for (bNode *reroute : ntree->toposort_left_to_right()) {

`for (bNode *reroute : ntree->toposort_left_to_right()) {`
lone_noel marked this conversation as resolved
@ -474,0 +491,4 @@
continue;
}
const bNodeSocket *from_sock = linked_sockets.first();

Can be reference.

Can be reference.
lone_noel marked this conversation as resolved
Leon Schittek added 3 commits 2023-10-08 10:24:41 +02:00
Leon Schittek added 1 commit 2023-11-09 22:21:23 +01:00
Leon Schittek added 4 commits 2023-11-25 14:19:32 +01:00
Author
Member

I wanted to address some of the points raised in the module meeting.

Make sure that the name doesn’t show when zoom out

That makes sense. I made it so the labels stop showing at the same zoom when we stop drawing sockets.

Using different colors for the explicit labels might not be necessary

Perhaps. For now I kept it, because I feel like it might be a bit frustraiting to have to look for the first instance of a labeled reroute. But happy to change this if that's not an actual issue.

Check how much it helps to use the generic output names of some nodes (e.g. just “Geometry”)

I removed the generic names for now to see what you think about it. I also checked if adding the node's name helps (see screenshots below).
I think the node names do add some context but I find both (3.) and (4.) too busy. Though (4.) made me realize that it might be nice, if the outputs of the math operations were named more explicitly. Like "Sum" for the Add node or "Difference" for Subtract etc.

1. All socket labels (previous PR) autolabels_sockets.png
2. Without generic labels (current PR) autolabels_non-generic-sockets.png
3. Added node names to all sockets autolabels_node-and-socket.png
4. Node names without generic labels autolabels_node-and-non-generic-sockets.png
I wanted to address some of the points raised in the module meeting. > Make sure that the name doesn’t show when zoom out That makes sense. I made it so the labels stop showing at the same zoom when we stop drawing sockets. > Using different colors for the explicit labels might not be necessary Perhaps. For now I kept it, because I feel like it might be a bit frustraiting to have to look for the first instance of a labeled reroute. But happy to change this if that's not an actual issue. > Check how much it helps to use the generic output names of some nodes (e.g. just “Geometry”) I removed the generic names for now to see what you think about it. I also checked if adding the node's name helps (see screenshots below). I think the node names do add some context but I find both (3.) and (4.) too busy. Though (4.) made me realize that it might be nice, if the outputs of the math operations were named more explicitly. Like "Sum" for the *Add* node or "Difference" for *Subtract* etc. |||| |---|---|---| |1.|All socket labels (previous PR)|![autolabels_sockets.png](/attachments/2f7edc90-f96e-452a-b9fc-ff1f439ca214)| |2.|Without generic labels (current PR)|![autolabels_non-generic-sockets.png](/attachments/3349945e-c7b8-42f8-ad9d-889bc9f46880)| |3.|Added node names to all sockets|![autolabels_node-and-socket.png](/attachments/b001c3b5-8c07-4882-9a2b-ee86a280c5b9)| |4.|Node names without generic labels|![autolabels_node-and-non-generic-sockets.png](/attachments/1554300e-1d3b-4fa7-adbc-8b37a8bf085f)|
Iliya Katushenock reviewed 2023-11-25 18:52:55 +01:00
Iliya Katushenock left a comment
Member

Not sure if avoiding template names would helps. But i'd like Node Name + Socket Name (if non-trivial).

Not sure if avoiding template names would helps. But i'd like `Node Name` + `Socket Name` (if non-trivial).
@ -522,0 +527,4 @@
const char *socket_label = blender::bke::nodeSocketLabel(&sock);
switch (sock.typeinfo->type) {
case SOCK_FLOAT:
if (socket_label == StringRef("Value")) {
static const VectorSet<std::pait<eNodeSocketDatatype, StringRefNull>> template_names = []() {
  VectorSet<std::pait<eNodeSocketDatatype, StringRefNull>> names;
  names.add_new({SOCK_FLOAT, "Value"});
  ...
  return names;
}();

const bool name_is_trivial = template_names.contains({sock.typeinfo->type, socket_label});
```Cpp static const VectorSet<std::pait<eNodeSocketDatatype, StringRefNull>> template_names = []() { VectorSet<std::pait<eNodeSocketDatatype, StringRefNull>> names; names.add_new({SOCK_FLOAT, "Value"}); ... return names; }(); const bool name_is_trivial = template_names.contains({sock.typeinfo->type, socket_label}); ```
Author
Member

Ah, that looks nice, thanks!

Ah, that looks nice, thanks!
lone_noel marked this conversation as resolved
Leon Schittek added 2 commits 2023-11-26 13:37:10 +01:00
Hans Goudey requested review from Simon Thommes 2023-12-12 00:14:14 +01:00
First-time contributor

Hi there ! It's awesome to see this feature developed again !
I did a python version inspired by Leon's initial work and this is super useful to document big trees, here is an example :
image

I'm not completely sold on automatically generating names for two reasons :
1/ It buries what is added manually and which is probably more important. It adds a lot of clutter especially for people who plans to have that activated all the time.

2/ It conveys the operation or what kind of node it's originated from, rather than what it's supposed to be. Let me explain :
Most of the time, we are more interested in what a noodle represent : say I've got a value that represent the length of a room, and I've added the thickness of the walls, I'm more interested in knowing that this particular reroute represents the room size, rather than the add operation that was done on that.

Anyway, that's probably just how I like to use the tool and for other applications this can be useful.
Maybe it's possible to make everyone happy by introducing some kind of a verbosity level :
0 : no propagation
1 : Manually named labels only
2 : Without generic label
3 : All socket label
4 : Node names and sockets

This way you decide how much info you want to see.

Hi there ! It's awesome to see this feature developed again ! I did a python version inspired by Leon's initial work and this is super useful to document big trees, here is an example : ![image](/attachments/df6cb274-0893-493d-b241-91f66acfc770) I'm not completely sold on automatically generating names for two reasons : 1/ It buries what is added manually and which is probably more important. It adds a lot of clutter especially for people who plans to have that activated all the time. 2/ It conveys the operation or what kind of node it's originated from, rather than what it's supposed to be. Let me explain : Most of the time, we are more interested in what a noodle represent : say I've got a value that represent the length of a room, and I've added the thickness of the walls, I'm more interested in knowing that this particular reroute represents the room size, rather than the add operation that was done on that. Anyway, that's probably just how I like to use the tool and for other applications this can be useful. Maybe it's possible to make everyone happy by introducing some kind of a verbosity level : 0 : no propagation 1 : Manually named labels only 2 : Without generic label 3 : All socket label 4 : Node names and sockets This way you decide how much info you want to see.
280 KiB
Author
Member

Thanks for the feedback and example, @sozap

1/ It buries what is added manually and which is probably more important. It adds a lot of clutter especially for people who plans to have that activated all the time.
2/ It conveys the operation or what kind of node it's originated from, rather than what it's supposed to be.

I think these are fair points.

Personally I don't think(hope) we need the granularity of different verbosity levels and would rather see us end up with something you can just toggle on or off.

While I can see the non-generic socket labels (without node names) adding value in some situations and I like that they add a degree of automatic annotation to the node tree, I'd rather go with just propagating user-set labels than cluttering the view with unnecessary info.

With only user-created labels we could also probably enable this overlay by default, which would be nice.

Thanks for the feedback and example, @sozap > 1/ It buries what is added manually and which is probably more important. It adds a lot of clutter especially for people who plans to have that activated all the time. > 2/ It conveys the operation or what kind of node it's originated from, rather than what it's supposed to be. I think these are fair points. Personally I don't think(hope) we need the granularity of different verbosity levels and would rather see us end up with something you can just toggle on or off. While I can see the non-generic socket labels (without node names) adding value in some situations and I like that they add a degree of automatic annotation to the node tree, I'd rather go with just propagating user-set labels than cluttering the view with unnecessary info. With only user-created labels we could also probably enable this overlay by default, which would be nice.
Leon Schittek added 4 commits 2024-02-24 12:54:52 +01:00
Leon Schittek added 1 commit 2024-03-03 16:47:02 +01:00
Leon Schittek added 1 commit 2024-03-15 09:58:44 +01:00
Leon Schittek added 1 commit 2024-04-14 18:40:58 +02:00
This pull request has changes conflicting with the target branch.
  • source/blender/blenkernel/BKE_blender_version.h
  • source/blender/blenloader/intern/versioning_400.cc

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u node-editor-reroute-label-propagation:lone_noel-node-editor-reroute-label-propagation
git checkout lone_noel-node-editor-reroute-label-propagation
Sign in to join this conversation.
No reviewers
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#113368
No description provided.