You could click an arrow and it hides/shows inputs:
But not on nodes. Just in the properties editor.
Perhaps “Subpanel”?
Like, the panel “Sampling” has subpanels:
Yes, that’s the idea.
5 Likes
I think, what would clean up the node trees, make it less “Spagetti”, is the ability to instance nodes.
Like, instead of connecting a node to two very distant destinations, the user could place that same node twice (only within the same node group).
Shift+D would duplicate a node.
Alt+D would duplicate a linked node.
Pretty straightforward, isn’t it? 
2 Likes
not really, because unless it’s a special node (such as a Group Input/Output where this is already possible, or a special property node like, say, texture coordinates or ray types etc., where there is no functional difference between a duplicated or linked node), it may be very tricky to tell which pair of nodes is connected.
-
Similar approach to Ur approach of checkmarks which are clickable panels on node already stated previously like RadeonPro render etc.
-
So the point of my approach is the have an alternative idea without changing existing UI features, so the idea is not brittle or terrible, Its an idea without adding new UI feature like checkbox to node itself. ı guess u didnt understand the point of my comment that try to do things without causing new changes or inconsistency in UI (3. because checkbox are usually vertically aligned in CURRENT UI so checkbox for each category will be messy and bad if we use checkbox in the same old vertically aligned way, so its more terrible idea to have many checkbox vertically aligned, it already make node long enough),
-
Also, in my idea, the checkmarks are in N-Panel already so enum options will be editable, so there wont be anything enormous or messy, it will depend on users. Putting all combinations is just to have material presets for different materials so blender can start to have material presets like carpaint and other materials so users will be more aware of how to make different materials by ENUMS that ship with blender by default instead of trying to understand which ones to use. (This way of working already exist in other softwares that u change type of uber shader that add extra options like in UE)
-
[quote=" Perhaps the user can be forced to create only the appropriate node
→ I like this idea in principle. I think Lux does something kinda like this sometimes.
But how do you then prevent people from just plugging in a different node after all? And what if multiple but not all nodes are reasonable? ‘’]
I disagree , its not a good idea, , its bad for making user forced to create appropriate node, its against the princple of brecht to have a single uber shader that can stay by itself so there will be compability with other uber shaders for conversion etc. Its more like a mess to connect many things by plus sign, its against uber shader logic
Say you have three separately activatable options.
Your enum needs 2³ = 8 entries to cover all variations. Maybe one less if you don’t intend to cover the case of selecting no options.
An ENUM of eight entries is reasonable.
Say you have five options. You are now looking at an enum of 32 entries.
We already got more than five options, and maybe there will be more in the future.
That’s the sense in which a single enum to cover all combinations is brittle.
Every single new option doubles the enum.
Imagine a seemingly endless list of just subtly different combinations of enabled features. It’s a UX nightmare.
ENUMs are good if there is exactly one option out of many to select from.
If you need to cover combinations, they are an unreasonably cumbersome way to present that information.
But the problem is that when the subpanels are opened, they will make node longer if someone open all the panels and wanna use it fully, it is conflicting with the core reason for the efforts which was making shader less long, If his solution make it longer for the person who want to expose all the panels, so there should be a way to get rid of the header of panel when they are uncollapsed,
1 Like
The functional differences between a duplicated and a linked node are very obvious:
If you change a value on one of them, the other ones change as well. Not happening with regular duplication.
If there is something connected to the input of one of the nodes, the others act as if that input is connected as well, but no line is drawn. (Line “Spagetti” averted)
If an input is connected elsewhere, display the inputs as semi-transparent on other instances of that node. If you connect something to a semi-transparent input, the input disconnects elsewhere.
The only visual difference it needs: Display number of users in the header of the node.
1 Like
I was not arguing against the functional difference. I’m saying for certain specific nodes it literally makes no functional difference. It will not ever matter whether a Light Path Node is copied or linked. It gives the exact same data either way.
And I don’t think the visual difference you mention is sufficient.
Take a really silly example:
I’m linking two pairs of value nodes.
They have the same title, both pairs say 2 in the top right corner. How do I know at a glance which pair is which?
It’s kind of like asking “How do you know that a mesh object is linked, or just looks the same”?
The answer is “They use the same mesh data, and there’s a number of users for that data”.
Never been a problem.
Here, it’s even less of a problem.
In meshes it’s actually pretty easy to see: If you go into edit mode, all objects that share mesh data are shown in edit mode together.
And for nodes, sure, if you are like an end user who doesn’t care about under the hood workings and just has all the functionality to control stuff in a convenient place or something, I agree this isn’t gonna be much of a problem. But if you actually want to understand or debug a node system, it absolutely is
-
The use of ENUM for 8 options is better than having 8 checkbox vertically aligned as current UI does with checkmarks. At least node wont get longer with current chexboxes that doesnt use space horizontally after 2.8 changes of making every things vertical
(Noone said that we will have more than 8 enums tho, blender can ship with 5 enums and users can add if they want, as I told in N PANEL to edit the combinations so there wont be any 30 ENUM coming with blender by default) -
When u have material list, there is kind of ENUM to choose materials and u search which one u want to choose by search, (so there are many enums that are more than 8 as will be mentioned in images below). Eight Checkbox is the real nigtmare in ur idea in vertical UI pattern of Blender after 2.8
-
Blender has no way to give users and material presets so using enum for 2 purpose like 2 bird with one stone is quite good
-
Enum can be little tweaked to behave like editor option etc.
Just like blender editor chosing panel it can also be made horizontally by catergories to make it 8 VERTICAL and 4 horizontal if needed if the problem is having 32 long vertical ENUM
Or there is already more than 8 choice in this part in UI so its not a new nightmare
other softwares has that logic for grouping material related things too
Thus, while evaluating ideas, I hope u focus on the fact that the idea is to use current UI without changing, so my idea is not brittle in terms of the limitations that I try to have an idea. Historical events are evaluated according to the conditions and limitations, so again u evaluated my idea in wrong way. So its what that can be done to solve issue without changing anything in UI, I just try to find alternative solutions with minimum change, thats all.
Those are both examples exactly of the kind I mentioned: A single choice out of many. For that, sure.
The issue is when it’s multiple choice.
No idea what this is from, but this is a material library where you apparently go through a choice tree. This amounts to navigating through nested folders. Quite a different use case. Stuff is grouped together into logical presets. But I don’t think the Uber Shader lends itself to that sort of classification.
I’m saying this:
You can have
Diffuse
Specular
Diffuse Specular
Sub Surface Scattering
SSS / Specular
SSS Thin Film
SSS Thin Film / Specular
Refractive / Specular
Refractive Thin Film / Specular
Emission
Diffuse / Emission
Specular / Emission
SSS & Emission
SSS / Specular / Emission
SSS Thin Film / Emission
SSS Thin Film / Specular / Emission
Refractive / Specular / Emission
Refractive Thin Film / Specular / Emission
Diffuse / Clear Coat
Specular / Clear Coat
…
It’s just SO MANY options.
Of course there are many options thats why there is N-Panel checkboxes in my proposal, so ENUM is just extra functionality for user to have presets or simple options, noone will prevent user to have their own combination, they can still change the node from checkbox without using ENUM as I mentioned in previous posts
So without ENUM it should still allow for removing the needed categories. Noone expect Blender to ship with all the combinations of options as enum and limiting users with those enums
You can already do that exact thing: Ctrl+G on the node to be duplicated.
1 Like
Could capturing the output of a node as a named attribute be a thing in shader nodes? If I want to use the same color ramp adjusted mask image in 17 different places (a node group within a node group) it would be so nice to just have a named variable/attribute node.
The settings of a node are not geometry attribute though. Those are ‘attributes’ of the node itself. I think the goal is to expose as many parameters of nodes as sockets to make that possible. If the colorramp itself was an input to the colorramp node you could re-use the same ramp in 17 places easily.
Quick question, don’t know if this has been discussed before, but the thread is rapidly expanding…
When loading a previous scene that used Principled V2, the output noodles of some nodes such as a node plugged into the Clearcoat input disappear into a closed section rollout of the Principled shader. Will sections that have connected inputs be auto-expanded in a next version?
1 Like
Imo this was the best discussion about this:
1 Like
