Is there a way to hide/unhide sockes in a node?

I’m with a dev friend of mine trying to figure out how to program some nodes, and to avoid lonk kilometric nodes we would like to be able to hide/unhide

The dev told me that there is an “hide_value” option, but he cannot find any “hide_socket” values.

Some help from you could save us days of work :slight_smile:

I will you here @jacqueslucke because I think you may be now the most familiar with all the node related things :slight_smile:


1 Like

bricktricks uses this for some internal housekeeping , sample usage here

Edit: to add, this is for 2.79, for 2.8 (eeve etc) support D4370 has to land first

1 Like

Ok, first of all thanks for that speed!

After receiving your answer @LazyDodo (and @jacqueslucke over twitter pointing at your answer) I kept talking with the dev, and he says I got it wrong.

The thing is that he wants to put a button in the middle of a node, but he wants to avoid the socket, I think the picture explains it in the best possible way I can express it.

In the example shown in the picture maybe we don’t need to save a lot of space, but there may be other situations were this may be the best way to go, to avoid having tons of sockets and parameters shown.

He knows that a button can be put, but it’s automatically located in the upper part of the node, so what he is looking for is to be able to order the different parameters with the not socketed parameters.

I hope I’m explaining myself right… I feel it’s a bit awkward explanation.

Cheers and thanks!

1 Like

This would give great flexibility to the design of custom nodes. Above all, when they have several tens of parameters.
Thank you JuanGea !!

1 Like

I don’t think it’s currently possible to mix the input/output sockets with other UI elements, but i have to admit i’m no UI expert.

This is a current limitation indeed.

I actually talked about this with @brecht briefly last week. Would be good to get this functionality at some point (also for Cycles nodes).

For now you can only show these settings in a separate panel/popup similar to how it is done in Animation Nodes.

Thanks both of you @LazyDodoand @jacqueslucke !!

Let’s hope we can see this solved soon, it will open a lot of possibilities with the nodes, and specially with the work you are doign for the future, this is something needed for sure.


A simple way to solve this would be to have some layout options in the draw_buttons_ext
That way, you can have more settings for controlling nodes layout, without cluttering the node itself with buttons.
Something like this (just a quick test):

class NodeSocketHide(bpy.types.Panel):
    bl_space_type = 'NODE_EDITOR'
    bl_region_type = 'UI'
    bl_category = "Node"
    bl_label = "Node Socket Hide"
    def poll(cls, context):
        return context.active_node

    def draw(self, context):
        layout = self.layout
        bx.label(text = "Inputs")
        for inp in context.active_node.inputs:
            row = bl.row()
            row.enabled = not inp.is_linked
            row.prop(inp, "hide", text= "Hide " +
        bx.label(text = "Outputs")
        for oup in context.active_node.outputs:
            row = bl.row()
            row.enabled = not oup.is_linked
            row.prop(oup, "hide", text= "Hide " +
def register():

def unregister():

if __name__ == "__main__":

Thank you Secrop…
This code has some limitations:

  • forces you to have the side panel open. Ideally, it could be done in the same node.
  • does not solve the problem of including ‘labels’ or properties that are not sockets, in any position of the node.
  • does not group the parameters (this could be easy to add …)

Ideally, it could be:

  • be able to have something like a ‘NodeUnSocketLabel’ or ‘NodeUnSocketColor’ (only the property, without a socket) that could be positioned anywhere on the node.
  • NodeUnSocketLabel could include the property to collapse or expand other sockets associated or related to that socket. This could exclude the sockets that were connected.

The current code works very well with small nodes, but becomes insufficient with large nodes.

Best regards…

IMO ShadingNode should have a draw_inputs or draw_sockets method which does the above, let you walk through inputs and “draw” them.

Changing order and putting buttons in the middle would be so nice.

(draw_inputs, draw_outputs maybe)?

Of course it has! I’m not going to write you a complete set of tools to completly change the look of your nodes and node_editors. It’s just a sample code…

You can place this code in a floating panel, or in a pie menu… it’s up to you.

As said above by jacqueslucke and LazyDodo, for now custom sockets are still incompatible with builtin nodetrees. But it might change.
About i disagree with placing UI elements in between sockets, imo they should be in the draw_buttons (if relevant for the edition)… but dunno if i’m the only one.

Layout design is again up to you.

So, with your code what I said can be done inside a node?

The question is that you say that it can be located in a pie menu or in a floating panel, but the target is to put it inside a node, not in any other place or part of the UI.

The idea behind this is to be able to enable/disable related settings inside the node as I show in the pictures, this way you have at hand the parts of the node you want, for long and complex nodes it can be very helpful.
Having this ouside of the node, like in the sidepanel, kills the idea of working fast within the node, we could remove any setting from the node and leave any settings in the side panel, it is the same as max does in the slate node editor, and it’s slow, you have to be jumping from one place to another with the mouse when everything could be all together.


No. It allows you to tweak the node’s layout, but not inside the node. For now, the draw calls for builtin nodes are not allowed from python, and the only option is to use a python node to encapsulate the original builtin node with a custom draw (as LazyDodo first responded).

That is bit different from allowing any kind of changes in the draw_nodes routines…
Perhaps, extensible groups of sockets, just like we have in side panels, or a custom layout dropdown…
I’m in favor of a collapse of unused sockets and ui elements if not needed. But not so much of letting the complete draw to be editable.

1 Like

What is wrong with allowing addons to incorporate a design more appropriate to their needs? Not all shading systems are the same. I’ve seen nodes in Appleseed, with dozens of options.

Nothing wrong, if it’s to make the nodes look simpler. :wink:
Anyway, D4370 is now on master, and you can make whatever you want, from giving a facelift to builtin nodes, to expand functionality of nodegroups.

This doesn’t solve the issue of mixing buttons and sockets though does it?

Mixing buttons and sockets is another matter… A node draw has a defined structure that’s uniform in all nodes (from top to bottom: label, outputs, preview, draw_buttons, inputs). You can place buttons in the draw_buttons area (or in the draw_buttons_ext, on the side menu), but not in the socket areas. For placing buttons in the sockets areas, we need to change the sockets draw calls (with custom sockets), and that is still not fully supported.

That is really weird, because the node design and button positions should be defined by the designer of the node, not by a fixed design, is like if all the wordpress pages were exactly the same, with the same side bar and the sampost part, and the same everything, it’s a design that could fit for some things, but won’t fit for everything, and the same happens with the nodes, I may want a button that enable or disable a feature (as the example I posted) because that way it’s easier to understand, the node is less cluttered and the node execution could be optimized (for example disabling parts of the shader I assume).

I understand that this comes from the first node-system design, but I really hope this changes soon, because if we are going to work with Modifiers as nodes, or with any other type of node (including uber shaders and other things) the developers should have freedom to design their own nodes IMHO.


I’m just telling how things are… Changing this, is not my decision, and without a concrete design proposal, I would rather keep it as it is…

Here’s a similar proposal to the one on the top post (that fits the current api):

Wouldn’t this fit your needs? Or you still prefer to clutter the the node’s UI with more buttons?
(while i was scripting this, it even came to mind that perhaps we could simply have a right-click menu, for changing the visualizations settings of any node)

1 Like

Is not what I want or not, is for people to have freedom of design, to be able to avoid super long nodes (have you seen the appleseed ones?). the main target is to remove the need of the right panel for settings and to remove all those sockets from those checkboxes you showed for example.

Some basic guidelines are mandatory, totally agree, but more freedom is also needed, but I’m sure tat Jacques will create a good proposal as a start