Node Editor: Add overlay to automatically label reroute nodes #113368
No reviewers
Labels
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 project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#113368
Loading…
Reference in New Issue
No description provided.
Delete Branch "lone_noel/blender:node-editor-reroute-label-propagation"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
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.
@ -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 vianode.inputs()...directly_linked_sockets()
?Ah, cool! Looks promising. Will take a stab at that tomorrow.
Here are few examples of use this feature in my old projects, works good.
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.
@ -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.
@ -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()) {
@ -474,0 +491,4 @@
continue;
}
const bNodeSocket *from_sock = linked_sockets.first();
Can be reference.
I wanted to address some of the points raised in the module meeting.
That makes sense. I made it so the labels stop showing at the same zoom when we stop drawing sockets.
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.
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.
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")) {
Ah, that looks nice, thanks!
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 :
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.
Thanks for the feedback and example, @sozap
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.
Checkout
From your project repository, check out a new branch and test the changes.