Node group inputs and outputs have incorrect "name" property #95432

Open
opened 2022-02-02 12:18:28 +01:00 by Lloyd · 18 comments

System Information
Operating system: Linux-5.8.0-44-generic-x86_64-with-glibc2.31 64 Bits
Graphics card: Radeon RX 580 Series (POLARIS10, DRM 3.42.0, 5.8.0-44-generic, LLVM 12.0.1) AMD 4.6 (Core Profile) Mesa 21.2.0-devel

Blender Version
Broken: version: 2.93.7 3.01 3.1 3.2
Worked: (newest version of Blender that worked as expected)

Short description of error
When adding new Input or Output Sockets in the Group Node Properties Tab, the selected Input or Output Socket name is duplicated.
Two issues:

    • the socket name is not unique (this can get problematic since entries in node.outputs are name based)
    • design question: should the new name default to either "Input" or "Output"?
      Should Default to Input or Output. ( Only Defaults to Input or Output if there are no Sockets except the Default ones )

Exact steps for others to reproduce the error
In the Node Editor add Input or Output Sockets to a nodegroup in the sidebar, change the name and try adding more Inputs or Outputs, the System will assign the name of the selected sockets.

Seems like there are muliple functions handling new sockets

  • make_socket_interface [in affect when adding a new socket through the UI] gives a unique identifier (but copies the name exactly -- no uniqueness)
  • nodeAddSocket or make_socket take care of making the name unique as well

{F12842289 size=full}

{F12842292 size=full}

ref #91826 (just to show that unique names are important).

**System Information** Operating system: Linux-5.8.0-44-generic-x86_64-with-glibc2.31 64 Bits Graphics card: Radeon RX 580 Series (POLARIS10, DRM 3.42.0, 5.8.0-44-generic, LLVM 12.0.1) AMD 4.6 (Core Profile) Mesa 21.2.0-devel **Blender Version** Broken: version: 2.93.7 3.01 3.1 3.2 Worked: (newest version of Blender that worked as expected) **Short description of error** When adding new Input or Output Sockets in the Group Node Properties Tab, the selected Input or Output Socket name is duplicated. Two issues: - - [x] the socket name is not unique (this can get problematic since entries in node.outputs are name based) - - [x] design question: should the new name default to either "Input" or "Output"? Should Default to Input or Output. ( Only Defaults to Input or Output if there are no Sockets except the Default ones ) **Exact steps for others to reproduce the error** In the Node Editor add Input or Output Sockets to a nodegroup in the sidebar, change the name and try adding more Inputs or Outputs, the System will assign the name of the selected sockets. Seems like there are muliple functions handling new sockets - `make_socket_interface` [in affect when adding a new socket through the UI] gives a unique identifier (but copies the name exactly -- no uniqueness) - `nodeAddSocket` or `make_socket` take care of making the name unique as well {[F12842289](https://archive.blender.org/developer/F12842289/image.png) size=full} {[F12842292](https://archive.blender.org/developer/F12842292/image.png) size=full} ref #91826 (just to show that unique names are important).
Author

Added subscriber: @LloydAlmeida

Added subscriber: @LloydAlmeida
Member

Added subscriber: @lichtwerk

Added subscriber: @lichtwerk
Member

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

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

Hm, not sure if it should default to "Input" or "Output" code pretty much looks like it wants to duplicate the name.
What is more concerning (I think) is that these dont get a new unique name.

Seems like there are muliple functions handling new sockets

  • make_socket_interface [in affect when adding a new socket through the UI] gives a unique identifier (but copies the name exactly -- no uniqueness)
  • nodeAddSocket or make_socket take care of making the name unique as well

ref #91826 (just to show that unique names are important).

I will add my concern to the report description (and leave the question of defaulting to "Input" / "Output" as a design question).

Hm, not sure if it should default to "Input" or "Output" code pretty much looks like it wants to duplicate the name. What is more concerning (I think) is that these dont get a new **unique** name. Seems like there are muliple functions handling new sockets - `make_socket_interface` [in affect when adding a new socket through the UI] gives a unique identifier (but copies the name exactly -- no uniqueness) - `nodeAddSocket` or `make_socket` take care of making the name unique as well ref #91826 (just to show that unique names are important). I will add my concern to the report description (and leave the question of defaulting to "Input" / "Output" as a design question).
Philipp Oeser changed title from Geometry Nodes - Selected Input or Output name is duplicated for the New Input. to Nodes Groups: adding new inputs or outputs will duplicate previous names (exactly, no uniqueness) 2022-02-02 16:29:53 +01:00
Member

Added subscriber: @HooglyBoogly

Added subscriber: @HooglyBoogly
Member

The node socket names aren't expected to be unique. That's why there's a separate identifier for each socket.

I don't think adding a .001 to names or something is helpful. Builtin nodes can reuse the same name for multiple sockets, so I think node groups should be able to as well.

When adding new Input or Output Sockets in the Group Node Properties Tab, the selected Input or Output Socket name is duplicated.

It's not just the name that's duplicated, but everything except the identifier. That's just because otherwise the new input/output is totally arbitrary.
I don't think defaulting to "Input" or "Output" would be an improvement.

The node socket names aren't expected to be unique. That's why there's a separate identifier for each socket. I don't think adding a `.001` to names or something is helpful. Builtin nodes can reuse the same name for multiple sockets, so I think node groups should be able to as well. > When adding new Input or Output Sockets in the Group Node Properties Tab, the selected Input or Output Socket name is duplicated. It's not just the name that's duplicated, but everything except the identifier. That's just because otherwise the new input/output is totally arbitrary. I don't think defaulting to "Input" or "Output" would be an improvement.
Author

Shouldn't the Socket also be added to the end of the list.

Shouldn't the Socket also be added to the end of the list.
Member

Shouldn't the Socket also be added to the end of the list.

It uses the same behavior as just about every list in Blender, adding right after the active element. I think it's better to be consistent here.

>Shouldn't the Socket also be added to the end of the list. It uses the same behavior as just about every list in Blender, adding right after the active element. I think it's better to be consistent here.
Author

Quite a few lists ( Shape Keys, UV Maps, Vertex Colors, Face Maps ) have the Value added to the end not the Active element. ( Which would be the desired result of Adding something ) I like the way the Attributes are added, the user can choose from the popup. With GN Inputs / Outputs I find I have to almost always reorder, change the Type and figure which was the added Socket especially if adding more than one at a time.

Quite a few lists ( Shape Keys, UV Maps, Vertex Colors, Face Maps ) have the Value added to the end not the Active element. ( Which would be the desired result of Adding something ) I like the way the Attributes are added, the user can choose from the popup. With GN Inputs / Outputs I find I have to almost always reorder, change the Type and figure which was the added Socket especially if adding more than one at a time.
Member

Okay, hmm, looks like I remembered incorrectly about the ordering, my bad.
A popup sounds reasonable, though not that different than just adjusting the type and name afterwards honestly.

I'm not convinced any of this behavior is a bug though, since it's working "as expected."

Okay, hmm, looks like I remembered incorrectly about the ordering, my bad. A popup sounds reasonable, though not that different than just adjusting the type and name afterwards honestly. I'm not convinced any of this behavior is a bug though, since it's working "as expected."
Member

In #95432#1300229, @HooglyBoogly wrote:
The node socket names aren't expected to be unique. That's why there's a separate identifier for each socket.

I don't think adding a .001 to names or something is helpful. Builtin nodes can reuse the same name for multiple sockets, so I think node groups should be able to as well.

Hm, how can we ever distinguish these in other Editors then?
{F12842289 size=full}

Or from python?
{F12842292 size=full}

> In #95432#1300229, @HooglyBoogly wrote: > The node socket names aren't expected to be unique. That's why there's a separate identifier for each socket. > > I don't think adding a `.001` to names or something is helpful. Builtin nodes can reuse the same name for multiple sockets, so I think node groups should be able to as well. Hm, how can we ever distinguish these in other Editors then? {[F12842289](https://archive.blender.org/developer/F12842289/image.png) size=full} Or from python? {[F12842292](https://archive.blender.org/developer/F12842292/image.png) size=full}
Member

In #95432#1300198, @lichtwerk wrote:
Seems like there are muliple functions handling new sockets

  • make_socket_interface [in affect when adding a new socket through the UI] gives a unique identifier (but copies the name exactly -- no uniqueness)
  • nodeAddSocket or make_socket take care of making the name unique as well

and why do the other functions ensure uniqueness?

> In #95432#1300198, @lichtwerk wrote: > Seems like there are muliple functions handling new sockets > - `make_socket_interface` [in affect when adding a new socket through the UI] gives a unique identifier (but copies the name exactly -- no uniqueness) > - `nodeAddSocket` or `make_socket` take care of making the name unique as well and why do the other functions ensure uniqueness?
Author

I haven't used it much, but from what I could see, the Add Attribute in the Object Data Properties does a few checks. User cannot add the same name for a Domain+Data Type. Also gives a warning. Attr.png

I haven't used it much, but from what I could see, the Add Attribute in the Object Data Properties does a few checks. User cannot add the same name for a Domain+Data Type. Also gives a warning. ![Attr.png](https://archive.blender.org/developer/F12843431/Attr.png)
Member

Added subscriber: @JacquesLucke

Added subscriber: @JacquesLucke
Member

and why do the other functions ensure uniqueness?

They ensure uniqueness in the identifier, not the name. Sockets have a unique identifier, but not necessarily a unique name, that's on purpose. If the sockets need to be distinguished in an animation editor, they should be renamed.

There's one thing in your screenshots that looks wrong to me though, it's the Python API for retrieving sockets. I think that should be using the socket identifier, rather than the name, that looks weird to me.

Or from python?
{F12842292 size=full}

@JacquesLucke, am I missing something, or do you agree? In rna_def_node_socket, it looks like RNA_def_struct_name_property should be moved to the "identifier" property to fix this.


By the way, make_socket_interface makes node group inputs and outputs. While those also use bNodeSocket for storage, that's something we want to change, and they are conceptually different than sockets.

> and why do the other functions ensure uniqueness? They ensure uniqueness in the identifier, not the name. Sockets have a unique identifier, but not necessarily a unique name, that's on purpose. If the sockets need to be distinguished in an animation editor, they should be renamed. There's one thing in your screenshots that looks wrong to me though, it's the Python API for retrieving sockets. I think that should be using the socket identifier, rather than the name, that looks weird to me. > Or from python? > {[F12842292](https://archive.blender.org/developer/F12842292/image.png) size=full} @JacquesLucke, am I missing something, or do you agree? In `rna_def_node_socket`, it looks like `RNA_def_struct_name_property` should be moved to the `"identifier"` property to fix this. --- By the way, `make_socket_interface` makes node group inputs and outputs. While those also use `bNodeSocket` for storage, that's something we want to change, and they are conceptually different than sockets.
Member

In #95432#1303428, @HooglyBoogly wrote:
They ensure uniqueness in the identifier, not the name.

Oops, sorry, yes, my bad

> In #95432#1303428, @HooglyBoogly wrote: > They ensure uniqueness in the identifier, not the name. Oops, sorry, yes, my bad
Member

am I missing something, or do you agree? In rna_def_node_socket, it looks like RNA_def_struct_name_property should be moved to the "identifier" property to fix this.

I agree with that, it's a bit unfortunate. It's not something we can easily change without breaking lots of stuff.

> am I missing something, or do you agree? In rna_def_node_socket, it looks like RNA_def_struct_name_property should be moved to the "identifier" property to fix this. I agree with that, it's a bit unfortunate. It's not something we can easily change without breaking lots of stuff.
Member

Okay, right, too bad. It would be hard to find all the places that depend on this behavior.

I'll convert this to a known issue then.

Okay, right, too bad. It would be hard to find all the places that depend on this behavior. I'll convert this to a known issue then.
Hans Goudey changed title from Nodes Groups: adding new inputs or outputs will duplicate previous names (exactly, no uniqueness) to Node group inputs have incorrect "name" property 2022-02-14 07:10:05 +01:00
Hans Goudey changed title from Node group inputs have incorrect "name" property to Node group inputs and outputs have incorrect "name" property 2022-02-14 07:10:13 +01:00
Philipp Oeser removed the
Interest
Nodes & Physics
label 2023-02-10 08:44:16 +01:00
Sign in to join this conversation.
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
4 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#95432
No description provided.