Page MenuHome

Compact node for input types (attribute, value) and visibility for attribute processor
Confirmed, NormalPublicDESIGN


See T87009 for the original proposal.



  • Visibility never affects functionality.
  • Included in this proposal is to use sub-panels to separate between Properties, Inputs and Outputs.
  • Included in this proposal animation decorators in the properties panel. This is not required, but I wanted to think ahead and see how they would fit.
  • With compact node design we can have more sockets to take an attribute. This is demonstrated here with the Transform node.
  • In the properties panel only show inputs that can have a value (i.e., don't show Geometry sockets).
  • In the properties panel only show outputs that are optional.
  • I'm not sure if the labeless second line should span to the entire line or be confined in the half column (as shown in mockup).
  • In the context menu users can change type and visibility (as operators, not as properties).

Initial feedback I got from Ton:

  1. Nice to have the visibility control (though the icon to "invisible" is very invisible.
  2. The Node panel could mention the node name (and perhaps the color) ▸ Node: Transform
  3. There could (should?) be individual nodes for Translation, Rotation and Scale. And let artist combine them in the order they want.
  4. Users should be able to know which attribute the Transform node is operating on (in this case is "position", but this could be exposed so users can change).
  5. It would be nice to be able to quickly look at what is in the Geometry data being passed around (in the properties panel OR in it can be in the socket inspection)
  6. Geometries could be named (and the name visible in the spreadsheet and in the geometry inspection (see 5.)
  7. Changing the socket type seems problematic. Why can't artists just plug something (attribute reference or the value itself) and things work? Why attributes can't be passed around?

Event Timeline

Dalai Felinto (dfelinto) changed the task status from Needs Triage to Confirmed.Jun 14 2021, 2:58 PM
Dalai Felinto (dfelinto) created this task.

Some questions:

  • By default are sockets shown and then they are explicitly hidden?
  • Can the title and color of the node header be incorporated into the design?

@Charlie Jolly (charlie) yes and what do you mean by title + color incorporated?

Since the selected node and side panel are far apart, having the node title e.g. Transform and node header color e.g. Green shown in the side bar would confirm to the user they are working with the correct node.

Besides the type showing in the side menu (possibly?) I wanted to explore options for the "multi-type socket" in the UI:

Variations on top of Proposal E (in white because I printed them):

Proposal B has my vote - even just an unused colour that says "Undefined: will adapt to what you plug in". Not sure about the picker readout proposal of E though, I think the readout should be dynamic to what you plug in.

Proposal A = looks like a collapsed socket, waiting to be expanded, you most likely can't in the UX.
Proposal C = similar to proposal A, but looks like a visual bug. May not be clear when zoomed out.
Proposal D = similar to proposal A, but looks like a visual bug. May not be clear when zoomed out - less so than Proposal D.
Proposal E = two click to set the socket is not ideal, as expected behaviour is.. plug in, it will know what it is. Look at undefined sockets from other software node graphs - you can just plug in, then the in socket and out socket will adapt to the noodle type.

Thanks for keeping these design decisions opens.

Agree with Andres above, Prop B is probably best(though the ellipsis is kind of hard to see). Prop A/carousel just looks too wide out but otherwise could work too I think.

What about something like this then?

I saw this thread and the discussion for multi-input sockets, and came up with my own idea:

I also created a Right-Click-Select post for it, where you can find more of an explanation: Possible Design for Multi-Type Node Sockets What do you think of this?

Felix Kütt (fkytt) added a comment.EditedJun 30 2021, 12:15 AM

@Vladislav Macíček (Aeraglyx) I like that, much easier to distinguish for my(admittedly not at all improving) eyesight. And it doesn't exceptionally reach extensively outside the node boundaries.