This doesn’t solve the issue of mixing buttons and sockets though does it?
@bsavery,
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.
Cheers!
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
Cheers
Ah, sorry, that was a selection list, anyways, the idea is to have more design freedom for everyone.
Cheers
We would like to improve nodes to support custom UI layouts and something like panels to group and collapse sockets. Contributions welcome, otherwise it will probably happen at some point in the future but undefined when.
3 Likes
You are right, it could be the best moment to do it.
Maybe a call to the community for ideas could be good right now?
Like with the workspaces and the HDRI’s
Not all the ideas would be useful, and not everything will be used, but maybe it’s a good moment to receive a lot of input for this so you have a pool of ideas with different points of view about the nodes.
What do you think? Could be a good call?
Workspaces and HDRI’s are things end users could do without knowing a line of code, I don’t see that same crowd do a proper design on how to improve custom nodes.
Ok, I see your point here, you are right
But any call for ideas between addons writers about that questions? Greetings…
Could we use the minimize icon node, to a rightclick that calls a menu with visualization options?? Right now it’s just an ‘Edit Source’ placeholder… 
There is not much point doing a call for ideas without a developer to implement them.
The main thing would be to let core and add-on developers define custom UI layouts. Not sure what right click menus have to do with this. The design should take into account how this can work for group nodes too, but doesn’t seem useful to go into specific UI details of how that would work.
I got this final design, with the current API.
Here all the groups are folded.
Here only one group expanded.
Here with some groups…
In my opinion, this design only needs 2 simple things:
- Allow sockets that do not show the link, to avoid connections that do not affect the node.
- Allow mixing sockets and ‘no-sockets’ in the same design
I do not know the solutions that the other developers have implemented, but for me, with these 2 simple changes, the advance in the design would be much more flexible.
Greetings…
3 Likes
2 Likes
thats an amazing design ! could really be handy in the future with everything node
That is great, brecht!!
Btw… I wonder if there is any possibility of accessing the code of that design?
Greetings…
Edit: Oh sorry, I read again: just no real implementation
Finally, I also found the mode of mixing sockets and no-sockets, but it’s just a trick, adding properties before and after the socket.
I would like to be able to work on the improvement of the nodes, but my free time is very limited.
Regards…
Edit: Btw… The two models (the previous one and this one) are real and fully operational implementations.
I think the basic proposal here is to have nodes override their draw() method (call it draw_buttons_node) or whatever.
In that you could call layout.socket_input(self, ‘socket_name’) or such.
Ok.While you make your detailed proposal, I will continue looking for solutions.
Cheers…